cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: TODO List so far
Date Tue, 31 Oct 2000 10:03:00 GMT
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.

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

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.


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

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

View raw message