cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@apache.org>
Subject RE: Refactoring back to Avalon
Date Tue, 19 Mar 2002 13:54:49 GMT


> -----Original Message-----
> From: Gonzalo A. Diethelm [mailto:gonzalo.diethelm@aditiva.com] 
> Sent: Tuesday, March 19, 2002 8:06 AM
> To: cocoon-dev@xml.apache.org
> Subject: Refactoring back to Avalon
> 
> 
> Hi, first post in this list.
> 
> I have been looking into adding some basic functionality
> to Avalon, such as:
> 
> a) session management
> b) upload of files
> c) parameter passing (URL? POST? hidden variables?)
> d) error handling

These are all servlet specific things.  It is not general enough
For Avalon Excalibur.

> 
> I understand Cocoon uses Avalon concepts to an extent, and 
> maybe even uses Avalon (Excalibur) components. I can also see 
> how some (all?) of this functionality may already be part of 
> Cocoon. I would really like to take a look into refactoring 
> those parts out of Cocoon and into Avalon. My questions:

Yes, Cocoon uses Avalon components and is built on Avalon
Concepts.  Things have gotten a little muddy with the proliferation
Of component types in Cocoon, but Cocoon is very much founded
On Avalon concepts (not just to an extent).

> 
> 1. Is my understanding correct, that Cocoon uses Excalibur
>    components in its implementation?

Yes.  DataSources, XML Parser, Xpath Processor, etc.

> 2. If yes, are the parts of Cocoon that implement any/all of
>    (a)-(d) above, written as Excalibur components?

Not the ones you listed.  The problem is that the domain that
Is addressed by those things are not general purpose enough
To use in a wide range of servers

> 3. Is anybody looking into refactoring this functionality and
>    porting it back into Avalon?

Not that particular functionality, but several components in
Excalibur started in Cocoon and have been ported back.

> 4. If this refactoring is done (and done properly), would the
>    Cocoon project consider changing Cocoon to use those
>    Excalibur components instead of the Cocoon 
> implementations? 5. Is there anything else that should be 
> considered a candidate
>    to be moved into Excalibur?

We have looked into these things in the past.  We are looking
to move the XML processor abstractions, but not the Transformer,
Generator, Serializer, et. al. interfaces.


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


Mime
View raw message