[Solar-talk] Controller_Front::fetch() vs. Controller_Page::load()
Rodrigo Moraes
rodrigo.moraes at gmail.com
Wed Jul 4 12:33:00 CDT 2007
Hi,
This is something I think from time to time: is there a reason for
Solar_Controller_Page::_load() accept both null / string /
Solar_Uri_Action?
This doubt has 2 reasons:
1. _load() is called only by fetch(); fetch() is normally called by
the front controller, which has already manipulated its $spec to build
a Solar_Uri_Action. So why not use the Solar_Uri_Action provided by
the front controller and throw an exception if it is not a instance of
Solar_Uri_Action?
2. The page controller acts like a front controller dealing with the
current uri built from spec. This makes a bit more difficult to setup
an alternative routing mechanism. The biggest problem imo is that the
page controller decides about the action that will be executed; you
have to "cheat" it passing a "fake" uri for it to extract the action
you want. Because of this, I think that the first part of _load()
should be a bit different:
* instead of manipulating Solar_Uri_Action to get action / uri info
/ uri query, it should receive this data directly from the front
controller, or ask the front controller about it. The first option is
more simple to implement: just make the front controller pass an array
with 'action', 'info' and 'query'. The uri manipulation part goes to
the front controller which already has an instance of
Solar_Uri_Action, and the page controller would just do the rest of
the job: set $_info, $_query and check if the passed action is valid,
etc.
Sounds pretty simple to me. Do you think it would be a problem or
would be less flexible? My purpose is to let the front controller set
the action to be executed, and avoid the uri parsing inside the page
controller. Thoughts?
-- rodrigo
More information about the Solar-talk
mailing list