cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [control flow] changes and new sample
Date Sat, 07 Sep 2002 11:47:43 GMT
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 ( 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"

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

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

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

View raw message