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 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)
Sylvain
HTH, -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]
