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/
