Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 43387 invoked by uid 500); 17 Mar 2002 22:01:57 -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 43376 invoked from network); 17 Mar 2002 22:01:57 -0000 Mime-Version: 1.0 X-Sender: media@pop3.demon.co.uk Message-Id: In-Reply-To: <001801c1cdda$e60c1280$0c91fea9@galina> References: <3C93412A.3060505@dff.st> <014e01c1cd20$0e6f3060$0c91fea9@galina> <001801c1cdda$e60c1280$0c91fea9@galina> Date: Sun, 17 Mar 2002 22:02:21 +0000 To: cocoon-dev@xml.apache.org From: Jeremy Quinn Subject: Re: [RT] Web Wizard Best Practices [was: Dynamic Schematron validation works!] Content-Type: text/plain; charset="us-ascii" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N At 11:40 am -0600 17/3/02, Ivelin Ivanov wrote: >Jeremy, >> Not wanting to be negative or anything ... but we have quite different >> approaches driven by different needs, we may or may not be able to >> reconcile them. > >That's perfectly fine with me. >Don't you think we should be able to agree on a problem that satisfies a >common subset of our real world scenarious which may be quite different for >everyone. >We can still end up with to 2 different possible solutions and offer these >as two alternative patterns. >My issue with the current stage with C2 is that there are no best practices >documents. >Most recently successful technologies have these documents which improve >their popularity and recognition by helping developers be more productive. I agree, I ought to be able to do that ..... it's just I am turning the project on it's head at least once a day ..... still experimenting too much >> It does not really matter right now, we will _all_ learn from both >attempts > >That's one certain thing ! That's how cocoon has grow >> What I mean more specifically: >> >> As I understand it .... you re trying to make a generic system (partially >> influenced by previous work done attempting to implement the XForms >> standard) for building complex business objects. >> >> Furthermore you are trying to make your _sitemap_ adapt itself to the >> progress of the transaction. > >Actually Torsten has a stronger view on this approach. >I mostly agree with his ideas, though there are a few things we'll need to >iron out in the coming days. > >I definitely want to understand your technique though. Don't want to rush >into a dead end street. You don't have a dead end street, the direction Torsten is going in could lead to new ways of using Cocoon, just as much as mine might ;) >I'm mostly driven by the fast developments in the web services area. >Having faced an actual problem of converting a complex Web UI portal into >one that offers almost all of its UI functionality through web services, I >know that this turned out to be very hard while it could have been real >easy. > >My humble vision is that in the near future successful web-app servers will >be >able to seamlessly integrate with web services. Web services already know >how to handle xml <-> object binding. Well that's cool stuff >Cocoon is a mature and sophisticated container and its future will be even >brighter if it allows for existing Web UI portals to offer their >functionality through web services with minimal investment. Cocoon is much more mature as a publishing engine than a webapp engine. >> I on the other hand am trying to make generic patterns for assembling >> sitemap and XSLT components, as an example of how to add the ability to >> edit your own existing assets, to an existing publishing project. > >I find this exciting and would certainly like to follow the development. >While working on these patterns I assume you will try to keep the lines >between presentation, content and logic bright and sharp. > >> >> What's more, I am implementing my logic differently; by having >transformers >> modify the _content_ of the pipeline to adapt to the progress of the >> transaction. >> >> Both techniques are very interesting in their own right! > >Have you checked this in? Where should I look? it's in cvs now >> If I had access to the stuff you are doing now, 12 months ago, I'd be >> dancing in the streets! It was JUST what I wanted for the Crudlet project >I >> was working on, where we had large and complex JavaBeans to fill in and >> manipulate, requiring multiple forms to do the job. > >I came across Crudlets recently and found it interesting, but it seemed like >there was no activity for quite a while. >What is the current status? May she RIP >> If you were to follow my pattern (which I am not suggesting, this is just >> an illustration) you would: >> >> 1. Generate an Instance >> using XSP or RequestGenerator + XSLT etc. >> >> 2. Validate the Instance. >> using the delightful Schematron (thanks!) > >so far so good. > >> >> 3. Adapt the Instance (depending on validation result) into tags for a >> CastorTransformer, which makes/modifies/prods your bean. > >The CastorTransformer marshalls a JavaBean into XML document. Currently it >only "prods" but does not "make/modify". Sorry, that should have been makes/modifies/prods/reads :) >How would you bind the XML data from 2. into JavaBeans in the business >domain? By un-marshalling the xml (you have just generated and validated) in (a new) CastorTransformer, specifying a mapping if required. The CastorTransformer would act either as a producer or a consumer of XML, depending on what tags were in it's stream. Writing XML un-marshals to a a Bean, Reading XML marshals from the Bean. Something else invokes methods on the Bean. You ought to be able to make/do/destroy any number of objects all on the same pass of the Transformer if you need to .... by having multiple castor tags in the stream. Even (Sylvain, you listening? ;) implement Castor access as a WriteableSource instead of a Transformer, you make up a psuedo protocol to read, write, prod. >> 4. Adapt the Instance (depending on Castor result) into whatever your next >> stage needs to be > >I assume you mean adapt through XSLT ? Yes >> I do not think we are duplicating effort. >> I think both of these efforts will (at the very least) prove to be useful >> examples for other developers, regardless of the final outcome. >> >> As long as we keep sharing our ideas publicly (as has happened to great >> effect so far!) we have a win-win situation. >> >> I am not convinced that one pattern can solve every problem in this realm >> .... there is still a lot to explore .... > >Definitely. >Let's keep it moving and close the subject this time. >It would be sad to see this discussion dead end like the other ones which >tried to tackle the same problem in the last 2 years. +1 regards Jeremy -- ___________________________________________________________________ Jeremy Quinn Karma Divers webSpace Design HyperMedia Research Centre --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org