You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Poetz <re...@apache.org> on 2003/09/26 14:59:35 UTC
Castor support in Cocoon (was: Building cocoon: where are block descriptions?)
> PS Speaking of which, can somebody enlighten me as to why the
> CastorTransformer still is part of the scratchpad
> block. And what would it take to move it to its separate block ?
I remember we already discussed this before 2.1 was released and we said
that we didn't want a block so short before the release.
Secondly, the new portal stuff uses Castor too and the two approaches
should be unified.
Carsten, do you have any suggestions (I think it was you who suggested
this).
Werner, if you have time create the new 'castor block', just do it. If
you like we can do it together (IRL).
Reinhard
Re: Castor support in Cocoon (was: Building cocoon: where are block descriptions?)
Posted by Werner Guttmann <we...@gmx.net>.
Well,
I'd be curious to learn what unification could and should take place ... and how the portal uses Castor. Apart from this, I
cannot see why I should not try to 'blockify' the CastorTransformer ;-).
Well, if somebody points me to documentation about how to go about this ? Is there a recipe that one could follow ?
Excuse my ignorance, but so far I've been viewing Cocoon mainly from the user side of things ...
Werner
On Fri, 26 Sep 2003 14:59:35 +0200, Reinhard Poetz wrote:
>> PS Speaking of which, can somebody enlighten me as to why the
>> CastorTransformer still is part of the scratchpad
>> block. And what would it take to move it to its separate block ?
>
>I remember we already discussed this before 2.1 was released and we said
>that we didn't want a block so short before the release.
>
>Secondly, the new portal stuff uses Castor too and the two approaches
>should be unified.
>Carsten, do you have any suggestions (I think it was you who suggested
>this).
>
>Werner, if you have time create the new 'castor block', just do it. If
>you like we can do it together (IRL).
>
>Reinhard
>
RE: Castor support in Cocoon (was: Building cocoon: where are block descriptions?)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Reinhard Poetz wrote:
>
> > From: Carsten Ziegeler
> >
> > Reinhard Poetz wrote:
> > >
> > > > PS Speaking of which, can somebody enlighten me as to why the
> > > > CastorTransformer still is part of the scratchpad
> > > > block. And what would it take to move it to its separate block ?
> > >
> > > I remember we already discussed this before 2.1 was released and we
> > > said that we didn't want a block so short before the release.
> > >
> > > Secondly, the new portal stuff uses Castor too and the two
> > approaches
> > > should be unified. Carsten, do you have any suggestions (I think it
> > > was you who suggested this).
> > >
> > Hmm, I'm not sure if I suggested this...weak memory.
> > But the portal uses a persistence component (persistent the
> > portal profile in an xml doc and vice versa) and this
> > component uses Castor. This is a general component which
> > perhaps could be used from the
> > transformer?
>
> Yep, I think this is what you've proposed.
>
> So we can put the complete castor stuff into a new 'castor' block,
> containing the transformer and the "persistence component" and maybe a
> generator. The new portal block will then depend on this castor block.
> Is this okay for you?
>
Yes.
Carsten
RE: Castor support in Cocoon (was: Building cocoon: where are block descriptions?)
Posted by Reinhard Poetz <re...@apache.org>.
> From: Carsten Ziegeler
>
> Reinhard Poetz wrote:
> >
> > > PS Speaking of which, can somebody enlighten me as to why the
> > > CastorTransformer still is part of the scratchpad
> > > block. And what would it take to move it to its separate block ?
> >
> > I remember we already discussed this before 2.1 was released and we
> > said that we didn't want a block so short before the release.
> >
> > Secondly, the new portal stuff uses Castor too and the two
> approaches
> > should be unified. Carsten, do you have any suggestions (I think it
> > was you who suggested this).
> >
> Hmm, I'm not sure if I suggested this...weak memory.
> But the portal uses a persistence component (persistent the
> portal profile in an xml doc and vice versa) and this
> component uses Castor. This is a general component which
> perhaps could be used from the
> transformer?
Yep, I think this is what you've proposed.
So we can put the complete castor stuff into a new 'castor' block,
containing the transformer and the "persistence component" and maybe a
generator. The new portal block will then depend on this castor block.
Is this okay for you?
Reinhard
RE: Castor support in Cocoon (was: Building cocoon: where are block descriptions?)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Reinhard Poetz wrote:
>
> > PS Speaking of which, can somebody enlighten me as to why the
> > CastorTransformer still is part of the scratchpad
> > block. And what would it take to move it to its separate block ?
>
> I remember we already discussed this before 2.1 was released and we said
> that we didn't want a block so short before the release.
>
> Secondly, the new portal stuff uses Castor too and the two approaches
> should be unified.
> Carsten, do you have any suggestions (I think it was you who suggested
> this).
>
Hmm, I'm not sure if I suggested this...weak memory.
But the portal uses a persistence component (persistent the portal
profile in an xml doc and vice versa) and this component uses Castor.
This is a general component which perhaps could be used from the
transformer?
Carsten