2

Our application is a large scale Javascript application, using the Javascript MVC framework. We are using the MVC app folder across all of our sites via an SVN:external, and each site also has their own files. The settings files are specific to the site.

We require the system to have the ability to have different functionality for each site. The core functionality should stay the same. We need to extend the core code while also keeping a maintainable solution for current and new developers.

Currently the options we have thought of are:

a: Embedding feature conditionals within the core and turn the features on/off via the a settings file

b: Override/inherit existing controllers

c: Implement a modular system (plugins) with unlimited hooks within the core and configure which plugins are loaded/enabled via the settings.json

Option a has the problem of being hard to maintain long term, and is fairly hacky.

Option b is already implemented, but is hard to maintain (as if we have a new feature, we have to edit each site's file if it has been overwritten

Option c is a solution we have recently thought of to try and decouple fixes (by using a shared (plugin) controller and editing a site-specific settings file.

What would be good to know is if anyone has any experience with any of the options we already have thought of, and if anybody knows of another option that would be a better fit.

Scott Warren
  • 243
  • 3
  • 12
  • Also worth mentioning, we use OpenAjax, so it is possible to decouple the shared code with the site specific code. We also use Steal.js as a dependancy manager – Scott Warren Mar 27 '13 at 00:53
  • Ended up using both option b and option c depending on the actual task: Using option b to overwrite our model methods that were needed and option c for things like form validation (adding new rules to sites rather than adding them to the core and using feature toggles) – Scott Warren Mar 27 '13 at 07:39

1 Answers1

0

Leaning towards option C.

Large scale applications would largely benefit from following the modular pattern. You can keep your code loosely decoupled for better maintainability in the future, also allowing for many developers to work on individual pieces at a time. And load your core modules and addons via site specific settings file.

I recommend you checking out Addy Osmani's article on the topic of large-scale applications:

The Mediator, Facade, Pub/Sub pattersn work very well with modular components, and couple that with a module loader like, RequireJS then you have a good foundation for large-scale application. I've used this at work and found it to be an excellent way to keep everything organized and easy to maintain.

Amy
  • 7,388
  • 2
  • 20
  • 31
  • Thanks, do you think there is any other options in trying to have shared code that we can make site-specific changes to? – Scott Warren Mar 27 '13 at 00:56
  • @scott There are other patterns you can use, there's no one-solution-fits-all, so I highly recommend you examine other patterns that you think your application would benefit from using. Here's more reading: http://addyosmani.com/resources/essentialjsdesignpatterns/book/#summarytabledesignpatterns – Amy Mar 27 '13 at 01:12
  • Thanks, I'll have a look. – Scott Warren Mar 27 '13 at 01:16