Nope. No warning. DateRange doesn't extend anything. I don't know
which framework class generates the warning, but I did see the
following comment in ChangeWatcher.getEvents()

            // If host is not IEventDispatcher, no events will be dispatched,
            // regardless of metadata.
            // User-supplied [Bindable("eventname")] metadata within a
            // non-IEventDispatcher class is unlikely,
            // but not specifically prohibited by the compiler currently.


On Tue, May 20, 2008 at 11:30 PM, Josh McDonald <[EMAIL PROTECTED]> wrote:
> And you're not getting "foo is not an IEventDispatcher"? What's your
> DateRange class extend? It may already be an EventDispatcher. I left my
> testbed code at work, so I can't verify it for myself :)
>
> Most intriguing though.
>
> -J
>
> On Wed, May 21, 2008 at 3:54 PM, Richard Rodseth <[EMAIL PROTECTED]> wrote:
>>
>> I don't believe that's the case, Josh. I just ran it again, with
>> [Bindable] on the start property, but not the end property, and got
>> the warnings for end, but not for start.
>>
>> On Tue, May 20, 2008 at 10:30 PM, Josh McDonald <[EMAIL PROTECTED]> wrote:
>> > What you're doing there is just tricking the compiler into not giving
>> > you
>> > the warning, but you'll still get a run-tiAme warning in your console.
>> > You
>> > won't get updates if start ever changes, which in your case is what you
>> > want- but if it's simply read-only rather than immutable, you'll need
>> > the
>> > call to dispatchEvent().
>> >
>> > -J
>> >
>> > On Wed, May 21, 2008 at 3:21 PM, Richard Rodseth <[EMAIL PROTECTED]>
>> > wrote:
>> >>
>> >> Interesting. Actually, I just did this:
>> >>
>> >> [Bindable(event="foo")]
>> >> public function get start():Date {
>> >> return _start;
>> >> }
>> >>
>> >> without deriving from EventDispatcher (unnecessary, since I'm not
>> >> dispatching anywhere), and that also worked. So perhaps that's the
>> >> best approach, assuming the overhead of the [Bindable] tag is pretty
>> >> minimal.
>> >>
>> >> Without knowing much about the internals, I can't be sure whether/how
>> >> the warning could be more discriminating or informative, although I
>> >> would think the runtime could tell that the property is read-only and
>> >> not the root of the expression.
>> >>
>> >> Thanks.
>> >>
>> >> On Tue, May 20, 2008 at 9:43 PM, Josh McDonald <[EMAIL PROTECTED]>
>> >> wrote:
>> >> > Binding to read-only accessors does work with custom events:
>> >> >
>> >> > ------------------- testbed.xml
>> >> >
>> >> > <?xml version="1.0" encoding="utf-8"?>
>> >> > <mx:Application xmlns:mx="http://www.adobe.com/2006/mxml";
>> >> > layout="absolute"
>> >> > xmlns:ns1="*" >
>> >> >
>> >> > <ns1:TestBindings id="test"/>
>> >> > <mx:Label text="Testbed number is { test.publicNumber }"
>> >> > horizontalCenter="0" verticalCenter="0"/>
>> >> >
>> >> > <mx:Button label="Ouch!" horizontalCenter="0" verticalCenter="30"
>> >> > click="test.doIt()"/>
>> >> >
>> >> > </mx:Application>
>> >> >
>> >> > ------------------- TestBed.as
>> >> >
>> >> > package
>> >> > {
>> >> > import flash.events.Event;
>> >> > import flash.events.EventDispatcher;
>> >> >
>> >> > public class TestBindings extends EventDispatcher
>> >> > {
>> >> >
>> >> > private var myNumber : Number = 10;
>> >> >
>> >> > public function doIt() : void {
>> >> >
>> >> > myNumber++;
>> >> > dispatchEvent(new Event("numberUpdated"));
>> >> > }
>> >> >
>> >> > [Bindable(event="numberUpdated")]
>> >> > public function get publicNumber() : Number { return myNumber; }
>> >> > }
>> >> > }
>> >> > -------------------
>> >> >
>> >> > This works as you'd expect it to, so it is possible to bind to
>> >> > read-only
>> >> > (and therefore also to immutable, if that really floats your boat) so
>> >> > long
>> >> > as it's an IEventDispatcher.
>> >> >
>> >> > -J
>> >> >
>> >> > On Wed, May 21, 2008 at 2:34 PM, Alex Harui <[EMAIL PROTECTED]> wrote:
>> >> >>
>> >> >> Yup, that's why it is a warning. Sometimes you can ignore it.
>> >> >>
>> >> >>
>> >> >>
>> >> >> ________________________________
>> >> >>
>> >> >> From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED]
>> >> >> On
>> >> >> Behalf Of Richard Rodseth
>> >> >> Sent: Tuesday, May 20, 2008 9:11 PM
>> >> >> To: flexcoders@yahoogroups.com
>> >> >> Subject: Re: [flexcoders] "unable to bind to property" warnings
>> >> >> binding
>> >> >> to
>> >> >> read-only properties
>> >> >>
>> >> >>
>> >> >>
>> >> >> Message delivery failed. Trying again, this time with blog entry:
>> >> >>
>> >> >> http://flexygen.wordpress.com/2008/05/21/immutability-and-binding/
>> >> >>
>> >> >> On Tue, May 20, 2008 at 7:40 PM, Richard Rodseth
>> >> >> <[EMAIL PROTECTED]>
>> >> >> wrote:
>> >> >> > Yes, but the point is that DateRange.start is not changeable - the
>> >> >> > DateRange object can be replaced in its entirety, but its pieces
>> >> >> > can
>> >> >> > not be changed.
>> >> >> >
>> >> >> > I was able to get rid of the warnings by creating bindable getters
>> >> >> > in
>> >> >> > the component that used the expression, replacing the expression
>> >> >> > with
>> >> >> > {this.start}.
>> >> >> >
>> >> >> > I've also verified that with the original expression {range.start}
>> >> >> > the
>> >> >> > binding works despite the warning.
>> >> >> >
>> >> >> > On Tue, May 20, 2008 at 4:56 PM, Alex Harui <[EMAIL PROTECTED]>
>> >> >> > wrote:
>> >> >> >> Unless DateRenge.start is bindable, then there's no way we'd be
>> >> >> >> able
>> >> >> >> to
>> >> >> >> see
>> >> >> >> changes to it.
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> ________________________________
>> >> >> >>
>> >> >> >> From: flexcoders@yahoogroups.com
>> >> >> >> [mailto:[EMAIL PROTECTED]
>> >> >> >> On
>> >> >> >> Behalf Of Richard Rodseth
>> >> >> >> Sent: Tuesday, May 20, 2008 2:53 PM
>> >> >> >> To: flexcoders@yahoogroups.com
>> >> >> >> Subject: Re: [flexcoders] "unable to bind to property" warnings
>> >> >> >> binding
>> >> >> >> to
>> >> >> >> read-only properties
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> Just when I think I understand binding....
>> >> >> >>
>> >> >> >> I believe I have the same issue described below. I have an
>> >> >> >> immutable
>> >> >> >> class DateRange. Surely, if I have
>> >> >> >>
>> >> >> >> [Bindable]
>> >> >> >> public var range:DateRange;
>> >> >> >>
>> >> >> >> I should be able to have a binding expression
>> >> >> >> "{model.range.start}"
>> >> >> >> ?
>> >> >> >>
>> >> >> >> Thanks!
>> >> >> >>
>> >> >> >> On Thu, Jul 19, 2007 at 8:06 AM, mikebgrove
>> >> >> >> <[EMAIL PROTECTED]>
>> >> >> >> wrote:
>> >> >> >>> i make extensive use of read-only properties in my ActionScript
>> >> >> >>> code. i find that anywhere i try to bind to a read only property
>> >> >> >>> i
>> >> >> >>> get a warning in flex builder's debug mode indicating that flex
>> >> >> >>> can't
>> >> >> >>> bind to the property.
>> >> >> >>>
>> >> >> >>> here's a simple class to illustrate the point.
>> >> >> >>>
>> >> >> >>> package
>> >> >> >>> {
>> >> >> >>> public class Foo
>> >> >> >>> {
>> >> >> >>> public function get bar():String {
>> >> >> >>> return "bar";
>> >> >> >>> }
>> >> >> >>> }
>> >> >> >>> }
>> >> >> >>>
>> >> >> >>> if foo is an [Bindable] instance of Foo, then a binding to
>> >> >> >>> {foo.bar}
>> >> >> >>> will produce this warning:
>> >> >> >>>
>> >> >> >>> warning: unable to bind to property 'bar' on class 'Foo' (class
>> >> >> >>> is
>> >> >> >>> not an IEventDispatcher).
>> >> >> >>>
>> >> >> >>> Foo is not an IEventDispatcher, but since every property of Foo
>> >> >> >>> is
>> >> >> >>> immutable it shouldn't need to be.
>> >> >> >>>
>> >> >> >>> this may be a flex defect, judging by the title of the defect at
>> >> >> >>> http://bugs.adobe.com/jira/browse/SDK-1046. i've asked adobe
>> >> >> >>> support
>> >> >> >>> to make more details about this defect public.
>> >> >> >>>
>> >> >> >>> i'm interested in strategies to avoid this warning for read-only
>> >> >> >>> properties. in some cases this warning is instrumental in
>> >> >> >>> helping
>> >> >> >>> me
>> >> >> >>> figure out a binding problem, but unfortunately the important
>> >> >> >>> warnings are nearly impossible to find among the hundreds of
>> >> >> >>> irrelevant warnings for binding to read-only properties.
>> >> >> >>>
>> >> >> >>> here are some of the strategies i can think of, none great (i'll
>> >> >> >>> continue using the above Foo class as an example):
>> >> >> >>>
>> >> >> >>> 1) don't bind to {foo.bar}, bind to {getBar(foo)} or
>> >> >> >>> {foo.getBar()},
>> >> >> >>> adding the getBar method either to the MXML component trying to
>> >> >> >>> bind
>> >> >> >>> to foo or the Foo class itself.
>> >> >> >>> 2) declare the bar getter function as [Bindable] to a made up
>> >> >> >>> event
>> >> >> >>> name, e.g.
>> >> >> >>> [Bindable(event="barChangedNeverGonnaHappen")]
>> >> >> >>>
>> >> >> >>> are there other strategies people have employed to eliminate
>> >> >> >>> these
>> >> >> >>> warnings for read-only properties? i trust i'm not the only one
>> >> >> >>> whose eclipse debug console has been consumed with warnings like
>> >> >> >>> these.
>> >> >> >>>
>> >> >> >>> thanks.
>> >> >> >>>
>> >> >> >>> -mike
>> >> >> >>>
>> >> >> >>>
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >
>> >> >
>> >> > --
>> >> > "Therefore, send not to know For whom the bell tolls. It tolls for
>> >> > thee."
>> >> >
>> >> > :: Josh 'G-Funk' McDonald
>> >> > :: 0437 221 380 :: [EMAIL PROTECTED]
>> >> >
>> >
>> >
>> >
>> > --
>> > "Therefore, send not to know For whom the bell tolls. It tolls for
>> > thee."
>> >
>> > :: Josh 'G-Funk' McDonald
>> > :: 0437 221 380 :: [EMAIL PROTECTED]
>> >
>
>
>
> --
> "Therefore, send not to know For whom the bell tolls. It tolls for thee."
>
> :: Josh 'G-Funk' McDonald
> :: 0437 221 380 :: [EMAIL PROTECTED]
> 

Reply via email to