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. 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) 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. 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. 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. -- Stefano Mazzocchi <[EMAIL PROTECTED]> -------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
