<snip/> > We must do *everything* possible to prevent abuse of the flowscript > layer. In fact, at the Cocoon BOF, several people expressed this concern > of seeing script kiddies coming from the flash world abusing the > flowscript and making the whole thing unmaintainable.
that's also one of my fears... > > Ideally, with business logic moved to the flow controller, one would only > > need to use selectors after a generator has been set. > > Yes. selectors? what for? <snip/> > > 1. Renaming The Flow Send Functions. > > Its clear from speaking with others that the naming of the flow script > > "sendPage" functions is quite confusing...because infact "sendPageAndContinue" > > has nothing to do with continuations. I propose: > > > > "sendPage()" be moved to "sendPageAndWait()" > > "sendPageAndContinue()" be moved to "sendPage()". > > +100! I had the exact same problem. +1 > > 2. Dynamic Flow Loading. > > The way I see it, the flow controller managers the flow through a set of > > available "views" (pipelines in our case). However, its quite possible that > > in certain situations the flow through this particular set of views will need > > to differ. For example, the flow through the views for a user with the > > profile of "administrator" might be different than for that of "user". > > Hmmm, -0.9 it sounds like overseparation of concerns to me (oSoC, it's > anti-pattern brother). We *want* people to work on the same file, > otherwise, the flow of the administrator and the one of the users might > get out of synch. why should they have to be in sync? it might be a totally different flow.. If we could read the flowscript from an internal pipeline we would be set. <map:flow language="JavaScript"> <map:script src="cocoon://something/prefs.js"/> </map:flow> cheers -- Torsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
