cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <>
Subject Re: [RT] Web Wizard Best Practices [was: Dynamic Schematron validation works!]
Date Sun, 17 Mar 2002 22:02:21 GMT
At 11:40 am -0600 17/3/02, Ivelin Ivanov wrote:
>> 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
>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
>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
>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
>My humble vision is that in the near future successful web-app servers will
>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
>> 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
>> 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

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 ?


>> 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 ....
>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.


regards Jeremy

   Jeremy Quinn                                           Karma Divers
                                                       webSpace Design
                                            HyperMedia Research Centre

   <>     		 <>
   <phone:+44.[0].20.7737.6831>             <>

To unsubscribe, e-mail:
For additional commands, email:

View raw message