> From: Peter Donald [mailto:[EMAIL PROTECTED]] > > On Tue, 11 Jun 2002 22:52, Berin Loritsch wrote: > > Another key difference is that the Cocoon model has a > requirement to > > re-connect the hint mappings at runtime--whereas the Merlin > model does > > it all at init time. > > Can you explain that? You aquire components based on request > parameters but > the request parameters supply constraints and not hints (ie "ssl" vs > "xalan").
The Cocoon Sitemap is either compiled (the old fashioned way) or interpreted. The sitemap file can change at any time. The definition of a pipeline is quite dynamic. In fact, the selection criteria for which Generator/Transformer/Serializer can depend on anything from the time of day to the price of tea in China. There are request parameters, session parameters, request methods, URI, etc. The fact that the mapping can be reloaded and reused at runtime makes it a bit more difficult to do init-time mapping. I'm not very familiar with Merlin, but I am familiar with Cocoon. You see, it is not so much as which transformer satisfies the need for a transformer, but that the transformer does the requested work. IOW I have a transformer that takes certain elements from the XML, uses them to gather information from a database, and then replace those original elements with ones generated from the data I pulled from the database. Now, I could care less if it is done with an XSLT transformer using ScriptBeans or if it is a custom hardcoded transformer. All I care about is that the output of the transformer does what I asked it to. With Cocoon, this is set up each time the sitemap is read. Unfortunately, there is no way to guarantee that the sitemap won't change unless we hardcode the sitemap. In practice, that is more work than it's worth. So, I am open to input on how you would solve this problem... -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
