On Mon, May 17, 2010 at 18:26, Justin Edelson <[email protected]> wrote: > On 5/17/10 12:10 PM, Alexander Klimetschek wrote: >> 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...
Sorry if I have been too harsh ;-) But that's a topic where I always wanted to write a longer post about... > 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. Exactly. Both approach the general concept of MVC, but in two very different ways. > 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. He he, they don't know what they are missing ;-) >>> 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. Sling's eventing can be used as a basis for the execution of workflows, and JCR's observation is a perfect triggering mechanism. The workflow engine in our CQ5 product is built on both (but it has its own workflow model). Regards, Alex -- Alexander Klimetschek [email protected]
