CastorTransformer and CastorSourceConverter

[Reinhard Pötz <re...@gmx.net>]

In the scratchpad we have a CastorTransformer. I'm not sure but I think
that it is a rather long time there. Is it in use and stable and is it
time to move it in the main trunk or can we remove it.

I also found a CastorSourceConverter in the portal framework. What are
the differences? Can they be unified?

Cheers,
Reinhard


-----Original Message-----
From: Tony Edwards [mailto:TEdwards@civica.com.au] 
Sent: Wednesday, July 16, 2003 1:16 AM
To: 'users@cocoon.apache.org'
Subject: RE: Beans as input for cocoon


I'm using the Castor transformer to convert a large, nasty bean into xml
and then into HTML/PDF. 
It works really well, seems fast (the slowest bit is the bean accessing
the database to get its data) and best of all it manages to convert all
ArrayLists and other complex types.
I initially use an XSP action to instantiate the bean and connect to the
datasource and populate the bean, then I pass this though the Castor
Transformer. I use the same mapping file that comes with the example
because the bean is so huge it would take too long to even come up with
a mapping file but Castor ignores all mappings it can't find or aren't
there and outputs elements based on the Bean field names. Excellent!
Tony 


-----Original Message----- 
From: Alexander Schatten [mailto:alasan@gmx.at] 
Sent: Wednesday, 16 July 2003 1:29 AM 
To: users@cocoon.apache.org 
Subject: Re: Beans as input for cocoon 


Uwe Gerger wrote: 
>Hello, 
>we have some Java-beans wich contains the data we wish to transform
with 
>cocoon into PDF. Is there a way how we can get the data from the bean 
>into cocoon? Maybe there is a special bean-transformer or something
like 
>this? 
> 
>  
> 
Hm, a BeanGenerator could be a nice idea? but where would this bean get 
the data from? it would be initialized by the generator, so is "empty"; 
off course you could read a file or something in the bean constructor or

access a database; but for both things there seem to be more elegant 
options. 
in fact you can access beans from within XSP scripts or actions, maybe 
this is a convenient solution. 


alex 



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

RE: CastorTransformer and CastorSourceConverter

[Carsten Ziegeler <cz...@s-und-n.de>]

Stephan Michels wrote:
>
>
> Okay, then yet-another-block ;-)
>
> I can also provide some components for Castor. We should really consider
> to move the 'blocks' into an own CVS repository.
>
> Similar to Avalon?
>
Whatever we decide, we should wait until we have released 2.1; otherwise we
would
run into problems with the distribution of 2.1.

Carsten

RE: CastorTransformer and CastorSourceConverter

[Stephan Michels <st...@apache.org>]

On Fri, 18 Jul 2003, Carsten Ziegeler wrote:

> Stephan Michels wrote:
> >
> >
> > Same from me, can we move the CastorSourceConverter into the main tree,
> > and also the CastorTransformer? They are very useful in my current
> > application.
>
> No, please not into the main trunk, it's already overcrowded with things
> that don't belong to the core.
> Now making an own block out of it seems not to be the best idea; we already
> have many (too many) small blocks consisting of only a single class.
> Now, what about making an "additional" blocks and moving things there?
> This is the e.g. the way ant does it with additional tasks.

Okay, then yet-another-block ;-)

I can also provide some components for Castor. We should really consider
to move the 'blocks' into an own CVS repository.

Similar to Avalon?

Stephan.

RE: CastorTransformer and CastorSourceConverter

[Carsten Ziegeler <cz...@s-und-n.de>]

Stephan Michels wrote:
> 
> 
> Same from me, can we move the CastorSourceConverter into the main tree,
> and also the CastorTransformer? They are very useful in my current
> application.

No, please not into the main trunk, it's already overcrowded with things
that don't belong to the core.
Now making an own block out of it seems not to be the best idea; we already
have many (too many) small blocks consisting of only a single class.
Now, what about making an "additional" blocks and moving things there?
This is the e.g. the way ant does it with additional tasks.

> 
> BTW, shouldn't it called
> org/apache/cocoon/components/persistence
> instead of
> org/apache/cocoon/components/persistance
> 
Yepp :)

Carsten

RE: CastorTransformer and CastorSourceConverter

[Stephan Michels <st...@apache.org>]

On Wed, 16 Jul 2003, Carsten Ziegeler wrote:

> Reinhard Pötz wrote:
> >
> > In the scratchpad we have a CastorTransformer. I'm not sure but I think
> > that it is a rather long time there. Is it in use and stable and is it
> > time to move it in the main trunk or can we remove it.
> >
> > I also found a CastorSourceConverter in the portal framework. What are
> > the differences? Can they be unified?
> >
> I don't now the CastorTransformer, but the CastorSourceConverter. The
> converter
> is an avalon component that "converts" io streams from and to java objects.
> So, you can read an xml file using castor and get the mapped objects and
> vice
> versa. I guess, this is a more general approach then the transformer.
>
> In general, I guess as well that they can somehow be unified, e.g. the
> transformer
> could use the source converter.
> I think there is also a patch for the transformer in bugzilla.

Same from me, can we move the CastorSourceConverter into the main tree,
and also the CastorTransformer? They are very useful in my current
application.

BTW, shouldn't it called
org/apache/cocoon/components/persistence
instead of
org/apache/cocoon/components/persistance

?


Stephan.

RE: CastorTransformer and CastorSourceConverter

[Reinhard Pötz <re...@gmx.net>]

From: Carsten Ziegeler

> Reinhard Pötz wrote:
> >
> > In the scratchpad we have a CastorTransformer. I'm not sure but I 
> > think that it is a rather long time there. Is it in use and 
> stable and 
> > is it time to move it in the main trunk or can we remove it.
> >
> > I also found a CastorSourceConverter in the portal 
> framework. What are 
> > the differences? Can they be unified?
> >
> I don't now the CastorTransformer, but the 
> CastorSourceConverter. The converter is an avalon component 
> that "converts" io streams from and to java objects. So, you 
> can read an xml file using castor and get the mapped objects 
> and vice versa. I guess, this is a more general approach then 
> the transformer.
> 
> In general, I guess as well that they can somehow be unified, 
> e.g. the transformer could use the source converter. I think 
> there is also a patch for the transformer in bugzilla.

Thank you Carsten!

Cheers,
Reinhard

RE: CastorTransformer and CastorSourceConverter

[Carsten Ziegeler <cz...@s-und-n.de>]

Reinhard Pötz wrote:
>
> In the scratchpad we have a CastorTransformer. I'm not sure but I think
> that it is a rather long time there. Is it in use and stable and is it
> time to move it in the main trunk or can we remove it.
>
> I also found a CastorSourceConverter in the portal framework. What are
> the differences? Can they be unified?
>
I don't now the CastorTransformer, but the CastorSourceConverter. The
converter
is an avalon component that "converts" io streams from and to java objects.
So, you can read an xml file using castor and get the mapped objects and
vice
versa. I guess, this is a more general approach then the transformer.

In general, I guess as well that they can somehow be unified, e.g. the
transformer
could use the source converter.
I think there is also a patch for the transformer in bugzilla.

Carsten