cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: [RT] Woody and round trip of parameters.
Date Tue, 29 Jul 2003 15:44:19 GMT

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 
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

Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                        

View raw message