> From: Antonio Gallardo [mailto:[EMAIL PROTECTED]
> Sent: zaterdag 22 november 2003 9:24
> To: [EMAIL PROTECTED]
> Subject: RE: Woody - Determining the value for a widget
>
>
> 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 form.save() 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
> job.
>
> 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.
Just to make the discussion clear a I made a simplified description and
example of the process we are talking about:
Some shortcuts I used:
---------------------------------
DS = Data Store (could be a database)
BO = Business Object (could be a bean)
UI = User interface (could be multiple templates acting on 1 form)
The process:
------------------
DS--(1)-->BO--(2)-->(Form<--(3)-->UI)--(4)-->BO--(5)-->DS
(1)The BO is loaded from the DS
(2) The BO data is loaded into a FORM
(3) User interaction takes place based on the FORM object.
(4) The FORM data is assigned to BO
(5) BO changes are comitted to the DS:
Example
------------
A (very) simplified sales transaction example of this process (in
flowscript) could be something like:
(1) SalesOrder mySalesOrder = new SalesOrder();
mySalesOrder.loadFromDataStore("so125631");
(2) myForm.id = mySalesOrder.getOrderNo();
myForm.desc = mySalesOrder.getDescritpion();
:
for(var i = mySalesOrder.getOrderLines(); i.hasNext();) {
var myOrderLine = i.next();
var myRow = myForm.form.getWidget("orderlines").addRow();
myRow.id = myOrderLine.getId();
myRow.desc = myOrderLine.getDesc();
}
(3) while(!finished) {
:
if(showOrderLines) {
form.showForm("orderlines");
if(showOrderLineDetails) {
form.showForm("orderlinedetails");
} else {
form.showForm("orderheader");
}
}
(4) mySalesOrder.setDescritpion(myForm.desc);
for(var i = myForm.getWidget("orderlines"); i.hasNext();) {
var myRow = i.next();
var myOrderLine = mySalesOrder.getOrderLine(myRow.id);
myOrderLine.setDesc(myRow.desc);
}
(5) mySalesOrder.saveToDataStore()
Thougths
-------------
This thread is about the 3th step in the process, the user interaction based
on a woody form object. The contract between the model and view is the FORM
object. But once the data is handed over from the MODEL to the VIEW you want
to be able to build "flexible interaction" with "riskless processing".
Flexible interaction.
IMHO this would start with having multiple templates for one form and to be
able to refer to all the widgets in a form (absolute/relative addressing
widgets, see other thread).
Riskless processing.
If in the example above I activate an order header template (which doesn't
do anything with my order lines) I don't want my order line data to
unnecessary travel back and forth over the network and to be processed by
woody. Why should we use hidden fields? Why storing primary keys in
wd:output fileds? Why put extra load on the valuable resources and
processing time? Why introducing more processing risks?
Greetz.
--
Danny
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
