Ovidiu Predescu wrote: > Christopher Oliver sent me a patch for enabling Velocity as the View > layer. I need to get back to it one of these days. I'll post it on the > mailing list shortly, maybe somebody else has the time to work on it.
Please do. > As you say, this is just an example. One could replace the static call > with anything else, JNDI lookup, Avalon component lookup etc. I don't > think I'm going to extend this example further. Instead I'll try to > develop some real applications; right now I'm working on an application > to collect and display user feedback for online documentation, similar > to what PHP has. This will have a different way to connect to the > business logic than the above. Ok, sounds good. > >> - the XSP pages, which describe the content of the pages, and XSLT > >> stylesheets which describe the look of the content. > > > > Question: in the flow layer you are calling 'login.html' and this > > automagically becomes an html page after the execution of the XSP page > > and a XSLT transformation. But where is this set? > > The html transformation is done in the parent sitemap, since it's > common to all the samples. It's also a bit complex to duplicate on each > sitemap for every example. Perhaps a note in the sample's sitemap would > make things clearer. Yes, most definately. > > 1) if the flow interpretation is part of the sitemap semantics, don't > > you think that having a flow interpreter as a component is using the > > 'overcomponentization' anti-pattern? > > > > I think so. The flow interpreter is not a sitemap component, but an > > avalon component. This means that its declaration should *NOT* reside > > on > > <map:components> but somewhere on cocoon.xconf. > > > > This makes the user have a stronger perception of integration between > > the sitemaps (URIs) and the flows (transitions between URIs) > > What do you mean? The flow interpreter is an avalon component, it's > described in cocoon.xconf. Checkout the flow.xconf file, it finds its > way in cocoon.xconf during the build process. My point is: since the flow engine is become part of the sitemap semantics, I think it's wrong to need to specify <flow-interpreter> in the <components> space. I think 'flow' should be part of the sitemap just like <components> or <resources>: something that cannot be removed, a first-class citizen of the sitemap because it completes it. > > 2) is the 'flow' really a <map:resource>? > > > > I don't think so. A flow is a flow. This calls for a more explicit: > > > > <map:flows default-language="javascript"> > > <map:flow name="prefs" src="prefs.js"/> > > <map:flow name="something-else" src="something.scm" > > language="scheme"/> > > </map:flows> > > > > which allows: > > > > - to declare more scripts (this eases aggregation of different > > webapps, > > will be useful for blocks) > > - to map them to different interpreting engines based on their > > language. > > I remember this being discussed some time ago. I think the ability to > describe multiple flows in one sitemap is nothing else than FS. A flow > is usually associated with a complete application. Having multiple > flows is a complication which may makes things harder to write and > follow. That's a good point. > What I'm instead working on is a simpler setup, like this: > > <map:flow language="JavaScript"> > <map:script src="prefs.js"/> > <map:script src="some-other-script.js"/> > </map:flow> > > The idea here is that we have a Cocoon Web application described in the > current sitemap, whose flow is described in multiple script files. > Again, make no mistake, flow in this context is not a simple sequence > of pages, but it describes the whole application. E.g. a map:flow > element describes all the scripts that compose the Controller. I like this approach better, I agree. +1 from me. > > 3) are <map:call> and <map:continue> semantically correct? > > > > I'm not really sure. I personally like them but there is a semantic > > conflict between the use of <map:call> to call a resource but I don't > > think this is so confusing because, in fact, both indicate a jump into > > another point of the webapp. > > > > But if we can have more than one flow, we have to explicitly identify > > which one we want to call. > > > > <map:call flow="prefs" function="login"/> > > > > where it's evident that if the sitemap has only one flowscript > > declared, > > the call falls implicitly on that one. > > As I said, I don't think we should have the notion of multiple > Controllers in the same sitemap. A (sub-)sitemap should define exactly > one Cocoon Web application. Specifying the flow name as in the above > <map:call> would make sense only when multiple flow, e.g. Controllers > are permitted. Which smells too much of FS. Agreed. > > I have no problems for <map:continue with="...">: I also think that > > needing to explicitate the continuation-passing URI gives some more > > awareness of the 'magic' behind the thing which might be a steeper > > learning curve for new users, but might result in a more confortable > > plateaux of use later. Which follows Cocoon's style. > > > > Ok, I'd like to hear your comments before asking for a vote on the > > change of the sitemap markup to accomodate the issues I outlined above. > > As Vadim noted in his reply, we already decided on this in > > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102454393731251&w=2, > > Vadim's proposal at that time still holds, I couldn't think of a better > alternative. It's simple enough to implement as well, so if anybody has > some spare time to implement it, would be great. Ok, I'll try to come up with a summary of the things to do and post them here for a formal vote (and to show people exactly what is left to do on this side of things). -- Stefano Mazzocchi <[EMAIL PROTECTED]> -------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
