Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 90390 invoked by uid 500); 7 Sep 2002 18:25:25 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 90379 invoked from network); 7 Sep 2002 18:25:24 -0000 Message-ID: <3D79E75F.D736F976@apache.org> Date: Sat, 07 Sep 2002 13:47:43 +0200 From: Stefano Mazzocchi X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: [control flow] changes and new sample References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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 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 ? I don't think so. A flow is a flow. This calls for a more explicit: 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 and semantically correct? I'm not really sure. I personally like them but there is a semantic conflict between the use of 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. 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 : 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 -------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org