The company I work for is building kind of a mini-framework on top of symfony. We build a lot of web sites for museums, and most of those sites have many very similar needs. For example, we typically deal with collections of objects, which may get organized into collections or curated 'exhibits'. Users can log in and make their own collections and exhibits, there is some specialized search functionality, etc, etc.
We've built one collection website using symfony, and we like it a lot. I am now trying to refactor the site in such a way that the reusable bits are easily pulled into future projects. The existing code consists of many modules, specialized libraries, core symfony libraries that have been extended, a somewhat complex data model, and so on. All of the 'site-specific' code is currently very entangled with the 'framework' code. Ideally we would have a repository for this core functionality and our future projects would use svn:external to point at specific snapshots of the core codebase. So, I'm trying to figure out the best approach to accomplish this. I've had a few ideas, but I was hoping to get some input on the feasibility of those ideas and possibly new ideas. APPROACH 1: All framework functionality as plugins. Following this approach, there would be one very large plugin which would include all of the core extensions to symfony which make up our framework, including the core data model. Smaller plugins would be used to add non-core features. Over time the entire framework would be likely to consist of many plugins, possibly 20+. Site specific functionality would be defined in configuration files and by Advantages: * Complete modularity, aside from the functionality in core every chunk of functionality can be added in or omitted as desired. * Some functionality which is more generally useful may be more easily open-sourced as plugins using this approach. I also see some disadvantages with this approach. * It will be something of a pain to create and maintain all the separate svn:external directories in the plugin folder. * It will also be a pain to have to manually add configuration settings for each plugin to the various project configuration files. APPROACH 2: Inside-out plugin approach This is a reverse of the previous approach. The core functionality would be a regular symfony project under version control. Extra features would still be saved as plugins, and in addition the site-specific customizations of that functionality would be saved as a plugin. I don't feel this is a good approach as it is really does not seem to be the intention of the plugin system and I'm sure there would be a lot to overcome. APPROACH 3: Framework = project, site = app This was my original idea of how to approach this before I became more familiar with the plugin system. As much as possible, shared functionality would be implemented as libraries at the project level. Site-specific customizations would be restricted to the application level. I feel this could work, except for the fact that the exact same model code is shared among all applications. This would make it very difficult to customize model logic for a project without also rolling those customizations back into core. As I see it, Approach 1 (many plugins) is a strong winner. Am I missing any other kind of approach that could work? Are there any big gotchas that I should watch out for while making an extensive collection of plugins like this? Any feedback would be very appreciated. :-) David Brewer [EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en -~----------~----~----~----~------~----~------~--~---
