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