You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Antonio Gallardo <ag...@agsoftware.dnsalias.com> on 2003/07/29 15:07:04 UTC
[RT] Woody and round trip of parameters.
Hi:
I had a concern about how to manage parameters that are flying between the
server and the client.
It will worth if we have an attribute in the form that define when we are
waiting or not for a parameter back from the user?
I know woody has some formulas, I was not full review woody. :)
I was thinking in some type of "formulas" or "equations" that we can send
to woody and let woody calculate them. ie: a tipical invoice
(master-detail):
Date: 29-jul-2003 N° 2300
Client: Cocoon
-------------------------------------------
Quantity Item Unit Price Amount
-------------------------------------------
2 pen $1.00 2.00
1 pencil $0.50 0.50
-------------------------------------------
Subtotal: 2.50
Shipping: 1.00
Total: 3.50
Here we have some fields that are sended from the model (amount, subtotal,
total), but we dont need it back from the form.
Is there a way to define this thing. Also a way to define what we need
back and what not.
This can helps to improve the performance of form handling.
Best Regards,
Antonio Gallardo
Re: [RT] Woody and round trip of parameters.
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Bruno Dumon dijo:
> On Tue, 2003-07-29 at 15:07, Antonio Gallardo wrote:
>> Hi:
>>
>> I had a concern about how to manage parameters that are flying between
>> the server and the client.
>>
>> It will worth if we have an attribute in the form that define when we
>> are waiting or not for a parameter back from the user?
>
> do you mean something like read-only fields?
Yep, read-only fields. As a read-only field we does not need to send it
back to the server since the fields are no persistent at all.
>
>>
>> I know woody has some formulas, I was not full review woody. :)
>>
>> I was thinking in some type of "formulas" or "equations" that we can
>> send to woody and let woody calculate them.
>
> sending formulas to woody? Me understand not :-)
Aha. For example in the invoice example (below) some fields are formulas
(not persistent):
Amount = Quantity * Unit Price;
Subtotal = Sum(Amount);
Total = Subtotal + shipping;
As this kind of info is more related to the form than to the model. I
think woody can handle this.
What you think?
Best Regards,
Antonio Gallardo
>
>> ie: a tipical invoice
>> (master-detail):
>>
>> Date: 29-jul-2003 N° 2300
>> Client: Cocoon
>>
>> -------------------------------------------
>> Quantity Item Unit Price Amount
>> -------------------------------------------
>> 2 pen $1.00 2.00
>> 1 pencil $0.50 0.50
>> -------------------------------------------
>> Subtotal: 2.50
>> Shipping: 1.00
>> Total: 3.50
>>
Re: [RT] Woody and round trip of parameters.
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
> Contribution form: a series of contribution payments is precalculated.
> User may override the amount of any payment in the series by entering a
> different number in the text widget (as long as the payments still add
> up to the original total). To enhance usability, similar logic is used
> in many of the forms we process.
Yep. Another example, a invoice system for small business when the cashier
can define right on the invoce form the price of every item. Of course the
default is the stored list price. Think in a marketplace, where you can
ask rebate buying oranges. :)
Antonio Gallardo.
>
> A very interesting discussion.
>
> --Michael
>
>
>
>
> "Antonio Gallardo" <ag...@agsoftware.dnsalias.com>
> 07/30/03 02:02 AM
> Please respond to
> dev@cocoon.apache.org
>
>
> To
> <de...@cocoon.apache.org>
> cc
>
> Subject
> Re: [RT] Woody and round trip of parameters.
>
>
>
>
>
>
> Marc Portier dijo:
>> I can't see a need for a field that should be 'calculated
>> automatically' AND be editable at the same time.
>> (I tried though)
> It sometimes happens, for example here in my country, in a restaurant
> invoice is a non written rule to pay 10% of the subtotal to people that
> serviced you. But if you dont want to pay this you can change the amount
> or not pay it at all. Then you need to create another invoice with the
> change.
>
> Also diplomatic people does not pay taxes. If you have an automatic
> formula to calculate the X % tax, when this people show you their ID,
> you need to put the tax amount to 0.
>
> I think is are two examples when a formula can be change by the user.
>
> Best Regards,
>
> Antonio Gallardo.
Re: [RT] Woody and round trip of parameters.
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Marc Portier dijo:
>
>
> Antonio Gallardo wrote:
>> Marc Portier dijo:
>>
>>>I can't see a need for a field that should be 'calculated
>>>automatically' AND be editable at the same time.
>>>(I tried though)
>>
>> It sometimes happens, for example here in my country, in a restaurant
>> invoice is a non written rule to pay 10% of the subtotal to people
>> that serviced you. But if you dont want to pay this you can change the
>> amount or not pay it at all. Then you need to create another invoice
>> with the change.
>>
>> Also diplomatic people does not pay taxes. If you have an automatic
>> formula to calculate the X % tax, when this people show you their ID,
>> you need to put the tax amount to 0.
>>
>> I think is are two examples when a formula can be change by the user.
>>
>
> I might be missing something, but if you try to model this in
> web-forms you will end up with something different then a field
> that must be updatable AND automatically calculated (upon each
> round-trip)
>
> in both cases you mention I think you will have
> - an editable field (1/ gratuity: a numeric field, percentage
> format initially set at 10% and 2/ isDiplomat: a
> boolean-field/checkbox initially set OFF)
>
> next to but separate from
> - a calculated field that shows the total.
>
> making sense?
Thanks for the response. Every programmer can found a way to use the given
tools to solve a problem. I know this can be solved as you show up. This
is one posibility.
But, I saw that we need another 2 fields that increse the complexity of
the form.
In the concrete restaurant example if you have only 2 cashier that need to
register 300 invoices between 10:00 p.m to 2:00 a.m on Friday and
Saturday. you will see that just "jumping" in another 2 fields make sense.
This is why (by the chashier request, we implemented this). 2 kestrokes *
300 is 600 keystrokes saved at a day => less work!
Best Regards,
Antonio Gallardo
>
> -marc=
> --
> Marc Portier http://outerthought.org/
> Outerthought - Open Source, Java & XML Competence Support Center
> Read my weblog at http://radio.weblogs.com/0116284/
> mpo@outerthought.org mpo@apache.org
Re: [RT] Woody and round trip of parameters.
Posted by Marc Portier <mp...@outerthought.org>.
Antonio Gallardo wrote:
> Marc Portier dijo:
>
>>I can't see a need for a field that should be 'calculated
>>automatically' AND be editable at the same time.
>>(I tried though)
>
> It sometimes happens, for example here in my country, in a restaurant
> invoice is a non written rule to pay 10% of the subtotal to people that
> serviced you. But if you dont want to pay this you can change the amount
> or not pay it at all. Then you need to create another invoice with the
> change.
>
> Also diplomatic people does not pay taxes. If you have an automatic
> formula to calculate the X % tax, when this people show you their ID, you
> need to put the tax amount to 0.
>
> I think is are two examples when a formula can be change by the user.
>
I might be missing something, but if you try to model this in
web-forms you will end up with something different then a field
that must be updatable AND automatically calculated (upon each
round-trip)
in both cases you mention I think you will have
- an editable field (1/ gratuity: a numeric field, percentage
format initially set at 10% and 2/ isDiplomat: a
boolean-field/checkbox initially set OFF)
next to but separate from
- a calculated field that shows the total.
making sense?
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
mpo@outerthought.org mpo@apache.org
Re: [RT] Woody and round trip of parameters.
Posted by mr...@collegenet.com.
Contribution form: a series of contribution payments is precalculated.
User may override the amount of any payment in the series by entering a
different number in the text widget (as long as the payments still add up
to the original total). To enhance usability, similar logic is used in
many of the forms we process.
A very interesting discussion.
--Michael
"Antonio Gallardo" <ag...@agsoftware.dnsalias.com>
07/30/03 02:02 AM
Please respond to
dev@cocoon.apache.org
To
<de...@cocoon.apache.org>
cc
Subject
Re: [RT] Woody and round trip of parameters.
Marc Portier dijo:
> I can't see a need for a field that should be 'calculated
> automatically' AND be editable at the same time.
> (I tried though)
It sometimes happens, for example here in my country, in a restaurant
invoice is a non written rule to pay 10% of the subtotal to people that
serviced you. But if you dont want to pay this you can change the amount
or not pay it at all. Then you need to create another invoice with the
change.
Also diplomatic people does not pay taxes. If you have an automatic
formula to calculate the X % tax, when this people show you their ID, you
need to put the tax amount to 0.
I think is are two examples when a formula can be change by the user.
Best Regards,
Antonio Gallardo.
Re: [RT] Woody and round trip of parameters.
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Marc Portier dijo:
> I can't see a need for a field that should be 'calculated
> automatically' AND be editable at the same time.
> (I tried though)
It sometimes happens, for example here in my country, in a restaurant
invoice is a non written rule to pay 10% of the subtotal to people that
serviced you. But if you dont want to pay this you can change the amount
or not pay it at all. Then you need to create another invoice with the
change.
Also diplomatic people does not pay taxes. If you have an automatic
formula to calculate the X % tax, when this people show you their ID, you
need to put the tax amount to 0.
I think is are two examples when a formula can be change by the user.
Best Regards,
Antonio Gallardo.
Re: [RT] Woody and round trip of parameters.
Posted by Marc Portier <mp...@outerthought.org>.
Sylvain Wallez wrote:
> Antonio Gallardo wrote:
>
>> Marc Portier dijo:
>>
>>
>>> some attempt/proposal:
>>> definition-model declares field:
>>> case A: nothing special -> defaults to read-write
>>> case B: as being read-only
>>> case C: specific as read-write
>>>
>>> binding declared on field
>>> case 1: nothing special -> defaults to inherited from the field
>>> definition?
>>> case 2: as being read-only
>>> case 3: specific as read-write
>>>
>>>
>>> then what happens
>>> A.1 == C.3 == C.1 == A.3: full read-write on all stages
>>>
>>> B.2: data flows only from backend up to the browser
>>> B.1: binding level reads from the field definition that it is
>>> read-only and inherits the behaviour --> B.2
>>>
>>> B.3: binding level will save although the end user could not change
>>>
>>> A.2 = C.2: allow user change, but don't save back to the object-model
>>> (which sounds awkward? I don't see a case needing this ATM)
>>>
>>
>>
>> Sorry to said that but this is very complex. :(
>>
>> I think we have only 2 case on every one, the nothing special case is
>> a normal default.
>>
>
> And what about introducing XMLForm's "output" element as a read-only
> Woody widget ? This widget would have a datatype and converter just as a
> normal field, but would not parse it's value from the request.
this description prefectly matches what I wanted to indicate with
@read-only on the field-definition, the different element-name
could very well help the understanding:
it would kind of push us into option1 and as such surely lower
the expectations of inherited @read-only value and lower possible
'false intuition'
not to be forgotten though:
considering the fact that the unique-row-id's for the
repeater-binding will need a similar thing we should maybe
foresee that still the template layer can choose to 'hide' these
output-fields
> Furthermore, it could have an expression to compute its value.
>
yep,
I can't see a need for a field that should be 'calculated
automatically' AND be editable at the same time.
(I tried though)
> Thoughts ?
sure :-)
>
> Sylvain
>
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
mpo@outerthought.org mpo@apache.org
Re: [RT] Woody and round trip of parameters.
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Antonio Gallardo wrote:
>Marc Portier dijo:
>
>
>>some attempt/proposal:
>>definition-model declares field:
>>case A: nothing special -> defaults to read-write
>>case B: as being read-only
>>case C: specific as read-write
>>
>>binding declared on field
>>case 1: nothing special -> defaults to inherited from the field
>>definition?
>>case 2: as being read-only
>>case 3: specific as read-write
>>
>>
>>then what happens
>>A.1 == C.3 == C.1 == A.3: full read-write on all stages
>>
>>B.2: data flows only from backend up to the browser
>>B.1: binding level reads from the field definition that it is
>>read-only and inherits the behaviour --> B.2
>>
>>B.3: binding level will save although the end user could not change
>>
>>A.2 = C.2: allow user change, but don't save back to the object-model
>>(which sounds awkward? I don't see a case needing this ATM)
>>
>>
>
>Sorry to said that but this is very complex. :(
>
>I think we have only 2 case on every one, the nothing special case is a normal default.
>
And what about introducing XMLForm's "output" element as a read-only
Woody widget ? This widget would have a datatype and converter just as a
normal field, but would not parse it's value from the request.
Furthermore, it could have an expression to compute its value.
Thoughts ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [RT] Woody and round trip of parameters.
Posted by Marc Portier <mp...@outerthought.org>.
Antonio Gallardo wrote:
> Marc Portier dijo:
>
>>some attempt/proposal:
>>definition-model declares field:
>>case A: nothing special -> defaults to read-write
>>case B: as being read-only
>>case C: specific as read-write
>>
>>binding declared on field
>>case 1: nothing special -> defaults to inherited from the field
>>definition?
>>case 2: as being read-only
>>case 3: specific as read-write
>>
>>
>>then what happens
>>A.1 == C.3 == C.1 == A.3: full read-write on all stages
>>
>>B.2: data flows only from backend up to the browser
>>B.1: binding level reads from the field definition that it is
>>read-only and inherits the behaviour --> B.2
>>
>>B.3: binding level will save although the end user could not change
>>
>>A.2 = C.2: allow user change, but don't save back to the object-model
>>(which sounds awkward? I don't see a case needing this ATM)
>
>
> Sorry to said that but this is very complex. :(
>
> I think we have only 2 case on every one, the nothing special case is a
> normal default.
>
Sorry for added complexity, I was aiming for the opposite (well,
I guess (only) good intentions are just no good ;-))
I was just trying to guess what would be intuitive and proposed
that for any given field the @read-only for binding could default
to the @read-only setting of the model-definition (rather then
default to the fix value 'false')
maybe the following view expresses better what I try to achieve:
option 1: with classic defaulting (to false):
USER WANTS TO DO THIS: | USER NEEDS TO CONFIG THIS:
type of usage | required setting @read-only
| model binding
-------------------------+-------------------------------------
1/ the normal case | false (dflt) false (dflt)
2/ no editing/no binding | true true
3/ the game-example case | false (dflt) true
4/ no use? case | true false (dflt)
option 2: with 'smart' defaulting
(i.e. binding-definition inherits from form-model-definition)
USER WANTS TO DO THIS: | USER NEEDS TO CONFIG THIS:
type of usage | required setting @read-only
| model binding
-------------------------+-------------------------------------
1/ the normal case | false (dflt) --> false (dflt)
2/ no editing/no binding | true --> true (dflt)
3/ the game-example case | false (dflt) true
4/ no use? case | true false
No assuming that I ordered the different types of usage from most
likely used to least wanted (i.e. the case for which I haven't
found any usage at the bottom) we see that option2 does a better
effort at promoting usage 2/ over usage 4/
which I would translate as: it makes it more intuitive ?
I'm fine either way, my argumentation for option2 would be 'make
woody more lightweight by making the most plausible settings the
easiest to make'
however if that adds to confusion rather then help out, then I'ld
like to follow your advice on that (just up to now I had the
feeling the choice wasn't presented well enough...)
making sense?
-marc=
> Best Regards,
>
> Antonio Gallardo
>
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
mpo@outerthought.org mpo@apache.org
Re: [RT] Woody and round trip of parameters.
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Marc Portier dijo:
> some attempt/proposal:
> definition-model declares field:
> case A: nothing special -> defaults to read-write
> case B: as being read-only
> case C: specific as read-write
>
> binding declared on field
> case 1: nothing special -> defaults to inherited from the field
> definition?
> case 2: as being read-only
> case 3: specific as read-write
>
>
> then what happens
> A.1 == C.3 == C.1 == A.3: full read-write on all stages
>
> B.2: data flows only from backend up to the browser
> B.1: binding level reads from the field definition that it is
> read-only and inherits the behaviour --> B.2
>
> B.3: binding level will save although the end user could not change
>
> A.2 = C.2: allow user change, but don't save back to the object-model
> (which sounds awkward? I don't see a case needing this ATM)
Sorry to said that but this is very complex. :(
I think we have only 2 case on every one, the nothing special case is a
normal default.
Best Regards,
Antonio Gallardo
Re: [RT] Woody and round trip of parameters.
Posted by Marc Portier <mp...@outerthought.org>.
Sylvain Wallez wrote:
> Bruno Dumon wrote:
>
<snip />
>
> I guess Antonio is talking about computed fields. For example, the
> "subtotal" above is the sum of all "amount" fields. Amounts are
> read-only, and subtotal is a fake field that has no binding to the
> application data model.
>
> I'm wondering if "read-only" is a property of the binding or of the
> field itself. It should be on the field, since it changes both the field
> rendering and it's handling of requests (it should not be parsed).
>
I think both apply
(see also my lengthy reply to Carsten on the position the binding
is taking in my head)
I agree that there should be a read-only property on the field
(in fact the repeater-unique-row-id binding in the samples calls
for such beast quite badly, that way we could remove them from
the form-template)
However that fact is split from the fact that the binding would
want to have one-way mapping as well:
so while indeed the 'read-only'-field couldn't have been changed
by the end-user (field-level read-only) it could of have been
changed by programming logic or some side-effects... the fact
that you want to save that change to the back-end objectmodel is
a different decission IMHO
(classic game example: automatically increase the number of
guesses, and 'display' that on the form. Clearly: do not accept
the end user to set it, but DO save that info to the backend)
and then there is the third aspect about these kind of fields
that is bound to pop up: does it need to be visible or not on the
end-user-form? --> for now you could just add it or leave it in
the template, but if we start mixing stuff in one file we'll need
to add this knowledge somewhere
yep, I know: 'woody is heavy' why require two (or three) when
most people will just want to say 'read-only' :-(
good news: we might just need to come up with the default and
delegation rules from one setting influencing the other so we
cover the 80% of cases with minimal editing, I would hate for us
to chase off the 20% others (on simple things like this)
some attempt/proposal:
definition-model declares field:
case A: nothing special -> defaults to read-write
case B: as being read-only
case C: specific as read-write
binding declared on field
case 1: nothing special -> defaults to inherited from the field
definition?
case 2: as being read-only
case 3: specific as read-write
then what happens
A.1 == C.3 == C.1 == A.3: full read-write on all stages
B.2: data flows only from backend up to the browser
B.1: binding level reads from the field definition that it is
read-only and inherits the behaviour --> B.2
B.3: binding level will save although the end user could not change
A.2 = C.2: allow user change, but don't save back to the object-model
(which sounds awkward? I don't see a case needing this ATM)
> Sylvain
>
HTH,
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
mpo@outerthought.org mpo@apache.org
Re: [RT] Woody and round trip of parameters.
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Sylvain Wallez dijo:
> I guess Antonio is talking about computed fields. For example, the
> "subtotal" above is the sum of all "amount" fields. Amounts are
> read-only, and subtotal is a fake field that has no binding to the
> application data model.
Yep. This is the idea. Also note this type of fields we does not need to
send back to the server. We can see an overall performance improvement
when saving network resources.
> I'm wondering if "read-only" is a property of the binding or of the
> field itself. It should be on the field, since it changes both the field
> rendering and it's handling of requests (it should not be parsed).
Right. It is a field related thing. Maybe in the final transformer we can
change the aparence of a field when it is a read-only.
Best Regards,
Antonio Gallardo
Re: [RT] Woody and round trip of parameters.
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Bruno Dumon wrote:
>On Tue, 2003-07-29 at 15:07, Antonio Gallardo wrote:
>
>
>>Hi:
>>
>>I had a concern about how to manage parameters that are flying between the
>>server and the client.
>>
>>It will worth if we have an attribute in the form that define when we are
>>waiting or not for a parameter back from the user?
>>
>>
>
>do you mean something like read-only fields?
>
>
>
>>I know woody has some formulas, I was not full review woody. :)
>>
>>I was thinking in some type of "formulas" or "equations" that we can send
>>to woody and let woody calculate them.
>>
>>
>
>sending formulas to woody? Me understand not :-)
>
>
>
>> ie: a tipical invoice
>>(master-detail):
>>
>>Date: 29-jul-2003 N° 2300
>>Client: Cocoon
>>
>>-------------------------------------------
>>Quantity Item Unit Price Amount
>>-------------------------------------------
>>2 pen $1.00 2.00
>>1 pencil $0.50 0.50
>>-------------------------------------------
>> Subtotal: 2.50
>> Shipping: 1.00
>> Total: 3.50
>>
>>Here we have some fields that are sended from the model (amount, subtotal,
>>total), but we dont need it back from the form.
>>
>>
>
>And here I get the impression that you're asking for one-directional binding? If so, checkout the readonly attribute on the wb:field element.
>
>Not sure I understood what you were asking for, but feel free to explain further.
>
I guess Antonio is talking about computed fields. For example, the
"subtotal" above is the sum of all "amount" fields. Amounts are
read-only, and subtotal is a fake field that has no binding to the
application data model.
I'm wondering if "read-only" is a property of the binding or of the
field itself. It should be on the field, since it changes both the field
rendering and it's handling of requests (it should not be parsed).
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [RT] Woody and round trip of parameters.
Posted by Bruno Dumon <br...@outerthought.org>.
On Tue, 2003-07-29 at 15:07, Antonio Gallardo wrote:
> Hi:
>
> I had a concern about how to manage parameters that are flying between the
> server and the client.
>
> It will worth if we have an attribute in the form that define when we are
> waiting or not for a parameter back from the user?
do you mean something like read-only fields?
>
> I know woody has some formulas, I was not full review woody. :)
>
> I was thinking in some type of "formulas" or "equations" that we can send
> to woody and let woody calculate them.
sending formulas to woody? Me understand not :-)
> ie: a tipical invoice
> (master-detail):
>
> Date: 29-jul-2003 N° 2300
> Client: Cocoon
>
> -------------------------------------------
> Quantity Item Unit Price Amount
> -------------------------------------------
> 2 pen $1.00 2.00
> 1 pencil $0.50 0.50
> -------------------------------------------
> Subtotal: 2.50
> Shipping: 1.00
> Total: 3.50
>
> Here we have some fields that are sended from the model (amount, subtotal,
> total), but we dont need it back from the form.
And here I get the impression that you're asking for one-directional
binding? If so, checkout the readonly attribute on the wb:field element.
Not sure I understood what you were asking for, but feel free to explain
further.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org