Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 85299 invoked by uid 500); 8 Sep 2002 05:09:47 -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 85288 invoked from network); 8 Sep 2002 05:09:47 -0000 Date: Sat, 7 Sep 2002 22:09:57 -0700 Subject: Re: [control flow] changes and new sample Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) Cc: Christopher Oliver To: cocoon-dev@xml.apache.org From: Ovidiu Predescu In-Reply-To: <3D79E75F.D736F976@apache.org> Message-Id: <37CCE854-C2E9-11D6-9874-00039398D61E@apache.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.543) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Saturday, September 7, 2002, at 04:47 AM, 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. 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. >> 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. 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. >> - 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. > 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. As I said above, there's no hardcoding whatsoever. We just need to place a note in the subsitemap indicating where the html translation takes place. >> 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) 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. > 2) is the 'flow' really a ? > > I don't think so. A flow is a flow. This calls for a more explicit: > > > > language="scheme"/> > > > 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. What I'm instead working on is a simpler setup, like this: 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. > 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. 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 would make sense only when multiple flow, e.g. Controllers are permitted. Which smells too much of FS. > 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. 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. Best regards, -- Ovidiu Predescu http://webweavertech.com/ovidiu/weblog/ (Weblog) http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, Emacs ...) --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org