cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <vadim.gritse...@verizon.net>
Subject Re: [control flow] changes and new sample
Date Sat, 07 Sep 2002 21:03:06 GMT
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message