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/ [EMAIL PROTECTED] [EMAIL PROTECTED]
