[Solar-talk] Method-Based Actions
Antti Holvikari
anttih at gmail.com
Sun Jun 25 03:07:28 PDT 2006
On 6/25/06, Matthew Weier O'Phinney <matthew at zend.com> wrote:
> 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.
You have a really good point there.
Now the question is, how would do this with Solar? Matthew, could you
share an example with CGI::Application :-)? With Solar, the base class
(like Bookmarks.php) needs to be instantiated by the front controller,
otherwise the config keys wont work. That is, you can't extend the
base class and have those config keys for the base class to apply to
the child classes. You could call child classes (which perform the
extended functionality) from the base class but then you have another
controller right there. Paul, correct me if I'm wrong.
At first it seems easy to extend and make those sub-apps but I have
yet not seen a clean solution for this.
> 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.
I think you're absolutely right, and this should always be kept in mind.
--
Antti Holvikari <http://antti.dotgeek.org/blog>
Zend Certified Engineer (ZCE)
More information about the solar-talk
mailing list