cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Danny Bols" <db...@osirion.be>
Subject RE: Woody - Determining the value for a widget
Date Sat, 22 Nov 2003 13:04:36 GMT
> From: Antonio Gallardo [mailto:agallardo@agsoftware.dnsalias.com]
> Sent: zaterdag 22 november 2003 12:43
> To: users@cocoon.apache.org
> Subject: RE: Woody - Determining the value for a widget
>
>
> Danny Bols dijo:
> >> From: Antonio Gallardo [mailto:agallardo@agsoftware.dnsalias.com]
> >> Sent: zaterdag 22 november 2003 9:24
> >> To: users@cocoon.apache.org
> >> 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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message