cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: [RT] New Input for woody
Date Fri, 01 Aug 2003 08:52:23 GMT
Marc Portier wrote:
> 
> <snip/>
> as I understood from earlier discussions this also serves as a 
> form-model-definition (meaning dywel doesn't require an aditional 
> file for that)
More or less: yes - you need the "binding".

> > 
> > How does it work? A component (a java implementation) parses
> > the template and the binding file, the first time it's used.
> > The template is compiled and the bindings are attached to
> > the internal tree representing the template.
> > 
> 
> could you elaborate on 'attached'
> is an instance of the business object involved in this process?
No, a tree is created is created with java objects for the different
elements or fields used. So you have a java object representing
one particular input field. This object gets the binding, so
it knows from where to get it's input. But this is only the
definition, so the object does not get the business object
itself only the string like "user.name".

> > A special generator uses the java component and asks it to
> > render the page. Now the tree is processed. Each field
> > knows how to render itself. To get the values for a
> > form field, the field asks the component for the
> > value for e.g. "user.name". The component now has
> > a getUser() method and the returned user object has
> > a getName() method.
> > 
> 
> this sounds like the business object instance values are only 
> read at this time...
> 
Exactly. The tree I mentioned above is traversed and the java
object for the field gets a "component" and can ask that
component for the value of let's say "user.name".

> 
> > For each form or better web page, you have to write
> > the java component = controller. You simply inherit
> > from a base class and provided methods to get your
> > business objects. (I'm looking to simplify this using
> > fom when everything else is set).
> > So, this solution is tied to java objects (currently).
> > 
> 
> well, it is tied to a custom-to-be-written java object
> 
> from a distance it looks like you'll need some luck for hooking 
> up some existing java objects from a long-before-dywel designed 
> business application (e.g. the validation method, but also the 
> type of the argument in the setXXX methods, the web is presenting 
> you with Strings, how is the conversion done? <-- this is the 
> crux of my current understanding of dywel)
Ah, ok, you don't need something in between you can directly connect
to existing business objects. E.g. JXPath can do most of the
conversions for you, if you have a string with a number and have
a setAge(int) the conversion is done for you automatically etc.
So most conversions can be done by that, you can set optional
formatter objects in the binding that do the conversion for you,
e.g. for date objects.

> 
> if that is the case then one is going to need to write a specific 
> javabean to accomodate for the intermediate step before actually 
> talking to the legacy backend system
No, as explained above.

> 
> woody's proposition is to use not Java code but the 
> form-definition file to describe this intermediate model... AFAIU 
> both approaches use this kind of intermediate stage as a basis 
> for validation and string-type conversion
> 
> (remembering Bruno's recent rumblings on jxpath addressing inside 
> form-widgets the line could get very thin)
> 
> > Now, it is possible to specify additional validation and
> > formatting in the binding, like:
> >   <dywel:binding id="street">
> >     <value>user.address.city</value>
> >     <validation>a rule</validation>
> >     <formatter>a formatter</formatter>
> >   </dywel:binding>
> > 
> > etc.
> 
> similar
> 
> I'm still looking for the reverse of the formatter (string to type?)
The formatter does both.

> 
> As I see it now, the integration is not trivial (but possible)
> Your bean seems to provide an alternative to the declarative 
> woody-widget tree (form-model)
> 
> We could argue about the woody-widget tree being the real CORE of 
> woody, so the 'not trivial' gets to have some meaning I guess :-)
> 
> 'Integration' then becomes making the form-model pluggable which 
>   would come down to
> 1/ making the woody-template-transformer can pull out the values 
> using jxpath rather then using the widget API
> 2/ and the other way around the form.process(request) needs to 
> evolve to Dywel.process(bean-or-widgetTree, request); which could 
> again use some jxpath-like approach to perform its setValues...
> 
> not trivial, maybe possible, useful?
Hmm, I'm a little unsure. Now, I don't want to destroy the design
of woody only to make me happy. If it makes sense, to change
woody: great. If it doesn't, well, then I can live with that
as well. It's a decision I'm currently not able to make or
contribute to.

I think, currently if Dywel will ever work sometime in the distant
future, it's more elegant to connect to existing business objects
than woody; but on the other hand woody has great advantage in
all the other form areas where you don't connect to business objects.

Carsten

Mime
View raw message