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 07:30:52 GMT


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/
mpo@outerthought.org                              mpo@apache.org


Mime
View raw message