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
<mailto:[EMAIL PROTECTED]> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pager:[EMAIL PROTECTED]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
