You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Giacomo Pati <Gi...@pwr.ch> on 2000/10/28 18:31:25 UTC
TODO List so far
Hy all
Here is my todo list I've collected so far.
- SiLLy (Simple Logicsheet Language)
Ricardo Rocha will soon release the work he has done so far
concerning SiLLy to CVS. SiLLys concerns are helping XSP
logicsheet writers with usual constructs to simplify the task
of writing XSP taglib writing. An additional benefit of its
use will be to generate consistent documentations out of it.
- Action-Chains (Sitemap Semantics)
As the discussion with Peter Donald has brought up the need
to chain Action has arised to fullfill application needs to
chain general Actions together. General Actions are the one
that are mostly needed in web app event handling (session
validation, form validation, form data saving, etc.)
- Resource Aggregation
Stefano has shown the need for internal Resource aggegation.
Discussion is still going on AFAIK how this will be achieved.
- Status, Profiling
Paul Russel has brought up a proposal how to obtain status
and profiling information out of the sitemap and it's
components. AFAIK discussion is still going on.
- TrAXTransformer
Sean Timm offered to write the TrAXTransformer to generalize
the use of XSL Transformation products.
- Cache Proposal
There has been a discussion many weeks ago about this topic.
We need to take up again to come to a conclusion. There has
been some thought about that from Russ Burton IIRC.
- Avalon-Integration
Berin Loritsch has IIRC already ported C2 to the new Avalon
release. Again, many thanks.
- SitemapModelComponent
Stefano pointed out that the use of the objectModel variable
in the Environment is too loose coupled. Discussion has to go
on about extending the Interface signatures from a "Map
objectModel" to "HttpRequest request, HttpResponse response,
Context context" to strength the contract between the
components and the Environment.
- URLHandlerFactory
The original proposal of the sitemap has used the notion of
URL to all resources used by it (classes, sources, etc.). The
absent of such a URLHandlerFactory and the fact that Javas
own system is not suitable for a Servlet to use has arised
the need of such a thing. Stefano pointed out that this is
something Avalon has to design and develop. But this will
take many weeks to be done, so we might discuss having an
alternative or stay with the system we have today.
- Documentation
Yes!
- Sequence of object initialisation
I've seen that the sequence how objects are initialized after
instantiation is not consequently respected. AFAIK there is
no written guide line from the Avalon project how this has to
be done. Federico stated in a discussion I had in the Avalon
list that the sequence should be "from inner to outer". This
means that a component should get it's configuration first
and the component manager after it (we do not use any other
interfaces from the Avalon project so far to initialize
Components). Also, Peter (on the Avalon list) has told me the
exact opposite (more or less). This tells me that *we* have
to agree on a sequence how this has to be happened and
control the code base to ensure that behaviour.
- Sitemap Management Tool
- Matcher/Action return type
Jon Stevens, project manager of the Turbine project,
mentioned to change the object type a Matcher/Action returns
to the sitemap engine from List to Map to be able to refer
those stings by name instead of numbers. This will not change
the behaviour of the Wildcard- and RegexpMatcher because
multiple Wildcards/Regexps are easily remembered as positions
in the pattern but other Matchers/Actions might not behave
like the former and it is not recognizable out of the pattern
and thus might be better addressed with names as with
positions. Please comment and vote on this issue.
- Moving sitemap component to cocoon.xconf
Peter Donald (Avalon) mentioned recently to move the
<map:components> section from the sitemap.xmap to the
cocoon.xconf file. This indeed would reduce the verbosity of
the sitemap but also will introduce some restrictions to the
design we have today. One restriction is that the concept of
the CodeFactory (direct integration of java code during the
sitemap generation stage) will not be possible anymore. Also
if someone uses many "custom" components to build up his URI
part its not been seen in "his" sitemap and the responsable
person of the cocoon.xconf file (usually a sysadmin) will
have to be contacted if new sitemap components have to be
integrated. Please discuss this as well.
So far these are the items I've collected during my break and the ApacheCon. I
know there might be others issues which are not listed above, so please stand up
and bring it into this discussion.
After we have collected all of them we will have to prioritize them and
categorize them to state which will be suitable for Beta 1.
Ok, let's start it.
Giacomo
--
PWR GmbH, Organisation & Entwicklung Tel: +41 (0)1 856 2202
Giacomo Pati, CTO/CEO Fax: +41 (0)1 856 2201
Hintereichenstrasse 7 Mobil: +41 (0)78 759 7703
CH-8166 Niederweningen Mailto:Giacomo.Pati@pwr.ch
Web: http://www.pwr.ch
Re: TODO List so far
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 15:37 -0500 30/10/00, Donald Ball wrote:
>>
>> Yes, but I thought some of you would at least had some comments to my
>>list or
>> give priorities which in your opinion should be given higher importance over
>> other issues (or at the best take responsability of one or the other
>>issue :)
>
>well, color me mostly responsible for porting the c1 logicsheets to c2.
>i'll help out debugging the xsp engine too.
>
>- donald
Hear Hear!
+1
Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
Re: TODO List so far
Posted by Donald Ball <ba...@webslingerZ.com>.
On Mon, 30 Oct 2000, Giacomo Pati wrote:
> > > - Comman line usage
> > > Vote on what mechanism should be implemented to prevent crawlers
> > > accessing not crawlable resources.
> > >
> > > - Porting C1 taglibs to C2
> > >
> > > - Any ideas of new needed sitemap components?
> > >
> > > Nobody else has any comments or additions?
> >
> > it's a good list. just need workers now, right? :)
>
> Yes, but I thought some of you would at least had some comments to my list or
> give priorities which in your opinion should be given higher importance over
> other issues (or at the best take responsability of one or the other issue :)
well, color me mostly responsible for porting the c1 logicsheets to c2.
i'll help out debugging the xsp engine too.
- donald
Re: TODO List so far
Posted by Giacomo Pati <Gi...@pwr.ch>.
Donald Ball wrote:
>
> On Mon, 30 Oct 2000, Giacomo Pati wrote:
>
> > I'd like to add these items
> >
> > - Redisign XSP Engine
> > Better adaption of the SAX model.
>
> any ideas for this? i think the current system is good, just needs some
> bug fixes.
The idea Ricardo had was to use a class similar to the ResourcePipeline class
which acts on the PI and manages the chain of logicsheet-transformers
dynamically. IIRC this would simplify the hole engine alot making many
abstractions and interfaces obsolet.
Ricardo, can you add something to this?
>
> > - Comman line usage
> > Vote on what mechanism should be implemented to prevent crawlers
> > accessing not crawlable resources.
> >
> > - Porting C1 taglibs to C2
> >
> > - Any ideas of new needed sitemap components?
> >
> > Nobody else has any comments or additions?
>
> it's a good list. just need workers now, right? :)
Yes, but I thought some of you would at least had some comments to my list or
give priorities which in your opinion should be given higher importance over
other issues (or at the best take responsability of one or the other issue :)
Giacomo
--
PWR GmbH, Organisation & Entwicklung Tel: +41 (0)1 856 2202
Giacomo Pati, CTO/CEO Fax: +41 (0)1 856 2201
Hintereichenstrasse 7 Mobil: +41 (0)78 759 7703
CH-8166 Niederweningen Mailto:Giacomo.Pati@pwr.ch
Web: http://www.pwr.ch
Re: TODO List so far
Posted by Donald Ball <ba...@webslingerZ.com>.
On Mon, 30 Oct 2000, Giacomo Pati wrote:
> I'd like to add these items
>
> - Redisign XSP Engine
> Better adaption of the SAX model.
any ideas for this? i think the current system is good, just needs some
bug fixes.
> - Comman line usage
> Vote on what mechanism should be implemented to prevent crawlers
> accessing not crawlable resources.
>
> - Porting C1 taglibs to C2
>
> - Any ideas of new needed sitemap components?
>
> Nobody else has any comments or additions?
it's a good list. just need workers now, right? :)
- donald
Re: TODO List so far
Posted by Giacomo Pati <Gi...@pwr.ch>.
I'd like to add these items
- Redisign XSP Engine
Better adaption of the SAX model.
- Comman line usage
Vote on what mechanism should be implemented to prevent crawlers
accessing not crawlable resources.
- Porting C1 taglibs to C2
- Any ideas of new needed sitemap components?
Nobody else has any comments or additions?
Giacomo
--
PWR GmbH, Organisation & Entwicklung Tel: +41 (0)1 856 2202
Giacomo Pati, CTO/CEO Fax: +41 (0)1 856 2201
Hintereichenstrasse 7 Mobil: +41 (0)78 759 7703
CH-8166 Niederweningen Mailto:Giacomo.Pati@pwr.ch
Web: http://www.pwr.ch
Re: TODO List so far
Posted by Stefano Mazzocchi <st...@apache.org>.
Giacomo Pati wrote:
I'd place the things that might trigger contract changes in M1, the rest
down the road.
> - SiLLy (Simple Logicsheet Language)
> Ricardo Rocha will soon release the work he has done so far
> concerning SiLLy to CVS. SiLLys concerns are helping XSP
> logicsheet writers with usual constructs to simplify the task
> of writing XSP taglib writing. An additional benefit of its
> use will be to generate consistent documentations out of it.
M1
> - Action-Chains (Sitemap Semantics)
> As the discussion with Peter Donald has brought up the need
> to chain Action has arised to fullfill application needs to
> chain general Actions together. General Actions are the one
> that are mostly needed in web app event handling (session
> validation, form validation, form data saving, etc.)
M1
> - Resource Aggregation
> Stefano has shown the need for internal Resource aggegation.
> Discussion is still going on AFAIK how this will be achieved.
M1
> - Status, Profiling
> Paul Russel has brought up a proposal how to obtain status
> and profiling information out of the sitemap and it's
> components. AFAIK discussion is still going on.
M2 or even 2.1, no impact on design.
> - TrAXTransformer
> Sean Timm offered to write the TrAXTransformer to generalize
> the use of XSL Transformation products.
M2, again, no impact on design.
> - Cache Proposal
> There has been a discussion many weeks ago about this topic.
> We need to take up again to come to a conclusion. There has
> been some thought about that from Russ Burton IIRC.
M1
> - Avalon-Integration
> Berin Loritsch has IIRC already ported C2 to the new Avalon
> release. Again, many thanks.
Done?
> - SitemapModelComponent
> Stefano pointed out that the use of the objectModel variable
> in the Environment is too loose coupled. Discussion has to go
> on about extending the Interface signatures from a "Map
> objectModel" to "HttpRequest request, HttpResponse response,
> Context context" to strength the contract between the
> components and the Environment.
M2, I'm ok for now.
> - URLHandlerFactory
> The original proposal of the sitemap has used the notion of
> URL to all resources used by it (classes, sources, etc.). The
> absent of such a URLHandlerFactory and the fact that Javas
> own system is not suitable for a Servlet to use has arised
> the need of such a thing. Stefano pointed out that this is
> something Avalon has to design and develop. But this will
> take many weeks to be done, so we might discuss having an
> alternative or stay with the system we have today.
Let's move this to avalon.
> - Documentation
> Yes!
Of course, but not before the contracts are ready.
> - Sequence of object initialisation
> I've seen that the sequence how objects are initialized after
> instantiation is not consequently respected. AFAIK there is
> no written guide line from the Avalon project how this has to
> be done. Federico stated in a discussion I had in the Avalon
> list that the sequence should be "from inner to outer". This
> means that a component should get it's configuration first
> and the component manager after it (we do not use any other
> interfaces from the Avalon project so far to initialize
> Components). Also, Peter (on the Avalon list) has told me the
> exact opposite (more or less). This tells me that *we* have
> to agree on a sequence how this has to be happened and
> control the code base to ensure that behaviour.
To avalon.
> - Sitemap Management Tool
2.1 or even further :)
> - Matcher/Action return type
> Jon Stevens, project manager of the Turbine project,
> mentioned to change the object type a Matcher/Action returns
> to the sitemap engine from List to Map to be able to refer
> those stings by name instead of numbers. This will not change
> the behaviour of the Wildcard- and RegexpMatcher because
> multiple Wildcards/Regexps are easily remembered as positions
> in the pattern but other Matchers/Actions might not behave
> like the former and it is not recognizable out of the pattern
> and thus might be better addressed with names as with
> positions. Please comment and vote on this issue.
Part of the action proposal (still M1)
> - Moving sitemap component to cocoon.xconf
> Peter Donald (Avalon) mentioned recently to move the
> <map:components> section from the sitemap.xmap to the
> cocoon.xconf file. This indeed would reduce the verbosity of
> the sitemap but also will introduce some restrictions to the
> design we have today. One restriction is that the concept of
> the CodeFactory (direct integration of java code during the
> sitemap generation stage) will not be possible anymore. Also
> if someone uses many "custom" components to build up his URI
> part its not been seen in "his" sitemap and the responsable
> person of the cocoon.xconf file (usually a sysadmin) will
> have to be contacted if new sitemap components have to be
> integrated. Please discuss this as well.
I'm fine with what we have right now.
> - Redisign XSP Engine
> Better adaption of the SAX model.
Part of XSP discussion.
> - Comman line usage
> Vote on what mechanism should be implemented to prevent crawlers
> accessing not crawlable resources.
Part of content aggregation.
> - Porting C1 taglibs to C2
M2 or even further... our main concern should be to stabilize the
architecture, modules, components and taglibs will be ported by the
people if we give them enough instructions and docs to do so and a solid
contract set to rely on.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Re: TODO List so far
Posted by Stefano Mazzocchi <st...@apache.org>.
Sylvain Wallez wrote:
>
> Hi folks,
>
> I had a few ideas while reading Giacomo's todo list that I wanted to
> share. I'm relatively new to Cocoon (3 months) and started to study C2
> only 2 weeks ago so forgive me if these ideas are not relevant, and if
> not please explain me why.
Sure thing.
> Giacomo Pati a écrit :
> >
> > Hy all
> >
> > Here is my todo list I've collected so far.
> >
>
> <snip/>
>
> > - Cache Proposal
> > There has been a discussion many weeks ago about this topic.
> > We need to take up again to come to a conclusion. There has
> > been some thought about that from Russ Burton IIRC.
> >
>
> A problem I think in both C1 (Modifiable) and C2 (Changeable) is that
> objects implementing these interfaces have no mean to say they will
> *always* change (volatile, no ergodic period). Don't know for C2, but in
> C1 (that was discussed recently on the list) the URL of an XSP is
> blocked while its content is produced to be put after in the cache. This
> is useless, since hasChanged() always returns true (unless you redefine
> it in the XSP), and has the additional bad side-effect of blocking
> concurrent requests to the same URL ! Also, I don't understand in which
> condition the C2 XSPGenerator modifiedSince() method can return false
> (it returns true if the XSP creation date is before the current date).
The C1 cache system is extremely poor in that detail (look at my inner
comments in Engine.java) and the behavior should be interface driven: if
the XSP doesn't want to be cached, it simply doesn't implement the
caching interfaces.
This was not possible before and this is the reason why XSP 1.1 will
have specific caching semantics. Ricardo will explain that in his paper.
> So can a new "isVolatile" method in "Modifiable" be the solution (if
> isVolatile, don't even try to cache it) ? What do you think about it ?
Nah, don't need that.. the cache will look if the generator/transformer
implements the cacheable interface and attemp to cache it if does,
otherwise do nothing and call it directly.
> Also, for objects that do have an ergodic period, I noticed in C1 that
> the cache key is the request URL and browser type. Don't we need a more
> generic mechanism based on the object model ? For example, I have some
> applications where XSPs can be cached on a per-session or per-user
> basis. Since I have no mean to express it, they're always regenerated.
> And I think this particular point will arise often with
> content-aggregation portal-like pages.
This is correct, the Cocoon caching interface should have access to the
whole object model so to allow perfect caching granularity.
The only problem with this approach is that caching the serialized
output becomes a configuration nightmare... more on this on my caching
proposal. stay tuned.
> >
>
> <snip/>
>
> > - Moving sitemap component to cocoon.xconf
> > Peter Donald (Avalon) mentioned recently to move the
> > <map:components> section from the sitemap.xmap to the
> > cocoon.xconf file. This indeed would reduce the verbosity of
> > the sitemap but also will introduce some restrictions to the
> > design we have today. One restriction is that the concept of
> > the CodeFactory (direct integration of java code during the
> > sitemap generation stage) will not be possible anymore. Also
> > if someone uses many "custom" components to build up his URI
> > part its not been seen in "his" sitemap and the responsable
> > person of the cocoon.xconf file (usually a sysadmin) will
> > have to be contacted if new sitemap components have to be
> > integrated. Please discuss this as well.
> >
>
> Regarding this point, why not use XInclude for the sitemap and xconf ?
> That would allow parts of their contents to be defined elsewhere.
Yes, I thought about that as well, but I don't see this as a big issue
right now.
> This suggestion comes from personal experience : some of our customers
> are big companies where people that are responsible for the installation
> and tunig in production environment (sysadmins) know nothing about the
> application. And these people like to have a single file that contains
> all runtime parameters they have to configure (JDBC info, LDAP server
> address, logins, etc). Also, mixing runtime information with structural
> information (definition and composition of components) in a single file
> can easily lead to application breakage if some structural information
> is accidentally changed when setting runtime parameters.
>
> Well, isn't that a kind of separation of concerns ? But the problem is
> that the elements that define these concerns heavily depend on the
> context : knowledge and responsibilitites of people, application,
> customer, etc. So I think using XInclude may be useful to achieve this
> separation in a modular fashion.
Totally agree, in fact, even Apache has an include directive in
httpd.conf and it's very useful.
+1 for adding XInclude semantics to the sitemap.
> > So far these are the items I've collected during my break and the ApacheCon. I
> > know there might be others issues which are not listed above, so please stand up
> > and bring it into this discussion.
> >
> > After we have collected all of them we will have to prioritize them and
> > categorize them to state which will be suitable for Beta 1.
> >
> > Ok, let's start it.
> >
>
> One additional item that was discussed recently : allowing classes
> produced from XSP to extend other classes than XSPGenerator. This would
> allow XSP to be used as a generic langage for XML generation in
> environments where a servlet context is not useful nor available
> (database connectors, legacy file transformation, etc) without
> reinventing the wheel and rewriting all the complicated java generation
> stuff.
Yes, XSP 1.1 will abstract completely on what is generated and dynamic
transformers will be available. True, this will greatly overlap with
XSLT, but I don't care, the users will define who wins.
> Hope you will find these suggestions usefull.
Totally, keep it up :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Re: TODO List so far
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Hi folks,
I had a few ideas while reading Giacomo's todo list that I wanted to
share. I'm relatively new to Cocoon (3 months) and started to study C2
only 2 weeks ago so forgive me if these ideas are not relevant, and if
not please explain me why.
Giacomo Pati a écrit :
>
> Hy all
>
> Here is my todo list I've collected so far.
>
<snip/>
> - Cache Proposal
> There has been a discussion many weeks ago about this topic.
> We need to take up again to come to a conclusion. There has
> been some thought about that from Russ Burton IIRC.
>
A problem I think in both C1 (Modifiable) and C2 (Changeable) is that
objects implementing these interfaces have no mean to say they will
*always* change (volatile, no ergodic period). Don't know for C2, but in
C1 (that was discussed recently on the list) the URL of an XSP is
blocked while its content is produced to be put after in the cache. This
is useless, since hasChanged() always returns true (unless you redefine
it in the XSP), and has the additional bad side-effect of blocking
concurrent requests to the same URL ! Also, I don't understand in which
condition the C2 XSPGenerator modifiedSince() method can return false
(it returns true if the XSP creation date is before the current date).
So can a new "isVolatile" method in "Modifiable" be the solution (if
isVolatile, don't even try to cache it) ? What do you think about it ?
Also, for objects that do have an ergodic period, I noticed in C1 that
the cache key is the request URL and browser type. Don't we need a more
generic mechanism based on the object model ? For example, I have some
applications where XSPs can be cached on a per-session or per-user
basis. Since I have no mean to express it, they're always regenerated.
And I think this particular point will arise often with
content-aggregation portal-like pages.
>
<snip/>
> - Moving sitemap component to cocoon.xconf
> Peter Donald (Avalon) mentioned recently to move the
> <map:components> section from the sitemap.xmap to the
> cocoon.xconf file. This indeed would reduce the verbosity of
> the sitemap but also will introduce some restrictions to the
> design we have today. One restriction is that the concept of
> the CodeFactory (direct integration of java code during the
> sitemap generation stage) will not be possible anymore. Also
> if someone uses many "custom" components to build up his URI
> part its not been seen in "his" sitemap and the responsable
> person of the cocoon.xconf file (usually a sysadmin) will
> have to be contacted if new sitemap components have to be
> integrated. Please discuss this as well.
>
Regarding this point, why not use XInclude for the sitemap and xconf ?
That would allow parts of their contents to be defined elsewhere.
This suggestion comes from personal experience : some of our customers
are big companies where people that are responsible for the installation
and tunig in production environment (sysadmins) know nothing about the
application. And these people like to have a single file that contains
all runtime parameters they have to configure (JDBC info, LDAP server
address, logins, etc). Also, mixing runtime information with structural
information (definition and composition of components) in a single file
can easily lead to application breakage if some structural information
is accidentally changed when setting runtime parameters.
Well, isn't that a kind of separation of concerns ? But the problem is
that the elements that define these concerns heavily depend on the
context : knowledge and responsibilitites of people, application,
customer, etc. So I think using XInclude may be useful to achieve this
separation in a modular fashion.
> So far these are the items I've collected during my break and the ApacheCon. I
> know there might be others issues which are not listed above, so please stand up
> and bring it into this discussion.
>
> After we have collected all of them we will have to prioritize them and
> categorize them to state which will be suitable for Beta 1.
>
> Ok, let's start it.
>
One additional item that was discussed recently : allowing classes
produced from XSP to extend other classes than XSPGenerator. This would
allow XSP to be used as a generic langage for XML generation in
environments where a servlet context is not useful nor available
(database connectors, legacy file transformation, etc) without
reinventing the wheel and rewriting all the complicated java generation
stuff.
Hope you will find these suggestions usefull.
-Sylvain