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
