Hi Derrell,
I am also a fan of default values, at least in this case. But if I  
take 'null' as "nothing is set, use the default value", I could not  
set null anymore. The same is true for every other value we could use  
as placeholder for "nothing is set here".
So I guess we need to stick with the current solution or otherwise we  
could not supply null as valid model. :(
Best,
Martin

Am 11.11.2009 um 14:09 schrieb Derrell Lipman [via qooxdoo]:

> On Wed, Nov 11, 2009 at 04:24, MartinWittemann <[hidden email]> wrote:
>
> Hello Derrell,
>
> All model properties don't have the fallback to its value. What is  
> clear is,
> that we need to supply a possibility to specify a different model  
> than its
> value. But I don't know if we need a fallback to the value / label.  
> All
> other widgets not having the model property use the value so you  
> don't run
> into that problem.
>
> The only widgets with the model property which could have that  
> fallback are:
>
> qx.ui.form.RadioButton
> qx.ui.menu.RadioButton
> qx.ui.form.CheckBox
> qx.ui.toolbar.RadioButton
>
> qx.ui.form.ListItem
> qx.ui.tree.AbstractTreeItem
>
> The first group could have its value as fallback. So you get 'true' or
> 'false' as model if no model is specified. But how do we know that  
> no model
> is specified? Perhaps someone would like to have null as model?  
> Imagine a
> set of radio boxes with the first one showing "no thanks" or  
> anything like
> that.
> The same is true for the second group where it becomes the label  
> instead of
> the value.
> What do you think? I'm not sure which situation is worse. Either you  
> can not
> specify null as model or you have no fallback!
>
> Martin, I don't think I yet have enough experience with the data  
> binding to give an educated response. My only comment right now, I  
> guess, is that it seems inconsistent. I like the concept of "default  
> values" and in most cases, there are some, but in this case there  
> wasn't.
>
> I agree it should be possible to specify null, but if that's not the  
> common case then I'd likely prefer for the user to do that  
> explicitly on the rarer occasions that it's necessary than for the  
> user to always have to specify values that could be defaulted  
> automagically in the more typical case.
>
> Derrell
> Â
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008  
> 30-Day
> trial. Simplify your report design, integration and deployment - and  
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>
> View message @ 
> http://n2.nabble.com/Problem-with-forms-and-radio-buttons-tp3968702p3986337.html
> To unsubscribe from Re: Problem with forms and radio buttons, click  
> here.
>


-- 
View this message in context: 
http://n2.nabble.com/Problem-with-forms-and-radio-buttons-tp3968702p3998935.html
Sent from the qooxdoo mailing list archive at Nabble.com.
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Reply via email to