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.
(Sorry for top posting, this email client is rubbish!)
Sent: 27 July 2011 14:30
Subject: [Catalyst] Refactoring Controllers
I have a question regarding controller refactoring, and whether
subclassing (or adding a Moose role) would be a good idea for a
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.
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