cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <>
Subject Re: [control flow] changes and new sample
Date Sun, 08 Sep 2002 05:09:57 GMT

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 ( 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)

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 <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.

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 

What I'm instead working on is a simpler setup, like this:

<map:flow language="JavaScript">
   <map:script src="prefs.js"/>
   <map:script src="some-other-script.js"/>

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 <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.

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 
<map:call> would make sense only when multiple flow, e.g. Controllers 
are permitted. Which smells too much of FS.

> 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.

As Vadim noted in his reply, we already decided on this in,

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 <> (Weblog) (Apache, GNU, 
Emacs ...)

To unsubscribe, e-mail:
For additional commands, email:

View raw message