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:[email protected]] Sent: 27 July 2011 14:30 To: [email protected] 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: [email protected] Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
