RE: [RT] New Input for woody

[Carsten Ziegeler <cz...@s-und-n.de>]

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

RE: [RT] New Input for woody

[Carsten Ziegeler <cz...@s-und-n.de>]

Sylvain Wallez wrote:
> 
> Marc Portier wrote:
> 
> > Carsten,
> >
> > Thx. This extra explanation on dywel added onto the understanding I 
> > already had (important nuances noted)
> >
> >>> 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'm not sure Woody's design has to be destroyed to include Dywel's way 
> of binding. With the upcoming separate datatype and format catalogues, 
> it would be possible to write an implementation that builds the datatype 
> catalogue using introspection.
> 
> Same applies to binding : there can be another implementation of the 
> binding.
Sounds good!

> 
> 
> > The resemblence is a great way IMO to realize none of us is completely 
> > on the wrong track, but it can't prevent the different alternatives to 
> > take specific differentiating positions that will make them more 
> > elegant to use in very specific situations.
> >
> > Woody has everything in it to grow into a system that can handle your 
> > bean backends equally well as pure XML backends given the loose 
> > connection ideas to be found everywhere in the design...
> >
> > There surely is the commitment (effort currently going on if you ask 
> > me) to ensure that specific broadly recognised usage models could get 
> > a simplified mapping onto the current Woody-soc... 
> 
> 
> Yep. Woody is currently able to map to XML and JavaBean backends, which 
> should already cover many of the needs. Another need I foresee is direct 
> mapping to an SQL backend.
> 
This sounds a little bit like mixing concerns, but let's see how it comes
out.

> > but rest assured: none of that effort will ever ensure that in a given 
> > case there could not be a more specific implementation that will be 
> > able to cut some corners and provide a more elegant solution.
> >
> > The above statement probably fits to a large extend to what Cocoon as 
> > a whole is providing. (and how it is sometimes perceived)
> >
> > In any case, thx for your input, it already added some nice features 
> > into the woody-basket (and possibly touching woody returned you some 
> > of the favor).
> >
> > I hope you can continue the effort of feeding us your progress 
> on Dywel. 
> 
> 
> Yes, please. And keep following the work on Woody. You may find that it 
> is able to host your ideas as particular implementations of one of its 
> components.
> 
Yes, of course I will do both. And I thank you all for trying to explain
Woody to me and to see how dywel and woody might fit together.

Perhaps we will see at a later time when both things will be used how the
real implementation should look like (perhaps for Cocoon 3.1).

Thanks
Carsten

Re: [RT] New Input for woody

[Sylvain Wallez <sy...@anyware-tech.com>]

Marc Portier wrote:

> Carsten,
>
> Thx. This extra explanation on dywel added onto the understanding I 
> already had (important nuances noted)
>
>>> 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'm not sure Woody's design has to be destroyed to include Dywel's way 
of binding. With the upcoming separate datatype and format catalogues, 
it would be possible to write an implementation that builds the datatype 
catalogue using introspection.

Same applies to binding : there can be another implementation of the 
binding.

>> 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.
>>
>
> I agree.
>
> That all of this largely resembles each other (Bruno saying I 
> reinvented xmlforms adds to that) should be no big surprise since all 
> of it tries to solve the same set of problems...


I would add that it's good that you reinvented XMLForm : there are nice 
ideas in it, but it's hardly usable for serious formatting and 
connection to back-end data. Every framework builds on the lessons taken 
from the previous one. And when good ideas exist, there's no reason to 
trash them.

> The resemblence is a great way IMO to realize none of us is completely 
> on the wrong track, but it can't prevent the different alternatives to 
> take specific differentiating positions that will make them more 
> elegant to use in very specific situations.
>
> Woody has everything in it to grow into a system that can handle your 
> bean backends equally well as pure XML backends given the loose 
> connection ideas to be found everywhere in the design...
>
> There surely is the commitment (effort currently going on if you ask 
> me) to ensure that specific broadly recognised usage models could get 
> a simplified mapping onto the current Woody-soc... 


Yep. Woody is currently able to map to XML and JavaBean backends, which 
should already cover many of the needs. Another need I foresee is direct 
mapping to an SQL backend.

> but rest assured: none of that effort will ever ensure that in a given 
> case there could not be a more specific implementation that will be 
> able to cut some corners and provide a more elegant solution.
>
> The above statement probably fits to a large extend to what Cocoon as 
> a whole is providing. (and how it is sometimes perceived)
>
> In any case, thx for your input, it already added some nice features 
> into the woody-basket (and possibly touching woody returned you some 
> of the favor).
>
> I hope you can continue the effort of feeding us your progress on Dywel. 


Yes, please. And keep following the work on Woody. You may find that it 
is able to host your ideas as particular implementations of one of its 
components.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com

Re: [RT] New Input for woody

[Marc Portier <mp...@outerthought.org>]

Carsten,

Thx. This extra explanation on dywel added onto the understanding 
I already had (important nuances noted)


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

I agree.

That all of this largely resembles each other (Bruno saying I 
reinvented xmlforms adds to that) should be no big surprise since 
all of it tries to solve the same set of problems...

The resemblence is a great way IMO to realize none of us is 
completely on the wrong track, but it can't prevent the different 
alternatives to take specific differentiating positions that will 
make them more elegant to use in very specific situations.

Woody has everything in it to grow into a system that can handle 
your bean backends equally well as pure XML backends given the 
loose connection ideas to be found everywhere in the design...

There surely is the commitment (effort currently going on if you 
ask me) to ensure that specific broadly recognised usage models 
could get a simplified mapping onto the current Woody-soc...

but rest assured: none of that effort will ever ensure that in a 
given case there could not be a more specific implementation that 
will be able to cut some corners and provide a more elegant solution.

The above statement probably fits to a large extend to what 
Cocoon as a whole is providing. (and how it is sometimes perceived)

In any case, thx for your input, it already added some nice 
features into the woody-basket (and possibly touching woody 
returned you some of the favor).

I hope you can continue the effort of feeding us your progress on 
Dywel.

regards,
-marc=
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at              http://radio.weblogs.com/0116284/
mpo@outerthought.org                              mpo@apache.org