Thanks Joerg and Vadim for your input. I am a big fan of the basic concepts of Cocoon and I do not tend to add a MVC layer on top of it. The power of Cocoon in my opinion is that it is not religic about the MVC pattern. It tries to do the job of building data driven websites extremely smart and fast. For MVC I am looking into JSF right now. How I will integrate this with Cocoon is still a open question. But to be honest I am not familiar with FlowScript and maybe it rocks. I stopped looking deeper into it when I read that it is a javascript engine on the server. I don't like javascript that much.
>> This basically means you can select on global, request and session >> fields because these are already set. But of course you also want to >> react on XML values in the stream. That is what you expect from an >> XML pipeline architecture. In short: I want to be able to choose >> different transformers depending on the elements/attributes placed in >> the stream by the previous transformer. Vadim Gritsenko wrote: > Forget it - this is another huge anti-pattern. Ok you convinced me that from a performance perspective, this is wrong. The caching algorithm alone will not work any more. I Don't know what excatly is wrong with it from a pattern perspective though. I will solve this as follows. Only allow for the selection of pipelines based on the XML send by the client (I am doing AJAX apps). So I wil write a Matcher that uses the incoming XML stream from the browser to select a certain pipeline. Thanks again for your thoughts, Kees -----Oorspronkelijk bericht----- Van: Vadim Gritsenko [mailto:[EMAIL PROTECTED] Verzonden: Thursday, August 11, 2005 12:47 AM Aan: dev@cocoon.apache.org Onderwerp: Re: Architectural concerns Joerg Heinicke wrote: > On 10.08.2005 11:18, Kees Broenink wrote: > >> Suppose the data of the client does not have XML but only request >> parameters. Now map this to Cocoon: >> - generator that builds the SQL query using request parameters >> - SQL transformer (adjusted to throw an exception on error) >> - XSLT that creates a new piece of HTML unrelated to the previous >> transformer (template match='/') - serialize >> >> Now to me the first generator is already a farce. I made an SQL >> transformer that simply accepts the query as parameter in stead of >> using the XML stream. You should not be using SQLTransformer at all - please take a look at Flow and ORM tools as others pointed out already. >> Now if you look at this pattern from a higher >> perspective you want to code this as follows: >> >> - SQL transformer >> - XML generator (no need to use an XSLT file) >> - serialize > > > This shows exactly that the SQLTransformer is "problematic" or in > other > words "not best practice". Try to map Cocoon to a MVC scenario and you > see that you should first build your model and retrieve it in a > generator. The SQLTransformer breaks this concept. There are perfectly valid scenarios where SQLTransformer is best tool for the job, and attemps to use 'model' layer fail (well, unless you consider ResultSet as a model ;-)). Streaming down large amount of data from the database (especially exceeding available memory) is one of them. In this case, it's impossible to process all database results in the model tier and pass it on to the view tier. OTOH, trying to do application business logic using SQLTransformer is anti-pattern, and that's where you must go for MVC architecture. > But IMO it is not > showing that Cocoon's pipeline concept as it is now has limitations. > Jens already pointed to flow, that makes it easier to see Cocoon as > player in a MVC concept. Yep. <snip/> >> 2. selectors are evaluated before the pipeline is executed >> >> This basically means you can select on global, request and session >> fields because these are already set. But of course you also want to >> react on XML values in the stream. That is what you expect from an >> XML pipeline architecture. In short: I want to be able to choose >> different transformers depending on the elements/attributes placed in >> the stream by the previous transformer. Forget it - this is another huge anti-pattern. > Besides the streaming mentioned by Torsten: This is even worse than > the > proposed TraxSerializer, the pipeline would be not predictable at all. > And from the point that even biggest systems work quite well with Cocoon > it's probably only FS. > (These systems might work (and be maintainable) only because Cocoon > pipelines are based on clean and simple concepts ;-) ) Yep. Vadim
