Re: [fw-general] Split controller actions into multiple classes
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 that module so the implementation logic resides in a subclass of the grid class instead of the controller instantiating the abstract grid and setting it "procedurally". A useful way to think about this is reading the chapter called "transaction scripts" and "page controllers" in POEAA, I think those patterns capture the essence of the "fat controller smell". Sudheer Satyanarayana wrote: > > 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 >> controller "thin"? >> >> > Consider splitting your code into multiple controllers and perhaps > modules. Do you have model classes by the way? > > > -- > > With warm regards, > Sudheer. S > Business: http://binaryvibes.co.in, Tech stuff: http://techchorus.net, > Personal: http://sudheer.net > > > -- View this message in context: http://www.nabble.com/Split-controller-actions-into-multiple-classes-tp25508838p25600601.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Split controller actions into multiple classes
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 then 4-5 complex actions and I could easily have 25+ helper methods bloating the controller. When the actions are spread out across controllers it can make it easier to factor, and they can always be re-combined later after some of those helper methods mature and are "moved up" into more abstract classes Ryan Chan-2 wrote: > > 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 >>> controller" not just "thin controller" >> > > For example, do you think the following code is a "thick controller"? > and difficult to manage? > > http://howachen.googlepages.com/test.php > > > For me, it is. > It would be better to manage if each action is in a separate PHP class > file, isn't? > > -- View this message in context: http://www.nabble.com/Split-controller-actions-into-multiple-classes-tp25508838p25600132.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Split controller actions into multiple classes
I'd agree. The View handles the rendering of output, etc. But the Controller determines the View, constructs responses, and can do a lot to influence the final presentation. The Controller+View make up the presentation layer of the application. Pádraic Brady http://blog.astrumfutura.com 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 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 helpers as you correctly pointed out. I consider both part of my application's presentation ( but maybe the line is blurred in passive MVC ) Matthew Weier O'Phinney-3 wrote: > > > 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. > > -- View this message in context: http://www.nabble.com/Split-controller-actions-into-multiple-classes-tp25508838p25551508.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Split controller actions into multiple classes
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 helpers as you correctly pointed out. I consider both part of my application's presentation ( but maybe the line is blurred in passive MVC ) Matthew Weier O'Phinney-3 wrote: > > > 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. > > -- View this message in context: http://www.nabble.com/Split-controller-actions-into-multiple-classes-tp25508838p25551508.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Split controller actions into multiple classes
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 don't really subscribe to the thick/thin controller idea necessarily. I think the controller should have as much code as it needs to fulfill its ultimate job.. Which is: The Controller should interact with the environment in such a way to instantiate the proper models, views, and other consumables (like a form) in order to complete a request. It shouldnt do anything "business" logic wise, nor should it do anything that would be considered UI or presentation specific. -ralph Ryan Chan wrote: 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 controller" not just "thin controller" For example, do you think the following code is a "thick controller"? and difficult to manage? http://howachen.googlepages.com/test.php For me, it is. It would be better to manage if each action is in a separate PHP class file, isn't?
Re: [fw-general] Split controller actions into multiple classes
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 >> controller" not just "thin controller" > For example, do you think the following code is a "thick controller"? and difficult to manage? http://howachen.googlepages.com/test.php For me, it is. It would be better to manage if each action is in a separate PHP class file, isn't?
Re: [fw-general] Split controller actions into multiple classes
-- 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 there is business logic it could be factored onto objects ( models > ) it belongs to. Yes, absolutely. > 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 > controller" not just "thin controller" Actually, repetitive presentation logic should be pushed into view partials or helpers, not action helpers. ;) > Recommended reading - > http://blog.astrumfutura.com/archives/353-An-Example-Zend-Framework-Blog-Application-Part-2-The-MVC-Application-Architecture.html > > Ryan Chan-2 wrote: > > what are the recommended way to make the > > controller "thin"? -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/
Re: [fw-general] Split controller actions into multiple classes
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 cutting concerns". Keep in mind the saying is "fat model thin controller" not just "thin controller" Recommended reading - http://blog.astrumfutura.com/archives/353-An-Example-Zend-Framework-Blog-Application-Part-2-The-MVC-Application-Architecture.html Ryan Chan-2 wrote: > > what are the recommended way to make the > controller "thin"? > -- View this message in context: http://www.nabble.com/Split-controller-actions-into-multiple-classes-tp25508838p25530137.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Split controller actions into multiple classes
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: = User Controller: = Auth Actions: = Registration Login Logout ResetPassword EmailVerification as you can see, even I put a lot of code in model - User, that are still too many action in auth controller. Thanks...
Re: [fw-general] Split controller actions into multiple classes
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 controller "thin"? Consider splitting your code into multiple controllers and perhaps modules. Do you have model classes by the way? -- With warm regards, Sudheer. S Business: http://binaryvibes.co.in, Tech stuff: http://techchorus.net, Personal: http://sudheer.net
