cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <scher...@gmail.com>
Subject c3 pipelines (was Re: [jira] [Commented] (COCOON3-96) Add support for "internal-only" pipelines)
Date Tue, 03 Apr 2012 22:48:23 GMT
On Tue, 2012-04-03 at 18:18 +0000, Simone Tripodi (Commented) (JIRA)
wrote:
> [ https://issues.apache.org/jira/browse/COCOON3-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13245561#comment-13245561
] 
> 
> Simone Tripodi commented on COCOON3-96:
> ---------------------------------------
> 
> Hi Grosso!
> 
> well done and thanks for taking care! just a request: can we move the {{isInternalOnly}}
detail outside the Pipeline APIs? I mean, that is a method needed in the sitemap, while Pipeline
APis have to be work as a library also outside Cocoon, it doesn't make a lot of sense to users
- like me (blush) - that are focused on the lower level library 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. 

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.

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.

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.

salu2

Thorsten Scherler <thorsten.at.apache.org>
codeBusters S.L. - web based systems
<consulting, training and solutions>
http://www.codebusters.es/


Mime
View raw message