On 12/18/07, angel.of.cynicism <[EMAIL PROTECTED]> wrote: > solprovider wrote: > > While I love writing Java and have written Cocoon Generators, I believe > > only new standard components should require programming Java with Cocoon. > When you say 'new standard components' thats for the website I am > developing?
My definition of "standard components" requires the component to be generic --useful for multiple applications. A generator pulling data from your database structure is not generic. A generator that can be configured to pull data from any SQL database is "standard." I wrote an enhancement of URLSource to pass Cookies between clients and backend servers when the protocol is HTTP. This allows the backends to maintain sessions without affecting Cocoon's sessions or requiring any special programming. This "standard component" is useful for many applications -- anytime Cocoon displays data from another Web application. (I want to commit the two files, but do not want to add new functionality just before the final release of Cocoon 2.1.) You may need to add components if you are building a platform. Writing a business application with Cocoon should not require compiling Java. > Based on the nature of the site I cannot see us getting away from writing > java code, each business transaction communicates to web-service. Would > inheriting off the ServiceableAction for request handling be a valid > consideration? Research "Web Service" and "SOAP". While the original definition of a Web Service did not require XML, the term currently means responding to HTTP requests with XML. Cocoon has components specifically for Web Services, but Cocoon's default components are sufficient for almost any functionality involving Web Services. I have yet to see code using an Action that could not be improved by replacing the Action with other components. Actions seem to be used when a programmer has been developing with Cocoon's XML for a week and needs a reason to write some Java. Cocoon 2.1 has trouble with Actions: error-handling does not work properly and other strange behaviors occur. Including an Action in your application design suggests insufficient understanding of Cocoon. (Like seeing ArrayList in Java code: you know the programmer learned Visual Basic first and is unlikely to learn proper use of data structures.) With Cocoon, the goal is to get the data into XML, process the data using XMAPs and XSLTs, then serialize into whatever format is needed. Web Service Transaction using Cocoon: 1. Accept Web Form. (RequestGenerator? or post.xsp.) 2. Transform to Web Service request. 3. Send request and receive response. 4. Transform Web Service response to required information. 5. Format, add navigation, serialize to HTML. No Actions. #3 needs a transformer that sends a fragment of the current document to a URLSource and places the response into the current document. This seems easy and useful, but I do not see a standard transformer with this functionality. This is a good example of a desirable new standard component. solprovider --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
