Danny Bols dijo:
>> 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?
I just suggested a posible solution. But I guess you are controlling all
this flow from the same function. If this is the case. You don't need to
make a roundtrip for the header info. The header is stored inside the
continuation as part of a variable being declared in the flow:
> (3) while(!finished) {
> :
> if(showOrderLines) {
> form.showForm("orderlines");
mySalesOrder.processOrderLines;
> if(showOrderLineDetails) {
> form.showForm("orderlinedetails");
mySalesOrder.processOrderLinesDetails;
> } else {
> form.showForm("orderheader");
mySalesOrder.processHeader;
> }
> }
Is this OK?
Best Regards,
Antonio Gallardo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
