Instead of worrying about having two different application VERSIONS why not have two different types of USERS. So you have user1 that is allocated to "Core" and user 2 that is allocated to "Advanced". You can then use symfony's built in session management to limit access to Advanced features if a Core user is logged in and vice versa. You can even go so far as to use the filters framework to restrict visibility of certain features to those users that are not allowed access.
Keeping everything in one application allows better re-use of the same code base rather than having to re-write or (-shudders-) copying and pasting code to replicate certain functionality. Its a lot easier to write everything once and prevent access after the fact. On Thu, Sep 30, 2010 at 11:51 AM, Tyler.Williams < tyler.williams.1...@gmail.com> wrote: > Hi, > > We develop a leave management system. We need to have two versions of > this as "Core" and "Advanced". Core contains the basic features while > Advanced contains specific features. We need to develop these two > separately and integrate whenever needed with minimum effort. Main > facts and requirements are, > > * Advanced contains code only for advanced features. It doesn't > duplicate core code. > * An advanced feature may be an extension to an already available > feature in Core product. For an example, in Core, we may not provide > an option to upload copies of medical certificates when applying sick > leaves. But that feature will be available in Advanced while all other > leave applying criteria being same. > * Database schema of Core and Advanced can be different. > * Whenever a new features is added to the Core, after integrating, it > should be available in Advanced. This implies upgrading core should be > easy. > > Following are the two options we have brainstormed so far, > > Solution 1: Have Two Symfony Products for Core and Advanced > > index.php - Contains links to Core and Advanced > core/ > apps/ > core/ > lib/ > model/ - Business logic of Core > form/ - Form classes of Core > modules/ > admin/ > actions/ - One class per each action. > apply/ > reports/ > config/ > doctrine/ > schema.yml - Contains Core schema definitions > lib/ > model/ > doctrine/ > base/ > BaseLeave.class.php > BaseReports.class.php > Leave.class.php > Reports.class.php > advanced/ > apps/ > advanced/ > lib/ > model/ - Business logic of Advanced > form/ - Form classes of Advanced > modules/ - Advanced get "admin" and "reports" modules from > Core > apply/ > actions/ - One class per each action. May or may not > extend from corresponding Core classes > config/ > doctrine/ > schema.yml - Contains only Advanced schema definitions. Each > table alias starts with "Ad" prefix. > lib/ > model/ > doctrine/ > base/ > BaseAdLeave.class.php > AdLeave.class.php > > We hope to autoload, "lib" folders of Core in Advanced. > > In the index.php, we will have links like below, > > /core/admin/viewDashboard - Will use Core code > /advanced/leave/applyLeave - This will overwrite corresponding action > of Core (/core/leave/applyLeave) > > > Solution 2: Have Two Symfony Apps for Core and Advanced > > index.php > apps/ > core/ > lib/ > model/ - Business logic of Core > form/ - Form classes of Core > modules/ > admin/ > apply/ > reports/ > advanced/ > lib/ > model/ - Business logic of Advanced > form/ - Form classes of Advanced > modules/ - Advanced get "admin" and "reports" modules from > Core > apply/ > actions/ - One class per each action. May or may not > extend from corresponding Core classes > config/ > doctrine/ > schema.yml - Contains schema definitions for Both Core and > Advanced. Advanced ones will have the prefix "Ad". > lib/ > model/ > doctrine/ > base/ > BaseLeave.class.php > BaseAdLeave.class.php > BaseReports.class.php > Leave.class.php > AdLeave.class.php > Reports.class.php > > In the index.php, we will still have links like Solution 1, > > /core/admin/viewDashboard - Will use Core code > /advanced/leave/applyLeave - This will overwrite corresponding action > of Core (/core/leave/applyLeave) > > > Notes: > > We are currently using Symfony 1.2, Doctrine ORM and MySQL. > > Suggestions: > > We would like Solution 1 over Solution 2 because of clear separation > it provides. Even though lib/vendor and some other code would be > duplicated, it doesn't seems to be a concern comparing to the > flexibility. But we are not sure whether caching and any other > internals would have issues in this approach. > > Any suggestion on these two approaches is highly appreciated. Have any > of you faced similar incidences where you want to have two versions? > May be we don't need to stick into default folder structure (getting > lib/vendor out?) and customizing bit would provide more flexibility. > > -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony users" group. > To post to this group, send email to symfony-users@googlegroups.com > To unsubscribe from this group, send email to > symfony-users+unsubscr...@googlegroups.com<symfony-users%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/symfony-users?hl=en > -- Gareth McCumskey http://garethmccumskey.blogspot.com twitter: @garethmcc -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en
