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.
Sorry for added complexity, I was aiming for the opposite (well, I guess (only) good intentions are just no good ;-))
I was just trying to guess what would be intuitive and proposed that for any given field the @read-only for binding could default to the @read-only setting of the model-definition (rather then default to the fix value 'false')
maybe the following view expresses better what I try to achieve:
option 1: with classic defaulting (to false):
USER WANTS TO DO THIS: | USER NEEDS TO CONFIG THIS:
type of usage | required setting @read-only
| model binding
-------------------------+-------------------------------------
1/ the normal case | false (dflt) false (dflt)
2/ no editing/no binding | true true
3/ the game-example case | false (dflt) true
4/ no use? case | true false (dflt)
option 2: with 'smart' defaulting (i.e. binding-definition inherits from form-model-definition)
USER WANTS TO DO THIS: | USER NEEDS TO CONFIG THIS:
type of usage | required setting @read-only
| model binding
-------------------------+-------------------------------------
1/ the normal case | false (dflt) --> false (dflt)
2/ no editing/no binding | true --> true (dflt)
3/ the game-example case | false (dflt) true 4/ no use? case | true false
No assuming that I ordered the different types of usage from most likely used to least wanted (i.e. the case for which I haven't found any usage at the bottom) we see that option2 does a better effort at promoting usage 2/ over usage 4/
which I would translate as: it makes it more intuitive ?
I'm fine either way, my argumentation for option2 would be 'make woody more lightweight by making the most plausible settings the easiest to make'
however if that adds to confusion rather then help out, then I'ld like to follow your advice on that (just up to now I had the feeling the choice wasn't presented well enough...)
making sense?
-marc=
Best Regards,
Antonio Gallardo
-- 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]
