Well, they're not all exactly alike -- they just share some common functionality. In fact they can look and work in almost completely different ways, even though at their core they share features.
Also, we're hoping to be able to continue developing and adding features to the framework, even as it is used on multiple projects, and be able to update those projects with the new features and/or bugfixes without overwriting the work already done on the project. So we need to be able to isolate the framework features from the custom parts of the site. So far we've been proceeding with the 'framework as a series of plugins' approach and I think that's going to work out pretty nicely. It has forced us to think about what our building blocks really should be, and it allows us to use individual configuration files to customize the behavior of each of those building blocks. Thanks, David On 2/27/07, Jorge Laranjo <[EMAIL PROTECTED]> wrote: > If all the websites are alike why not do, from one of thoose, create a > sandbox that you reuse for future projects? > And you can have multiple plugins as you need it or even components or > components slots. > > > Em 2007/02/20, às 02:17, David Brewer escreveu: > > > 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] > > -- > Atentamente, > Jorge Laranjo > > email> [EMAIL PROTECTED] > gTalk > [EMAIL PROTECTED] > msn > [EMAIL PROTECTED] > aim > [EMAIL PROTECTED] > skype> jorge.laranjo > http://www.olhares.com/fueg0/ > http://www.flickr.com/photos/fueg0/ > http://concursosdefotografia.blogspot.com/ > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
