cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mircea Toma" <mirceat...@home.com>
Subject Re: [RT] Alternative Solution to XSP
Date Sun, 24 Jun 2001 18:09:38 GMT

----- Original Message -----
From: "giacomo" <giacomo@apache.org>
To: <cocoon-dev@xml.apache.org>
Sent: Sunday, June 24, 2001 10:42 AM
Subject: Re: [RT] Alternative Solution to XSP


> On Sun, 24 Jun 2001, Piroumian, Konstantin wrote:
>
> > Hi!
> >
> > <skip>
> > > > sounds like an interesting technique. how do you insert the business
> > > > objects into the cocoon sax pipeline? e.g. from an xsp page, a
> > generator,
> > > > a transformer, what?
> > >
> > > From an XSP page:
> > >
> > >   <page>
> > >     <xsp:logic>
> > >       Unmarshaller.unmarshal(this.contentHandler, businessObj);
> > >     </xsp:logic>
> > >   </page>
> >
> > So, you might have some mapping between businessObj and resulting XML?
Do
> > you use something like Exolab's Castor for that or you have implemented
your
> > own technic? Marshalling and unmarshalling requires heavy usage of
> > reflection API and it's not very effective for the performance.
>
> No, we use XML Schema to describe our business objects whereas Castor
> uses its own format.

That's not true! Castor has beside the object to relational mapping a
"Source Builder" that does exactly that, compiles a XMLSchema to a Java
class and instances of this class know how to marshall and unmarshall
themselves!

> And no, our toollkit doesn't need reflection
> because the generated business objects contains all information needed
> to be serialized in a performant way.
>
> > XMLizable interface can be better in some cases - when the object itself
> > knows how to represent itself in XML format, but it requires more work
with
> > every object and is more difficult to maintain it - changing a name of
an
> > attribute will require recompilation of the object.
>
> That's what a toolkit should be able to do. Generate the
> XMLizable methods as well out from the XML Schema definition.
>
> >
> > It seems that problems are alsmost the same everywhere, as well as the
> > solutions... :)
>
> Do you still think so?
>
> Giacomo
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


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


Mime
View raw message