Separate Chaplin into a 'framework' and a sample app.

[cpsubrian]

Forgive me if this goes a bit against the philosophy of Chaplin, but after working with it for a while it is clear that Chaplin contains about 50% generic, reusable code and 50% sample application code (sessionController, likes controller, posts controller, etc.)

Lets say someone has 5 smallish sites running under the Chaplin structure. Right now, it would be cumbersome to merge in changes and optimizations to the base classes, views, and application logic because they are interspersed with sample code.

I would propose that Chaplin could be split into a framework-esque base set (for the sake of discussion lets call it "Bowler'), and then a sample implementation of that base set called 'Chaplin'.

Bowler can contain the following:

• application.coffee
• mediator.coffee
• routes.json
• controllers/
  • controller.coffee
  • application_controller.coffee
• lib/
  • route.coffee
  • router.coffee
  • subscriber.coffee
  • support.coffee
  • sync_machine.coffee
  • utils.coffee
  • view_helper.coffee
• models/
  • collection.coffee
  • model.coffee
  • user.coffee
• views/
  • application_view.coffee
  • collection_view.coffee
  • view.coffee

Essentially, boil it down to a glorified 'Hello World'. That allows developers using it to more easily incorporate updates and optimizations to the core logic into their app. In an ideal world, this core would even be stored in a bowler/ or core/ directory that developers don't touch. They instead extend it where necessary.

Chaplin then can happily continue to demonstrate how one might handle authentication, advanced views interactions, proper use of collections, etc.

Thoughts?

[paulmillr]

+1, this will allow easy updating & publishing.

-1 for routes.json, it should be routes.coffee.

[paulmillr]

In my opinion chaplin should also be distributed as a one simple .js / coffee file which is not usually modified (just as jQuery.js etc).

[cpsubrian]

routes.json was just a slip of the finger, heh. Agreed that .coffee is the correct format.

[cpsubrian]

As far as distribution goes, I'm not sure I totally agree, I imagine most people would deploy their 'Bowler' app using require.js' optimizer or some other build system.

[Rendez]

For what I know, that's already underway.

[cpsubrian]

Great news Rendez. An insight into the progress or how we can contribute/test?

[molily]

I would also like to split the general structure & core from mere example code, but the question is where to make the cut and if this cut is comprehensible for developers.

At the moment, the situation is so messy that quick separation would just introduce more confusion:

• Developers are supposed to subclass the Controller, Model and View classes from Chaplin
• … but Application, mediator, utils, support and routes are singletons, you have to modify them directly
• … which is mostly easy but not nice from a framework POV
• … also, you could theoretically subclass ApplicationController/ApplicationView, but then you have to edit/replace the Application to load your derived modules instead, so at the moment you should just edit them and add your custom stuff
• … which is neither easy nor nice

That’s why we published Chaplin as “an example architecture” in the first hand, because it does match the characteristics of a framework (yet). Of course Chaplin may evolve and I’m all for making it more framework-like.

My ideas would be:

• Controller, Model and View may be subclassed (like it’s already done)
• Make Application a class. The sample implementation instantiates it.
• Separate Router/Route and routes.coffee
• Move all app-specific code out of AppController so you don’t have to subclass it to start-up common controllers
• By using a custom (i.e. derived) Application, you might use a custom AppController and/or custom Router
• By using a custom AppController, you might use a custom AppView
• mediator stays a singleton but it can be extended in a custom Application
• utils and support stay singletons but may be derived by prototypal delegation

I welcome more ideas how to clean this up even further.

[cpsubrian]

All very good ideas. I wonder what the best place to start is. Just fork chaplin and offer up ideas that way?

[cpsubrian]

I think much of the logic of ApplicationController (if not all) could be moved into the (new) Application class. ApplicationController never really was much of a controller (connecting routes to actions) and acted more like a meta-controller. I think it makes sense for a higher layer to take care of loading and initializing controllers.

A developer could then subclass Application to add any additional initialization logic needed.

[cpsubrian]

The new ApplicationController would be very minimal, basically just starting up the main application view.

[cpsubrian]

initControllers and initRouter can move from application.coffee to the Application class.

application.coffee can be renamed to main.coffee (it would be recommended to rename main.coffee to the actual name of your webapp). main.coffee creates an instance of Application.

[cpsubrian]

One last thought for now.. I guess there is no need to rename the core. The core can be Chaplin and we can just add an examples directory. That opens up an opportunity for other use cases to be contributed back in addition to the current one.

[maelp]

you should also probably move all the "generic classes" like models/model views/view into lib/model and lib/view

[molily]

I wonder what the best place to start is. Just fork chaplin and offer up ideas that way?

I’ll answer in more detail later, just a note so far: Please fork the development branch since I already made severe changes to the structure in that branch and started to test the core components (see issue #9).

[karellm]

Hi there,

I've started playing with the exemple application and it was my main concern about chaplin. I love the ideas and architecture but it is "difficult" to dive in as you don't really know what is to keep or application specific. I ended up reading almost all the code base to understand it end to end.

I'm working on some BB plugins too and I'd love to see a framework with plugins (a bit like the RoR ecosystem). I'd love to get involved in making it a framework. If it is something you want, @molily could you define some guidelines and how we can help?

[molily]

The progress so far: We’ve split up Chaplin and the sample app in the development branch so Chaplin can be built independantly. All Chaplin files are AMD modules named 'chaplin/…'. These can be compiled with an r.js build file into one external library file.

This Chaplin core is agnostic in regard to the templating engine used. An app based on Chaplin need to create a View class inheriting from Chaplin’s View class. The derived class provides a getTemplateFunction method. The example app loads templates with the require-text plugin and compiled them using Handlebars.js on the client side.