Darn. Meant for this to go to the list, not to you directly. -----Original Message----- From: Ralph Goers To: 'Joerg Heinicke ' Sent: 1/27/2004 9:06 PM Subject: RE: [proposal] Cleaning up our component library
I realise I am fairly new to Cocoon and my opinion probably doesn't carry as much weight as most of yours. In many ways I agree with you, but not all. In particular, I am not in favor of removing components if their replacement requires flowscript. In my company we won't/can't use it. Our environment has special security concerns that just won't allow a scripting language - or even JSPs or XSPs for that matter. One of the things we love is that the flow can be completely implemented through the sitemap and a few custom compoents, as well as those already provided by Cocoon. We'd love to use Woody (aka Cocoon Forms), but if it can be used without FlowScript it isn't obvious. So we will be using the SimpleFormTransformer etc., for the forseeable future. One of the things I abhor about Java Open Source projects is their apparent disregard for backward compatibility. If any of you read the forum at theserverside.com about the release of Commons Collections 3.0 you will know what I am talking about. So while providing strong guidance on best practices is great, IMO removing classes that have been released should only be done after the classes have been deprecated for at least one release. Ralph -----Original Message----- From: Joerg Heinicke To: [EMAIL PROTECTED] Sent: 1/27/2004 5:40 PM Subject: [proposal] Cleaning up our component library Another example or the "wrong" components as [Read|Write]DOMSessionTransformer or SourceWritingTransformer. They are not transformers in the closer sense, they just tee the pipeline. They should be completely removed and replaced with either XModuleSource and aggregation (read) or FlowScript's processPipelineTo (write). Similar as for the FileGenerator the DirectoryGenerator is "out of date", we already have the replacement in our CVS. WDYT? Joerg
