> From: Antonio Gallardo [mailto:[EMAIL PROTECTED] > Sent: zaterdag 22 november 2003 12:43 > To: [EMAIL PROTECTED] > Subject: RE: Woody - Determining the value for a widget > > > 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? Yep, it's ok..but I think it also depends on how you define your transaction level in a business object. In this example the transaction level is defined on the whole salesorder. But you could also imagine a design in which you define the transaction level on each order line and order header (it's a total different approach). It just depends on what is needed in the particular business case.
-- Danny --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
