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 Wed, 30 Jul 2003 08:06:10 GMT

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 

> Furthermore, it could have an expression to compute its value.


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 Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                        

View raw message