That's a pretty broad question, but three basic ideas come to mind. First start by factoring as much common code as possible out into separate classes. If they are asking for major differences in their custom versions, using a version control system and branching for their changes might be a good idea, but it brings with it the overhead of maintaining branches and backporting fixes as needed. If the customizations are not so vast, you can use a Strategy pattern to codify the customizable behaviors into interchangeable classes and then either create an Admin page or a config file where they can select the ones they want.
But I think the solution you choose will depend on the sort of customization you're facing. In general I think the design practise of creating well-defined interfaces for the various components of your app makes it easy to create interchangeable components and behaviors. Whether you are picking the components at runtime with some configuration options or at compile time by actually selecting a subset of files to deploy (via makefiles or version control) is not as important in my mind. I'm sure there are many other possible solutions as well. If you could provide some more info about the sorts of customizations I think you'll probably get some interesting answers. Byron From: Michael Reddick [mailto:[email protected]] Sent: Thursday, April 02, 2009 1:32 PM To: [email protected] Subject: [Catalyst] Custom changes to different instances of the same app If you have a Catalyst app installed at several different customers, and they all want their own customizations, whether it be to the interface or the business logic, what are some different strategies for doing that using good coding standards? Thanks, Michael
_______________________________________________ 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/
