> > 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. > +1 > ...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, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/
