<snip type="agree"/> > >>>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? > > Hmmm... > > > it might be a totally different > > flow.. > > yes, sure, but it smells like overseparation to me. Why don't we start > with one and then see in the future what happens? I'm afraid of FS here.
I hear you... > > 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> > > hmmmm, hmmmm, hmmmm, I have FS alarms ringing all over the place in my > head, but I have several great examples of where having that would rock > the planet.... but still, I'm afraid of people going back adding > programmatical logic to the sitemap.... Actually I couldn't even think of programmatical logic people would want to stick into the sitemap when we have flowscript - but users tend to be very creative on things like that ;) But seriously - whether you call it FS or not... from a user's perspective it will not be understandable why he might use an internal pipeline in other src attributes in the sitemap but not on the script tag. Whether we think it's useful or more FS - we should even provide it for consistency reasons! ...just ask yourself what the user expects and if we really have reasons not to deliver this expectation... > ... but it would be *so* cool to have a Workflow definition language > created as markup and then having a pipeline that generates the > flowscript by XSLT transformation! hmmm... don't now if the detour into generating javascript is really that appealing :-/ > I know, I know, it smells of FS all around, but this would make it *so* > easy to be able to connect cocoon to existing workflow editing systems. hm... but that's an interesting idea!! > Gosh, I have to think about that. > > What do you people think? ...if we add resolving to the src attribute we have all options -- Torsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
