Stefano Mazzocchi wrote: >Ovidiu Predescu wrote: > >[lots of good stuff removed] > > > >>In a perfect world, >>XSP should have only one logicsheet, the JXPath logicsheet. There >>should be no other things in an XSP page that put logic in the page >>(read View), instead of the Model. If you don't like XSP, and prefer to >>use JSP or Velocity, the JXPath logicsheet equivalents should be >>implemented. >> >> > >I keep having the impression that using Velocity as the view layer will >be the best choice for a number of reasons. In case you have a few spare >cycles, please consider investing them there. > > > >>Basic usage >>=========== >> >>As hinted in the previous section, an application using Cocoon's MVC >>approach is composed of three layers: >> >>- a JavaScript controller which implements the interaction with the >>client >> >>- the business logic model which implements your application >> >> > >One comment on this part: I would remove the 'static' part from >UserRegistry. I know this is just an example of use, but it would be >*much* more useful to show a patter of use of the technology that could >be adopted in other realms and if we suggest to get a hold on java >objects via getting a static reference, we are simply dooming our users >to a land of despair and pain later on. > > > >>- 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? > >This is very important: the concepts of sitemap and flowscripts were >defined *exactly* to allow somebody to *understand* what's going on >simply by looking at these central blueprints of your webapp. If >something is made implicit (like the login.xsp -> login.html resource >generation) we are totally loosing he concept up front. If a *.html >matching pipeline is inherited from a sitemap above, the examples should >make it explicit. Instead, if the XSP -> HTML pipeline has been somewhat >hardcoded in the flow engine, *PLEASE*, consider removing it alltogether >in favor of something more explicit. > > > >>The thing I'm going to work on next is a user feedback for >>documentation which uses this MVC pattern. Jeff Turner and I are >>planning to use this system as the documentation system for Anteater. >>For this I want to use OJB (http://jakarta.apache.org/ojb/) to map >>database tables to Java objects, so I can implement a clean Model >>layer. This is a more realistic example, which will hopefully showcase >>the ease of use of this MVC approach. >> >>Future plans include writing a WikiWiki application and a Weblog tool >>using the same patterns. I think these would be real killer >>applications for Cocoon with MVC. >> >>As usually, I appreciate any comments and feedback you have on the >>above. >> >> > >The above is *very* cool and exiting, but I still have a few comments on >the sitemap-flowscript integration which, IMO, should be solved before >making a 2.1 release. > >
<snip/> >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. > >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. > I thought we kinda agreed on http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102454393731251&w=2, thing is nobody had enough time to make it reality. Vadim >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. > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
