On 5/17/10 12:46 PM, Alexander Klimetschek wrote: > 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... You should... I didn't take it that harshly, but I do think there's a big difference between MVC and "MVC". For better or worse, I've given up on talking about the former. I recognize this is a bit lazy.
... > >>>> 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). I think we're talking about two different types of workflow here. I really meant "pageflow". Eventing/Observation are good triggers for an asynchonous workflow (i.e. for content processing). But I'm not sure these are that applicable for the pageflow part of, say, a bill pay transaction (or any multi-page wizard). That said, I see these pageflow-type workflows migrating to be almost entirely client-side. In any case, it's not like there's a workflow system integrated into Sling (CQ is a different story). Whether this is something we should do or not is a separate discussion. Justin > > Regards, > Alex >
