cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [control flow] changes and new sample
Date Sun, 08 Sep 2002 15:50:55 GMT
Ovidiu Predescu wrote:

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

Please do.

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

Ok, sounds good.
 
> >> - 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.

Yes, most definately.

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

My point is: since the flow engine is become part of the sitemap
semantics, I think it's wrong to need to specify <flow-interpreter> in
the <components> space.

I think 'flow' should be part of the sitemap just like <components> or
<resources>: something that cannot be removed, a first-class citizen of
the sitemap because it completes it.
 
> > 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
> follow.

That's a good point.

> 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"/>
> </map:flow>
> 
> 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.

I like this approach better, I agree. +1 from me.

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

Agreed.

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

Ok, I'll try to come up with a summary of the things to do and post them
here for a formal vote (and to show people exactly what is left to do on
this side of things).

-- 
Stefano Mazzocchi                               <stefano@apache.org>
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message