On Thu, Sep 11, 2008 at 6:52 PM, BobV [EMAIL PROTECTED] wrote:
Is it the case that value=a and values=a are equivalent in their
behaviors?
Yes. (At least, I can't think of any reason it shouldn't work that way.)
--~--~-~--~~~---~--~~
AFAIK, no one is proposing that set-property changes the set of possible
values. I would certainly argue against that.
The upshot of all this is:
set-property gets another attribute called values that is mutually
exclusive with value:
set-property name=foo value=a/ // set property
On Thu, Sep 11, 2008 at 10:02 AM, Bruce Johnson [EMAIL PROTECTED] wrote:
AFAIK, no one is proposing that set-property changes the set of possible
values. I would certainly argue against that.
The upshot of all this is:
set-property gets another attribute called values that is mutually
On Tue, Sep 9, 2008 at 7:33 PM, BobV [EMAIL PROTECTED] wrote:
This patch against trunk allows multiple define-property tags for the
same deferred binding property. The second and subsequent definitions
of a property will override the allowable values and undo the effects
of any previous
Sorry, typo. See correction below.
On Wed, Sep 10, 2008 at 10:24 AM, Bruce Johnson [EMAIL PROTECTED] wrote:
I propose instead of allow set-property to have a values attribute as a
mutually-exclusive alternative to the value attribute:
I propose instead to allow set-property to have a values
Honestly, I'm a little torn about the interaction between restricting the
range of properties and an explicit set-property call. It feels like the
task of trying to restrict the range of valid properties shouldn't clobber a
previous pinpointing of exactly what property you want, because they seem
Why didn't you just put it that way the first time? :P
But seriously, my perhaps-silly thought was what about this sort of case
(assume ultimate lexical order):
Module 1 (say, UserAgent.gwt.xml)
define-property name=user.agent
values=ie6,gecko,gecko1_8,safari,opera/
Module 2 (a module that I'm
On Wed, Sep 10, 2008 at 12:10 PM, Bruce Johnson [EMAIL PROTECTED] wrote:
@Scott: Basically, why exactly don't you like my reasoning? Let me be more
concise to see if you find it more sensible:
define-property: introduces a property and its initial set of allowed
values; it is illegal to
It was the issue of repeated restrict range of values tags that made
me decide that define-property had a far more obvious semantic when
it's repeated. And, as a convenience to developers, you can add
additional property values with the one tag.
--
Bob Vawter
Google Web Toolkit Team
I agree with Bruce's design. The ability to widen an
initially-restricted set is compelling.
New thread that introduces non-deferred-binding properties:
http://groups.google.com/group/Google-Web-Toolkit-Contributors/t/fa19b93ae079af12
--
Bob Vawter
Google Web Toolkit Team
On Wed, Sep 10, 2008 at 7:37 PM, BobV [EMAIL PROTECTED] wrote:
They're the same thing. The previous set-value behavior is simply
limiting the number of active choices to exactly one.
As far as I can tell, set-property calls property.setActiveValue, which
simply updates the activeValue field.
I find all three cases (add, remove, set legal values) useful. For
gwt-log I'd like to offer developers the redefine capability. In other
contexts I can see add/remove being useful as well.
Fred
On 9/10/08, John Tamplin [EMAIL PROTECTED] wrote:
On Wed, Sep 10, 2008 at 7:22 PM, BobV [EMAIL
+1
I think this would be very useful. Indeed it would allow me to simplify my
.gwt.xml files in gwt-log a great deal.
Thanks
Fred Sauer
[EMAIL PROTECTED]
On Tue, Sep 9, 2008 at 5:33 PM, BobV [EMAIL PROTECTED] wrote:
This patch against trunk allows multiple define-property tags for the
same
13 matches
Mail list logo
