cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [C2] XSP based Action
Date Mon, 30 Apr 2001 13:02:34 GMT
Jeremy Quinn wrote:
> 
> At 2:00 PM -0400 19/4/01, Berin Loritsch wrote:
> >Jeremy Quinn wrote:
> 
> >> When I get back, I start work writing our new Crudlet 2.0 TagLib, the first
> >> thing I'll be asking advice about, will be ....
> >>
> >>         What is the best way to write the XMLFragment implementing support
> >> objects for a TagLib so that you do not have to write output code for both
> >> DOM and SAX?
> >>
> >>         As Cocoon 2 is the future, it makes sense to me to "natively"
> >>output SAX
> >> Events, and have some sort of "adapter" to capture the events and convert
> >> them to DOM for output to Cocoon 1. (the opposite of DOMStreamer?)
> >>
> >>         Does this make sense?
> >>
> >>         Is it possible?
> >
> >Is this something you can accomplish using <xsp:element> and <xsp:attribute>?
> >If that is the case, then let Cocoon do the hard work for you.
> 
> Hi Berin,
> 
> Thanks for the reply, I've just got back .....
> 
> It is just too complex, I think it would be possible if I only had Simple
> Properties but I have to be able to recurse through Beans and their
> Composite Properties (Beans that contain Beans) etc, building XML that
> represents the Bean/Property structure.
> 
> Any other suggestions?

It's been a while, so I will venture this approach that I have used:

I have my beens implement an XMLizable interface that has two methods:

interface XMLizable {
    String toXML();
    void toSAX(ContentHandler handler);
}

If a bean has a child bean, they use Cocoon's contenthandler for includes
(strips start and end document events).  This ensures that every bean is
represented in a clear and consistent manner--no matter the context.

The reason for the two methods is that when you are communicating over a
wire (i.e. EJB), SAX is too costly.  Otherwise, SAX is the preferred method,
and is directly embeddable in Cocoon.

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


Mime
View raw message