That's one way of achieving the goal but should not be a means to an end.
Ideally you would identify new model objects to be born, for instance is the
controller dealing a lot with adding fields to some "grid" object before
pushing it to the view, if so you could sub-class that grid object for tha
Yes, it is thick to me. Sometimes it is useful to make it a goal to have 1
action per controller, when you have a lot of actions per controller I have
found it makes you more hesitant to break up actions into helper methods (
the relationship of actions to helper methods for me is not 1:1 so more
http://www.survivethedeepend.com
OpenID Europe Foundation Irish Representative
From: josh.ribakoff
To: fw-general@lists.zend.com
Sent: Thursday, September 24, 2009 11:11:57 AM
Subject: Re: [fw-general] Split controller actions into multiple classes
The
The view displays the model in the UI yes, but the controller also affects
the application's presentation, albeit not visually. Repetitive controller
logic like a repeating subroutine that is modifying the view, should be
factored into action helpers. Repetitive display logic belongs in view
helpe
I would first consider creating some protected methods within that
controller to isolate some of your more repeated code. On first glance,
a method creating $params, might make sense.
In general, I dont think your controller is out of the ordinary, nor
would I say it is especially long. I do
Hello,
On Mon, Sep 21, 2009 at 9:55 PM, Matthew Weier O'Phinney
wrote:
>> If it is repetitive presentation logic you could sub-class the
>> Zend_Controller_Action or create action helpers if the repeating logic are
>> "cross cutting concerns". Keep in mind the saying is "fat model thin
>> control
-- josh.ribakoff wrote
(on Sunday, 20 September 2009, 03:00 PM -0700):
> It depends, controllers are part of the presentation layer,
Umm, not really. Controllers take the request, and determine what
view(s) and/or model(s) need to be instantiated. The view is the actual
presentation layer.
> if
It depends, controllers are part of the presentation layer, if there is
business logic it could be factored onto objects ( models ) it belongs to.
If it is repetitive presentation logic you could sub-class the
Zend_Controller_Action or create action helpers if the repeating logic are
"cross cuttin
Hello,
On Fri, Sep 18, 2009 at 9:48 PM, Sudheer Satyanarayana
wrote:
> On Friday 18 September 2009 07:10 PM, Ryan Chan wrote:
>>
>
> Consider splitting your code into multiple controllers and perhaps modules.
> Do you have model classes by the way?
Consider the following design.
Model class
On Friday 18 September 2009 07:10 PM, Ryan Chan wrote:
Hello,
I have a controller that contains too many line of codes, which made
the controller too large.
So I want to split each action into eactly one class files.
Is it recommended? If not, what are the recommended way to make the
controlle
Hello,
I have a controller that contains too many line of codes, which made
the controller too large.
So I want to split each action into eactly one class files.
Is it recommended? If not, what are the recommended way to make the
controller "thin"?
Thanks.
11 matches
Mail list logo
