cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Ball <ba...@webslingerZ.com>
Subject Re: Cocoon 2.0: proposed battleplan
Date Sun, 09 Apr 2000 20:26:06 GMT
On Sat, 8 Apr 2000, Pierpaolo Fumagalli wrote:

> Ok kids... Since I've seen no -1 to my suicidal decision to "take over"
> this project :) and, actually, I got a lot of feedback on that, here's
> the "battle plan" for the next release of Cocoon 2.0
> 
> Please comment, add, modify, revise, do whatever you want with this, and
> say if you're interested in taking care of a certain part (and if you
> have time :)

Great job, Pier. Sorry I've been rather absent recently, I've been
learning all about linux virtual server services. whee.

> Cocoon 2.0 Beta Battle Plan (Deadline: JavaONE 2000)
> ----------------------------------------------------
> 
> The first things to define are what components are going to be
> integrated into the "standard" Cocoon distribution, and so need to be
> ready for the release, and wich ones are to be considered as "addition"
> or plug-ins, and so can go on with proprietary schedules.
> 
> G) Filters:
>    - XSLT Filter (based on XALAN)
>    - TRAX Filter (used as a pluggability API, TRAX can access different
>      filters, depending on the configuration)
>    - XSP Taglib Filter

I was, and am, working on an XInclude Filter... I think it's likely to be
useful enough to merit inclusion in the main engine. Currently I'm trying
to figure out if one can do xpath with SAX or if I need to build a DOM
tree if the xinclude's xpointer includes an xpath expression.

Is TRAX far enough along that we can link against it now?

> E) Serializers:
>    - XML bare serializer
>    - HTML bare serializer

I vote to reuse Assaf's serializers if at all possible; the less duplicate
code in the ASF the better.

> Other components that are scheduled to be "plug ins" are (names are 
> the ones associated with the person who proposed the addition):
> 
> - Printing (Ugo Corda)
>     Pier said: "That's a hell-a-good idea... I'd like to investigate
>                further on it. Can it be done as a filter nesting a
>                serializer?"
> 
> - Oracle PLSQL Producer (Marcelo Ochoa)
>     Stefano said: "Can this be generic enough or it will be always tied
>                   only to Oracle?"
>   
> - Turbine-Like Generator: (Giacomo Pati) 
>     Still need some feedback on this.
> 
> - XForms (Gerard van Enk)
>     Geremy said: "Maybe this should developed as a taglib"
>     Pier said: "I roughly looked at the spec, but I really don't
>                understand what we should do to make those work (what do
>                you want to do with the data obtained from the form?)"
> 
> - XLink (Gerard van Enk)
>     Pier said: "I don't see how XLink can work on the server side"

The generic SQL filter is already checked into CVS and works quite nicely.

- donald


Mime
View raw message