Pragmatism in the real world

AkCom: The Akrabat Components for the Zend Framework

I have a real world project to deliver that will be based on the Zend Framework, so I’m actually putting in time to get a system that works for me.

Some of the work I’m doing, I’ve decided to release under the same license as the Zend Framework and I’ve decided to use the name AkCom. I was using Akrabat, but decided that it’s too generic for me and I might have other plans for it in the future :)

AkCom mainly exists to provide a place for me to put my extensions to the Zend Framework in order to enable me to write applications more easily. No doubt it’ll grow over time!

What’s in there, then?

Initially, there are three files in AkCom:

DevelopmentExceptionHandler.php
Minor modifications of Harry Fueck’s Pretty Blue Screen
Controller/Action.php
An extension of Zend_Controller_Action that creates views automatically for use in the action. Upon destruct, it renders the view. Recent impovements are based on the ideas of Marcus
Controller/RequestRouter.php
A simple router that picks up controller and action from the $_GET and $_POST arrays. It allows for use of Zend_Filter_Input to hold $_GET and $_POST and also allows for controllers to be in different directories based.

Subversion

AkCom is kept in subversion and is available at http://svn.akrabat.com/svn/AkCom/trunk/.

I’ll try and write up my usage of the components as time allows.

8 thoughts on “AkCom: The Akrabat Components for the Zend Framework

  1. hello, rob!

    i'm using your new Controller/ files, and i get an error on app/views/site.tpl.php when i try rendering main content
    $this->render($this->Templates->content) (that's how it worked with your old files from Test Code 3 i think).

    so can you tell me how should i use it correctly ?

    thanks.

  2. sory… i messed it up. i found what i was doing wrong. u should delete theese 2 posts. my bad :D

  3. hi again!

    i have a little problem. particularly with a login module. but the problem is the same with all modules that are incorporated in main site and need a little php pre-processing.

    so… my login module is up there on every page of the site (every controller/action). what i can do (and i did for now…) is to put a loginAction method in each controller with same PHP code and _forward from each action inside the controller to 'login' action. it's ugly but it works. in this case.

    but in a complex application, in which might be 5-10 of these independent persistent modules, what can i do ? maybe u have a clean, simple solution.

    thanks.

  4. The processing of the login only needs to be in one module/action. I would probably create a view helper to display the login box.

    Regards,

    Rob…

  5. Hi there, looking for the graal of view rendering automation, I ended up on your overpowered version of Controller_Action. That said, there's one thing I do not understand: why do you have two different instances of Zend_View ? :|

    After re-re-re-reading your code, it seems like _view renders only the action part, which is echoed somewhere in the siteTemplate rendered by _siteView, like in:

    Your site name
    actionOutput; ?>

    Thus, siteView, would be some kind of wrapper to add headers and footers.

    Did I understand well ?

  6. Hi Geoffrey,

    Exactly. right. $this->_siteView is used for the "outer" html template and $this->_view is used for the action template.

    The "outer" template is called site.tpl.php which has:

    <?php echo $this->actionOutput ;?>

    within it.

    Mainly to allow separation of concerns. Not sure that it's really necessary though…

Comments are closed.