[Solar-talk] Method-Based Actions

[Matthew Weier O'Phinney]

On 6/24/06, Antti Holvikari <anttih at gmail.com> wrote:
> On 6/23/06, Paul M Jones <pmjones at ciaweb.net> wrote:
> Basicly the problem is with Solar's config mechanism (which is
> beautiful) :-). If you group those classes using the "standard" way
> you can't apply config keys for them since they're never instantiated.
> If you try grouping like Zend does with the 'controllers' directory
> you end up with a mess with all sorts of dispatchers (hello Zend :-),

A couple caveats to my following comments: I develop a controller class
called Cgiapp, which is a PHP port of the perl module CGI::Application,
and I'm a Zend employee who occasionally contributes to Zend Framework
(but who actually rarely uses the Zend_Controller in my day-to-day work).

I can see the benefit to having all controllers in a particular
subdirectory, particularly when you're doing many related applications
on a single site; this acts as a queue for a maintenance developer as to
the purpose of the code, as well as what code to look at and where when
an application goes awry.

That said, in Cgiapp, we actually use lookup tables that are built by
the developer (and sometimes auto-generated, if the developer so
chooses), giving greater flexibility to individual developers in how
they organize their files.

> so that is not a good option nor is that the "solar way" ;-). But as
> we discussed before it would be good to be able the scatter the
> actions for multiple files so that you don't end up with a class with
> 100 methods.

The rule of thumb that most CGI::Application developers go by is that if
an application class has more than 7 distinct actions, you probably need
to refactor and determine whether or not you can split the application
into several sub-apps. Beyond 7, you risk complexity that will make the
application unmaintainable.

Beyond that, you're still likely to have more than seven methods in an
application class -- you may need setup or teardown methods, shared form
handling, etc. However, if you find you're doing a lot of logic in your
controller, it might be time to either move that logic into your Models
(if it's business related) or your Views (if it's presentation related).
I find that, in my controllers, if I have more than about 50 lines of
code in an action method, I generally need to rethink what I'm doing.

I often will create a base class for an application that has the minimum
required functionality, and then extend it for more specific
functionality. For instance, an article application really only needs
actions for listing, searching, and individual article views (and the
first two are basically the same, with a list being a pre-defined
search). This would serve on the public side fine. Then, for
administration, I might extend it and add methods for adding, editing,
and deleting articles; however, the beauty of it is that in that
particular class, I only need to view with that subset of the methods. A
further extension might add RSS feeds to the original application, and
so on.

Using an OOP paradigm, such as Solar and most other frameworks provide,
this is not only possible, but intended. Keep your classes simple, and
use them as building blocks for more extensive functionality.

-- 
Matthew Weier O'Phinney
mweierophinney at gmail.com
http://weierophinney.net/matthew/