from the Seagull mailing list
Seeing what other frameworks are doing, i’ve done a diagram that may help developers to visualise the Seagull workflow from the app controller point of view. You must imagine that the currently active module will override the validate/process/display methods to implement the specific functionality.
This way the framework takes care of framework tasks, and modules deliver specific functionality.
We don’t do things like Phrame and Mojavi (and struts) in terms of creating an object to encapsulate actions mainly to avoid the uneccessary overhead of using objects for objects’ sake. In the Seagull equivalent, an action request parameter is mapped to $input->action and invokes the relevant private method in the module’s manager object.
Also worth mentioning as the question gets asked a lot, the choice of database abstraction layers and template engines are up to you. Seagull happens to use PEAR::DB and Flexy but slotting in other components does not require a lot of code to be changed.