On 5/17/10 12:10 PM, Alexander Klimetschek wrote: > On Mon, May 17, 2010 at 17:27, Justin Edelson <[email protected]> wrote: >> This is really a critical point. Sling is a web framework and, as such, >> is perhaps better compared with Spring MVC or Grails. >> >> Sling uses an entirely different paradigm than MVC-based frameworks. And >> whether this resource-driven paradigm works better than MVC is, to my >> mind, more a factor of the type of site/application than the display >> platform. > > Sorry, but I have to fully disagree. Sling is *totally* MVC: > > - model = JCR repository > - controller = Sling engine (url processing, resource + script resolution) > - view = custom rendering scripts/servlets, both for read and write (GET + > POST) > > The good thing is that you only have to design the model (simple, once > you got some JCR experience) and write your views. No custom fiddling > with the controller, ie. url regexp matching, OCM mappings and all > those ugly things ;-) OK OK OK... From a GoF perspective, you are of course correct. But in a practical basis, Struts and its descendents (e.g. Spring MVC) have redefined MVC to mean "you write a bunch of discreet controllers and wire paths to them". The difference with Sling, as you point out, is that you (almost? always?) NEVER write controllers. This is, to me, a paradigm shift from the way the MVC pattern has been implemented in the web tier for the past decade.
I could be wrong about this, but my experience has been that Sling is not recognizable as MVC to your average Struts/Spring MVC developer. >> Content-driven sites are an excellent match for Slin; I would not write >> a banking application with Sling. > > Why not? (apart from the fact that RDBMS are 150% made for banking > applications and thus will always be a little bit better than JCR) Two reasons: 1) Unless I'm missing something major, Sling doesn't have any workflow support ala Spring WebFlow or the Drools support in Seam. 2) The reason you gave. Justin > > Regards, > Alex >
