cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <>
Subject RE: Woody - Determining the value for a widget
Date Sat, 22 Nov 2003 08:24:21 GMT
Danny Bols dijo:
> I still have a problem with the current behaviour which overwrites field
> values with null values if they are not available on the request string!
> If I am not able to convince you at least I would plead to make this
> behaviour configurable.

You can define this fields as "wd:output". We use it for hidden Primary
keys and woody gracefully return it back. It does not overwrite it.

But, I think the question here is what we are trying to do with woody?

Woody is just a form interface between the user and the server. Woody work
is interact with the user and return to us the results of this
interaction. Nothing more, nothing less.

The woody binding framework allow us to easily interact between the
"model" and the "views", by using and form.load(). The views
in this case is woody.

The tight integration between woody and "model" related stuff is not a
good idea. I am not sure why I need to be confident with woody about my
data. I prefer to never let them leave. Instead we can just give a copy to
woody. As pointed before, we cannot trust in the user input. So why put on
risk the critical data, by giving them to woody? An approach is: "check"
what woody return back, control it and do some actions after all. This is
posible using Flow.

My view point is: woody just send me the fields that the user fill. Woody
cannot manage all the bean fields if we don't describe it.
Note: I am aware it is posible, JXPath allow it, but it is not desirable.

Woody don't know nothing more or nothing less. I cannot expect woody
return me the next value of an autoincremental value. This is not woody

Then it is the work of the "model" to decide what actions to do based on
the woody output. It is a chain. So I think we cannot ask more to woody.

Don't think I have not the same problems as you. We thought a solution can
be a returning flags that indicate what changed on the bean. Maybe
Dynabeans can come to help here.

I know I can be wrong, please comments.

Best Regards,

Antonio Gallardo.

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

View raw message