[Catalyst] Refactoring Controllers

Steve steve at matsch.com
Wed Jul 27 14:11:24 GMT 2011


Ian,

You may have a point there.  The application in question was my first 
*real* Cat app, and as such being explicit was very important.  If a 
refactor is to be done, there will be a ton of logic moved to the model, 
as these controllers are pretty big currently.

I still would like to know how subclassing and/or roles might be applied.

Thanks!
On 7/27/2011 9:46 AM, Ian.Docherty at nomura.com wrote:
> Steve
> I'm not sure I have enough information to answer this so my answer may be a bit wide of the mark.
>
> Would it make more sense, rather than to have different controllers, to abstract the different types of invoice into model objects with common methods, but use inheritance, moose roles, etc. to ring the changes.
>
> Then in your controllers, perhaps use a query parameter to indicate the type of invoice, create the correct type of object and put it on the stash, using chaining to sort out your other controllers.
>
> e.g. /invoice creates an invoice object using query argument 'invoice_type' to determine the class to use
> then chain to /invoice/initialize, or invoice/control, or invoice/generate etc.
>
> Regards
> Ian
>
> (Sorry for top posting, this email client is rubbish!)
>
> -----Original Message-----
> From: Steve [mailto:steve at matsch.com]
> Sent: 27 July 2011 14:30
> To: catalyst at lists.scsys.co.uk
> Subject: [Catalyst] Refactoring Controllers
>
> Hi all,
>
> I have a question regarding controller refactoring, and whether
> subclassing (or adding a Moose role) would be a good idea for a
> particular application.
>
> The application creates 6 different types of invoices, each representing
> a particular type of service.  Currently, I have a controller for each
> that handles the various steps that must be taken to produce and
> ultimately send these invoices.  ALL OF THESE CONTROLLERS HAVE THE SAME
> ACTIONS, and most of the same logic, which to me says I should refactor
> these controllers...I just don't know how, and also whether the benefit
> is worth the work.  Almost certainly it would not be worth it in and of
> itself, however I might want to write another application someday where
> knowing this would certainly be useful :)
>
> So IF this seems reasonable, and my controllers are 'FOOcontrol',
> 'BARcontrol', 'BAZcontrol', and my actions are 'initialize',
> 'upload_data', 'process', 'generate_invoices'...etc., what is a good way
> to stay DRY?  In particular I'm having a hard time wrapping my mind
> around how the URI's would be handled.
>
> Thanks,
> Steve
>
>
>
> This e-mail (including any attachments) is confidential, may contain
> proprietary or privileged information and is intended for the named
> recipient(s) only. Unintended recipients are prohibited from taking action
> on the basis of information in this e-mail and must delete all copies.
> Nomura will not accept responsibility or liability for the accuracy or
> completeness of, or the presence of any virus or disabling code in, this
> e-mail. If verification is sought please request a hard copy. Any reference
> to the terms of executed transactions should be treated as preliminary only
> and subject to formal written confirmation by Nomura. Nomura reserves the
> right to monitor e-mail communications through its networks (in accordance
> with applicable laws). No confidentiality or privilege is waived or lost by
> Nomura by any mistransmission of this e-mail. Any reference to "Nomura" is
> a reference to any entity in the Nomura Holdings, Inc. group. Please read
> our Electronic Communications Legal Notice which forms part of this e-mail:
> http://www.Nomura.com/email_disclaimer.htm
>
>
> _______________________________________________
> List: Catalyst at lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/
>
>



More information about the Catalyst mailing list