On Sun, 24 Jun 2001, Mircea Toma wrote:
>
> ----- Original Message -----
> From: "giacomo" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> 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.
Ok, so you are by far more familiar with Castor then I am. Sorry to
spream information that doesn't correspond to the reality.
Giacomo
>
> > 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: [EMAIL PROTECTED]
> > For additional commands, email: [EMAIL PROTECTED]
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
