On Mon, May 17, 2010 at 18:59, Justin Edelson <[email protected]> wrote: > I think we're talking about two different types of workflow here. I > really meant "pageflow".
I see. I was thinking of workflows because of Drools, but I haven't used that myself, just known it as some kind of workflow engine (might be wrong here). > 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). These pageflow/wizard applications are mostly non-restful and use a server-side session to keep the state. Building support for that in Sling would involve some kind of modeling of the relevant persistence in JCR, which goes quite far into the business/application specific logic. Also, in my experience, wizards are a very specific type of UI (and mostly a bad one ;-)), supporting them directly doesn't make sense IMO. And you typically do this with client-side javascript nowadays, anyway. So I don't think this is needed in Sling itself. > That said, I see these pageflow-type workflows migrating to be almost > entirely client-side. Right. > 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. It's difficult to come up with a good workflow system, because one the hand you want users to easily build custom workflows, and on the other hand developers want to use it for complex processing, ie. as a substitute for actual programming languages. I would say because of this it would be too difficult to tackle within Sling. And I guess it is too far away from the core goal of Sling. Regards, Alex -- Alexander Klimetschek [email protected]
