cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
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 
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


Mime
View raw message