cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robby Pelssers <>
Subject RE: c3 pipelines (was Re: [jira] [Commented] (COCOON3-96) Add support for "internal-only" pipelines)
Date Wed, 04 Apr 2012 07:34:44 GMT
Exactly my thought.  I never comprehended the difference between the configure() and setup()
either. I'm pretty sure I asked the same in a old thread. Even for component developers this
leads to confusion.  Nice to see some good discussion being started !!


-----Original Message-----
From: [] On Behalf Of Simone Tripodi
Sent: Wednesday, April 04, 2012 8:42 AM
Subject: Re: c3 pipelines (was Re: [jira] [Commented] (COCOON3-96) Add support for "internal-only"

> I second that concern since I am hitting lately some frontiers opposed
> by that sitemap focused view. IMO *.xmap in the end should be a wrapper
> to configure spring registered pipes.

+1000!!! :)

> Some old school configure methods had sneaked into some componentes and
> I think we should clean up some methods and ways to change attributes in
> general.
> For example the difference between configure() and setup() is IMO not
> justifiable to maintain. Further the complete usage of java based
> pipelines need to better be synced with the sitemap. I need to be able
> to look up pipelines configured by the sitemap in a java only context.

can you believe that today I still get in trouble with that? If it is
confusing for me, I can imagine what users can think - not that I am
good, but of course more familiar that newcomers

> However the principal difference ATM is that in xmap the hierarchy is
> pipe-match-components but "match" is in no way part of the java pipe
> api. Leading to the current situation where both are treated completely
> separated.
> However components such as regexpLinkRewriter and i18nTransformer should
> be configured in a spring context to be reusable in a hybrid
> environment. In one of our projects I had to duplicate the effort to
> configure this. It is a "lesser evil" decisions for now but I am keen to
> change it in the near future.
> So bottom line IMHO c3 pipes being java or xmap should be usable vice
> versa otherwise they cause double of work.


> ...and if we think abstract the look up of a java pipe in xmap env would
> be fire the request "matching" a pattern. What comes within a match are
> basically a java pipe. The only thing is to integrate the input
> module/language interpreter into the java pipe logic to make xmap pipes
> usable as java pipe.

in the CLI module I started working on that, even if with a different
format that xmap - even if not complete yet (I feel shame for not
having completed yet) it shows anyway that injecting config parameters
to pipeline without the Map context is possible

> Having worked with all versions and supporting projects that are hybrids
> of c2.x and c3 I have to admit if we can think of the traditional 2.x
> sitemap as config for spring and we can lookup and (re)use the matches
> in both environments than we are so much more than the leading xml
> framework since 1998. Since finally our Lego(tm) web components
> (generators, transformers, ...) are not bound to avalon and reusable
> everywhere.
> Having said that, we need to sometimes expose much more setters in our
> components to break away from the xmap and vice versa to expose setup()
> method to configure the component via sitemap. The parameter based
> configuration  proofed to be quick and flexible to configure components
> in both environments.
> ...maybe we even can implement "map:invoke-method name="setup|..." ..."
> for components and "configure" them in a more general way. ... with the
> benefit in reusing the logic in different environments.
> I will write a summary of java pipes in c3 after we go online with the
> main project we based on c3, but that may take at least 2 months.

You have my full support, please let me know if/how we can cooperate!

All the best,
View raw message