cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <ovi...@apache.org>
Subject Re: [status & RT] design challenges
Date Mon, 08 Apr 2002 17:27:01 GMT
On Mon, 08 Apr 2002 13:41:16 +0200, Sylvain Wallez <sylvain.wallez@anyware-tech.com>
wrote:

> Stefano Mazzocchi wrote:
> 
> >Ovidiu Predescu wrote:
> >
> >>They already live together!
> >>
> >
> >Ok, but what I want is:
> >
> > 1) merge 'schecoon' with the trunk
> >
> > 2) have the ability to mount a 'flowmap' into a 'sitemap' and a
> >'sitemap' into a 'flowmap'.
> >
> >Until I have this, they are not living together in my book.

Um, I can see how a sitemap can make use of a flow script, but what
does it mean for a flow script to "mount" a flow script?

Right now when a flow script wants to generate a response page, it
just passes the control to the sitemap which renders the output
page. The only change to the sitemap contract is that the flow script
adds two more attributes to the Environment object: one which
represents the business object data whose attributes can be queried
during generation phase, and the continuation object, which can be
asked for its identifier, to be placed in links or form action that
want to come back.

> >Now, I'll be in favor of 'branching the CVS module' to keep the '2.0.x'
> >series clean and start moving stuff from the scratchpad into the trunk
> >and name that 2.1-dev
> >
> >I want more visibility for what currently lies in the scratchpad because
> >I think that currently Schecoon is an 'internal fork' and I personally
> >don't consider it *working* in Cocoon until the two things are merged
> >together.
> >
> >What do you think?
> >
> 
> I think there's been a long time since you looked at what's in 
> scratchpad/schecoon ;)
> 
> Seriously : schecoon *was* a kind of internal fork when it was a 
> scheme-only reimplementation of the sitemap engine. But Ovidiu has 
> rewrote the whole thing since there are continuations in Rhino. It's now 
> "just" a couple of new components and treeprocessor nodes. Integration 
> with the main trunk requires only a few lines to be added to 
> cocoon.roles and treeprocessor-builtins.xml !

I agree with Sylvain here. Schecoon is now completely redesigned and
it's a very simple task to merge it in the main trunk.

Having said that, I think we can keep things simple if we merge
directly on the main branch. And rather than creating a branch for the
2.1 release, I think it's better if we create a branch for the 2.0.x
release, which should allow us to fix bugs and make minor
releases. This way people doing development and casual expert users
get exposed to the new things without having to do any magic with CVS.

Also, before merging Schecoon on the main trunk, I'd like to fix some
bugs, the most important being the ExcaliburComponentManager, which
prevents the code from running :-(

Regards,
-- 
Ovidiu Predescu <ovidiu@apache.org>
http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff)

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


Mime
View raw message