From cocoon-dev-return-33516-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org Sun Dec 01 10:16:31 2002 Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 57743 invoked by uid 500); 1 Dec 2002 10:16:30 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 57718 invoked from network); 1 Dec 2002 10:16:29 -0000 Message-ID: <3DE72913.8090805@apache.org> Date: Fri, 29 Nov 2002 00:45:07 -0800 From: Stefano Mazzocchi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: Flow wishlist :) References: <601F6322AD71D5118D6C0003472515290660D088@sjmemexc1.stjude.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Hunsberger, Peter wrote: > Hmm, I guess I've been exploring this long enough that I thought it was > somewhat intuitively obvious, sorry... (Someone has also remarked that this > sounded somewhat like a capability that was in C1.) yeah, you could implement what you want using dynamically added PI (processing instructions) for the C1 reactor, but it would end up being very messy anyway. > I'll skip the background for all this, but basically our requirements are a > bit extreme; 1000's of variations on 100's of UI "screens"; each UI > variation can change over time, and it must be possible to audit the history > of changes and see data in the form that the UI was at the time the data was > originally created. As such, we need to be able to drive ALL UI > construction, validation and workflow dynamically out of a database. Ok, let's start from these requirements. > Cocoon is a good starting point for this, but as we work with Cocoon we end > up coding presentation rules and presentation flow rules in the sitemap. well, that's what it was designed for. The design of the sitemap was *explicitly* meant to be static and remains so. So far, nobody was able to come up with an example where dynamically generated pipelines were the *only* way to solve a functional requirement. Anyway, I'll be strongly against adding dynamic pipeline generation capabilities, either in the sitemap or in the flowmap. > If > we're not careful we also end up coding work flow in the site map. It's > possible to get around this by adding selectors based on parameters and > making a pretty complex sitemap. But now you have a new maintenance > problem; strange sitemap "language", few experts, etc. A similar problem > comes with the coding of actions; I think I can skip details here since > you've remarked (I think) that you see flowscript as helping to remove the > requirement for actions? Yes, I don't see the need for writing your own actions once you start using flowscript attached to your sitemap. > Basically, we've got a requirement for a rules based evaluation of context > data. I don't want to code this in the sitemap language and I don't want to > hard code it in Java, I really want dynamic rules evaluation. Look: I really don't get what you mean by this. Sorry, I'm slow sometimes: can you show me an *explicit* example of your functional needs? otherwise I don't feel I can be much helpful if we keep this level of abstraction without me understanding where you want to go. > We know a > functional programming model can provide this. Just so happens we have such > capabilities at hand via XSLT if we can feed it rules selectors described as > XML. Sounds like the good old 'golden-hammer' antipattern to me. But I won't comment further until I understand your requirements. > In-other-words: currently, sitemap has access to context via URI, > parameters, generators, etc. Based on this, sitemap spits out a decision on > what transform to use. That's one way of looking at it. Another is that your functional logic could be directly included in the generator. > What I want instead is to feed an XSLT this same set > of context as XML and have the XSLT pick the subsequent transform to use. > The advantages to me are; 1) I can code in XSLT instead of sitemap language; > 2) I can optimize the entire chain of events since the transform picking > XSLT can pass on the context to the next transform (standard transform > chaining); 3) I get a functional programming model (not an advantage to > some, I know). I don't get it: you say that your requirements are so horrible that you need to keep all your rules into a database (which is a questionable sentence right there, but I don't have details to judge it). Then you say that a sitemap becomes a mess. Result: you want to write a XSLT stylesheet that uses extensions to connect to a database to obtain dynamically generated pattern-matching rules to transform an XML representation of your request context into a directly-digestible output? how that is goint to be any better than a sitemap+flowmap is *very* hard to see from where I stand. moreover, it sounds like an optimal solution to kill your webapp performances: that stylesheets becomes your bottleneck. So either you write your own xslt engine (or extend an existing one) to be able to optimize those database-extracted rules, or you're goint to have *serious* scalability issues right there. In both cases, big implementation PITA. End result? your people might know the XSLT syntax, but one thing is to know the syntax of a language, another is to be able to read a stylesheet that includes hard-core functional programming connected to external datasource via extensions. If you think that is going to be easier for you to find people able to read/write/maintain those hard-core stylesheets than it will be to find people that can learn the sitemap syntax and a read a few lines of javascript, I think you have some thick walls to crash into in your future :) >>>>for the second, I worry that it will be harder to find people that >>>>understand what cocoon is doing and this slows down the community >>> > building > >>>>for the third, I think nobody will stop people from implementing and >>>>proposing alternative flow engines. >>> >>> >>>Yes, and if blocks gets done properly there should be nothing to stop >>>one from implementing extensions to the sitemap handler in a modular >>>way. :-) >> >>well, I don't know about htat. > > > I hope it shouldn't be much of an issue. Even with Cocoon as it currently > sits we could almost do this cleanly; plug in a new transformer (sort of) > that takes over for the sitemap at some point, parceling out the rest of the > work as it sees fit. It would be subject to all the normal sitemap > invocation rules, but in our case we might end up with very few pipeline > (matchers) in the pipeline. Depending on how things shake out the new > component(s) might return to the sitemap for final serialization and thus to > Cocoon look exactly like a normal transformer. Yes. If you write your own transformer that does everything for you, then there is no problem, you can do it even today. > However, I could also see > how there might be situations where the serialization decision might be part > of the new thingy, and thus the blocks discussion and how to hand off > service calls becomes relevant. It is *NOT* a transformer decision to drive the serialization process. It's against both SoC and IoC! There is nothing planned for Cocoon Blocks that will allow this to happen and as soon as I have to vote around here, you'll get my -1 on anything that makes possible for one pipeline component to modify dynamically the pipeline execution, including choosing a serializer. -- Stefano Mazzocchi -------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org