Loading ...
Sorry, an error occurred while loading the content.
 

Re: [yui3] Re: Attribute "after" event, fire even if there are no changes

Expand Messages
  • Satyen Desai
    I think what you re doing right now: treating null (a.k.a. unfinished) as a default and valid value, along with black , oak , cherry is an accurate
    Message 1 of 10 , Sep 24, 2009
      I think what you're doing right now: treating null (a.k.a. unfinished)
      as a default and valid value, along with "black", "oak", "cherry" is
      an accurate representation IMO.

      I can see if it makes sense to be build a clear() method into the API
      (need to give it some thought - if you file an enhancement request,
      it'll make sure I won't forget about it, because I'm old),

      Regards,
      Satyen

      On Sep 24, 2009, at 12:25 PM, Andrew wrote:

      > You're spot on and your reasoning is basically the exact same line
      > of reasoning I've had. The one requirement we have is that if I
      > select "unfinishedChair" but then decline to set the stain color, I
      > want the UI to act as if I hadn't selected "unfinishedChair" at all.
      >
      > I like the reset idea so I'll try to implement that. A related
      > question is when you have an attribute that can have an
      > "uninitialized" state, what's a good way to handle that. TO do this,
      > I have attributes that can either be null or an integer, say. I
      > basically check to see if the value is not null to see if it's
      > initialized and then use it.
      >
      > This is a little inefficient since my validation method must now
      > allow null and there isn't a great API for this, but it could be
      > formalized like:
      >
      > this.clear("myAttribute"); // Different from reset, which might set
      > it to some default value.
      >
      > this.isSet("myAttribute"); // return true or false based on whether
      > it's been initialized.
      >
      > Anyways, maybe there's a way to do this already or you have some
      > better ideas.
      >
      > Thanks for all the input.
      >
      > - Andrew
      >
      > --- In yui3@yahoogroups.com, Satyen Desai <sdesai@...> wrote:
      > >
      > > Hey Andrew,
      > > Is the value state of the unselected objects in your array reflected
      > > anywhere?
      > >
      > > From your description (or rather my interpretation of "they must
      > then
      > > give a value to that object") it seems like the array is a source of
      > > default/generic objects/options, which users set a value for when
      > > selected.
      > >
      > > My interpretation:
      > >
      > > var furniture = [ unfinishedDesk, unfinishedChair,
      > unfinishedTable ];
      > > // your generic valued objects
      > > selected = furniture[1];
      > > selected.stain = "black"; // your value
      > >
      > > And your code as currently implemented, ends up storing black as the
      > > value of the unfinishedChair, after the first time it's been
      > selected
      > > and a value has been set, so that the next time an unfinishedChair
      > is
      > > selected and it's stain is set to "black", it doesn't fire a change
      > > event?
      > >
      > > If the above description is accurate (it may not be, again, my
      > > interpretation), then it seems like value should be reset when
      > > something is unselected [ or a new default valued object should be
      > > created on selection, but I can see there would be performance
      > reasons
      > > to avoid this, if it can just be reset ] to correctly reflect the
      > > application.
      > >
      > > Even otherwise, it seems like the selectedIndex change is what is
      > > initiating the update in the UI and should drive subsequent UI
      > updates
      > > for the item (so it's not really an update to it's value, but an
      > > initial rendering of the selected item)?
      > >
      > > This is not to say that attribute shouldn't have a way to configure
      > > the "same value" notification (it's pretty trivial to add). Just
      > > trying to figure out the use case behind it so it's not added as a
      > > knee jerk reaction.
      > >
      > > As mentioned, if you want to file an enhancement request for it, if
      > > possible with a URL/example, we can keep track of the conversation
      > in
      > > the request.
      > >
      > > Regards,
      > > Satyen
      > >
      > > On Sep 23, 2009, at 5:36 PM, Andrew wrote:
      > >
      > > > I'm building a widget that has an array of objects from which a
      > user
      > > > can choose. When a user selects an object, they must then give a
      > > > value to that object. If the user completes both of these steps
      > > > (essentially a two-phase commit), that object is marked as the
      > > > selected object and I want to fire an event to update some text on
      > > > the page reflecting the user's choice.
      > > >
      > > > My implementation of this is to attach a listener to the
      > > > "valueChange" event of each of the objects. The subscribed method
      > > > then updates an attribute that is the index of the object that was
      > > > just updated and then calls a method to update the text describing
      > > > which object was selected and what value was passed to it.
      > > >
      > > > This doesn't work if a user selects an object and inputs the value
      > > > that is already stored within that object.
      > > >
      > > > One idea would be to "reset" the value of that object and then
      > allow
      > > > the user to update it. I'd have to ignore the reset value in the
      > > > subscribed method, which might not be too bad.
      > > >
      > > > Any ideas?
      > > >
      > > > --- In yui3@yahoogroups.com, Satyen Desai <sdesai@> wrote:
      > > > >
      > > > > Hi,
      > > > > It would need to be something added to the attribute layer, as
      > an
      > > > > attribute configuration property.
      > > > >
      > > > > If you file an enhancement request, I can look into it for the
      > next
      > > > > 3.x release, however I'm not certain it's the right approach.
      > If you
      > > > > can file some details about your code/application in the
      > enhancement
      > > > > request, I can look into whether or not there's a better way
      > to go
      > > > > about what you're trying to achieve.
      > > > >
      > > > > - Satyen
      > > > >
      > > > > On Sep 22, 2009, at 8:47 PM, Andrew wrote:
      > > > >
      > > > > > I need to have the attribute "after" event fire regardless of
      > > > > > whether that attribute has been updated. I need a hook that
      > says
      > > > the
      > > > > > user tried to change that value and it succeeded -- either
      > because
      > > > > > the value changed or because they input the same, valid value.
      > > > > >
      > > > > > Any thoughts on a way to do this or is this going to be
      > integrated
      > > > > > into the Event utility at some point?
      > > > > >
      > > > > >
      > > > > >
      > > > >
      > > >
      > > >
      > > >
      > >
      >
      >
      >
    • Eric Ferraiuolo
      Just to try to add a little something here… I ve also been using Attribute definitions which allow null and a string with a length 0 as valid values. e.g.
      Message 2 of 10 , Sep 25, 2009
        Just to try to add a little something here…

        I've also been using Attribute definitions which allow null and a string with a length > 0 as valid values.

        e.g.

        subject : {

        value : null,

        validator : function (v) {

        return this._validateNewSubject(v);

        }

        },


        Where _validateNewSubject looks like:

        _validateNewSubject : function (v) {

        return ( isNull(v) || (isString(v) && v.length > 0) );

        },


        This works and allows me to call this.reset('subject'); to put the value back to null; I did notice that if I didn't provide a default value for the Attribute, reset didn't behave as I expected.

        Not sure how much this will help, but I've been using a feature of the Event and Attribute API to add some extra metadata about the change to an attribute. My _afterSubjectChange event handler looks like this:

        _afterSubjectChange : function (e) {

        if ( ! e.supressSyncUI ) {

        this._syncSubject(e.newVal);

        }

        },


        And in certain cases I set the Attributes value as follows:

        this.set(SUBJECT, subjectNode.get(VALUE), { supressSyncUI:true });


        Which is called from within my _syncSubject methods:

        _syncSubject : function (subject) {

        var subjectNode = this.get(SUBJECT_NODE);

        if (this._validateNewSubject(subject) && subjectNode) {

        subjectNode.set(VALUE, subject);

        } else if (subjectNode) {

        this.set(SUBJECT, subjectNode.get(VALUE), { supressSyncUI:true });

        }

        },


        This is where I ended up with my custom Widget code to prevent an endless update loop. This widget has an input[type=text] Node and a managed Attribute for Subject. I wanted to use an Attribute to define the default value and validation for a Subject, and provide a textbox for the user to be able to update the subject through the web form. The hard part here was keeping these things in sync. I wanted to make sure I could programmatically update the value of the input, as well as allow the user to edit the input's value, and sync the value back to the Attribute.

        Event listeners can be attached to the Subject textbook Node, e.g. onBlur, to call this._syncSubject(); which will set the value of the Subject Attribute to the value of the input Node, and suppress a UI change since the input already has this value.

        I've been finding that developing Widgets which have forms for users to change inputs being a pretty complicated thing; I'm wondering what could be done to make this easier?



        Eric

        On Thu, Sep 24, 2009 at 3:25 PM, Andrew <andrew.bialecki@...> wrote:
         

        You're spot on and your reasoning is basically the exact same line of reasoning I've had. The one requirement we have is that if I select "unfinishedChair" but then decline to set the stain color, I want the UI to act as if I hadn't selected "unfinishedChair" at all.

        I like the reset idea so I'll try to implement that. A related question is when you have an attribute that can have an "uninitialized" state, what's a good way to handle that. TO do this, I have attributes that can either be null or an integer, say. I basically check to see if the value is not null to see if it's initialized and then use it.

        This is a little inefficient since my validation method must now allow null and there isn't a great API for this, but it could be formalized like:

        this.clear("myAttribute"); // Different from reset, which might set it to some default value.

        this.isSet("myAttribute"); // return true or false based on whether it's been initialized.

        Anyways, maybe there's a way to do this already or you have some better ideas.

        Thanks for all the input.

        - Andrew



        --- In yui3@yahoogroups.com, Satyen Desai <sdesai@...> wrote:
        >
        > Hey Andrew,
        > Is the value state of the unselected objects in your array reflected
        > anywhere?
        >
        > From your description (or rather my interpretation of "they must then
        > give a value to that object") it seems like the array is a source of
        > default/generic objects/options, which users set a value for when
        > selected.
        >
        > My interpretation:
        >
        > var furniture = [ unfinishedDesk, unfinishedChair, unfinishedTable ];
        > // your generic valued objects
        > selected = furniture[1];
        > selected.stain = "black"; // your value
        >
        > And your code as currently implemented, ends up storing black as the
        > value of the unfinishedChair, after the first time it's been selected
        > and a value has been set, so that the next time an unfinishedChair is
        > selected and it's stain is set to "black", it doesn't fire a change
        > event?
        >
        > If the above description is accurate (it may not be, again, my
        > interpretation), then it seems like value should be reset when
        > something is unselected [ or a new default valued object should be
        > created on selection, but I can see there would be performance reasons
        > to avoid this, if it can just be reset ] to correctly reflect the
        > application.
        >
        > Even otherwise, it seems like the selectedIndex change is what is
        > initiating the update in the UI and should drive subsequent UI updates
        > for the item (so it's not really an update to it's value, but an
        > initial rendering of the selected item)?
        >
        > This is not to say that attribute shouldn't have a way to configure
        > the "same value" notification (it's pretty trivial to add). Just
        > trying to figure out the use case behind it so it's not added as a
        > knee jerk reaction.
        >
        > As mentioned, if you want to file an enhancement request for it, if
        > possible with a URL/example, we can keep track of the conversation in
        > the request.
        >
        > Regards,
        > Satyen
        >
        > On Sep 23, 2009, at 5:36 PM, Andrew wrote:
        >
        > > I'm building a widget that has an array of objects from which a user
        > > can choose. When a user selects an object, they must then give a
        > > value to that object. If the user completes both of these steps
        > > (essentially a two-phase commit), that object is marked as the
        > > selected object and I want to fire an event to update some text on
        > > the page reflecting the user's choice.
        > >
        > > My implementation of this is to attach a listener to the
        > > "valueChange" event of each of the objects. The subscribed method
        > > then updates an attribute that is the index of the object that was
        > > just updated and then calls a method to update the text describing
        > > which object was selected and what value was passed to it.
        > >
        > > This doesn't work if a user selects an object and inputs the value
        > > that is already stored within that object.
        > >
        > > One idea would be to "reset" the value of that object and then allow
        > > the user to update it. I'd have to ignore the reset value in the
        > > subscribed method, which might not be too bad.
        > >
        > > Any ideas?
        > >
        > > --- In yui3@yahoogroups.com, Satyen Desai <sdesai@> wrote:
        > > >
        > > > Hi,
        > > > It would need to be something added to the attribute layer, as an
        > > > attribute configuration property.
        > > >
        > > > If you file an enhancement request, I can look into it for the next
        > > > 3.x release, however I'm not certain it's the right approach. If you
        > > > can file some details about your code/application in the enhancement
        > > > request, I can look into whether or not there's a better way to go
        > > > about what you're trying to achieve.
        > > >
        > > > - Satyen
        > > >
        > > > On Sep 22, 2009, at 8:47 PM, Andrew wrote:
        > > >
        > > > > I need to have the attribute "after" event fire regardless of
        > > > > whether that attribute has been updated. I need a hook that says
        > > the
        > > > > user tried to change that value and it succeeded -- either because
        > > > > the value changed or because they input the same, valid value.
        > > > >
        > > > > Any thoughts on a way to do this or is this going to be integrated
        > > > > into the Event utility at some point?
        > > > >
        > > > >
        > > > >
        > > >
        > >
        > >
        > >
        >


      • Satyen Desai
        Hey Eric, The additional argument to add src data to the attribute event payload was added specifically for the use case you describe:
        Message 3 of 10 , Sep 25, 2009
          Hey Eric,

          The additional argument to add "src" data to the attribute event
          payload was added specifically for the use case you describe:

          http://yuilibrary.com/projects/yui3/ticket/2527933
          http://yuilibrary.com/forum/viewtopic.php?f=92&t=792&p=2917&hilit=Attribute+silent#p2917

          I can see a Form plugin/extension, which would bind a Widget's
          attributes to a Form [ mapping input elements to attributes ] and
          handle the two way sync with loop avoidance, to avoid the pain you
          mention.

          Regards,
          Satyen

          On Sep 25, 2009, at 10:11 AM, Eric Ferraiuolo wrote:

          > Just to try to add a little something here…
          >
          >
          > I've also been using Attribute definitions which allow null and a
          > string with a length > 0 as valid values.
          >
          > e.g.
          >
          > subject : {
          >
          > value : null,
          >
          > validator : function (v) {
          >
          > return this._validateNewSubject(v);
          >
          > }
          >
          > },
          >
          >
          >
          > Where _validateNewSubject looks like:
          >
          > _validateNewSubject : function (v) {
          >
          >
          > return ( isNull(v) || (isString(v) && v.length > 0) );
          >
          > },
          >
          >
          > This works and allows me to call this.reset('subject'); to put the
          > value back to null; I did notice that if I didn't provide a default
          > value for the Attribute, reset didn't behave as I expected.
          >
          > Not sure how much this will help, but I've been using a feature of
          > the Event and Attribute API to add some extra metadata about the
          > change to an attribute. My _afterSubjectChange event handler looks
          > like this:
          >
          > _afterSubjectChange : function (e) {
          >
          >
          > if ( ! e.supressSyncUI ) {
          >
          > this._syncSubject(e.newVal);
          >
          > }
          >
          > },
          >
          >
          > And in certain cases I set the Attributes value as follows:
          >
          > this.set(SUBJECT, subjectNode.get(VALUE), { supressSyncUI:true });
          >
          >
          > Which is called from within my _syncSubject methods:
          >
          > _syncSubject : function (subject) {
          >
          >
          > var subjectNode = this.get(SUBJECT_NODE);
          >
          >
          > if (this._validateNewSubject(subject) && subjectNode) {
          >
          > subjectNode.set(VALUE, subject);
          >
          > } else if (subjectNode) {
          >
          > this.set(SUBJECT, subjectNode.get(VALUE), {supressSyncUI:true });
          >
          > }
          >
          > },
          >
          >
          > This is where I ended up with my custom Widget code to prevent an
          > endless update loop. This widget has an input[type=text] Node and a
          > managed Attribute for Subject. I wanted to use an Attribute to
          > define the default value and validation for a Subject, and provide a
          > textbox for the user to be able to update the subject through the
          > web form. The hard part here was keeping these things in sync. I
          > wanted to make sure I could programmatically update the value of the
          > input, as well as allow the user to edit the input's value, and sync
          > the value back to the Attribute.
          >
          > Event listeners can be attached to the Subject textbook Node, e.g.
          > onBlur, to call this._syncSubject(); which will set the value of the
          > Subject Attribute to the value of the input Node, and suppress a UI
          > change since the input already has this value.
          >
          > I've been finding that developing Widgets which have forms for users
          > to change inputs being a pretty complicated thing; I'm wondering
          > what could be done to make this easier?
          >
          >
          >
          > Eric
          >
          > On Thu, Sep 24, 2009 at 3:25 PM, Andrew <andrew.bialecki@...>
          > wrote:
          >
          > You're spot on and your reasoning is basically the exact same line
          > of reasoning I've had. The one requirement we have is that if I
          > select "unfinishedChair" but then decline to set the stain color, I
          > want the UI to act as if I hadn't selected "unfinishedChair" at all.
          >
          > I like the reset idea so I'll try to implement that. A related
          > question is when you have an attribute that can have an
          > "uninitialized" state, what's a good way to handle that. TO do this,
          > I have attributes that can either be null or an integer, say. I
          > basically check to see if the value is not null to see if it's
          > initialized and then use it.
          >
          > This is a little inefficient since my validation method must now
          > allow null and there isn't a great API for this, but it could be
          > formalized like:
          >
          > this.clear("myAttribute"); // Different from reset, which might set
          > it to some default value.
          >
          > this.isSet("myAttribute"); // return true or false based on whether
          > it's been initialized.
          >
          > Anyways, maybe there's a way to do this already or you have some
          > better ideas.
          >
          > Thanks for all the input.
          >
          > - Andrew
          >
          >
          >
          > --- In yui3@yahoogroups.com, Satyen Desai <sdesai@...> wrote:
          > >
          > > Hey Andrew,
          > > Is the value state of the unselected objects in your array reflected
          > > anywhere?
          > >
          > > From your description (or rather my interpretation of "they must
          > then
          > > give a value to that object") it seems like the array is a source of
          > > default/generic objects/options, which users set a value for when
          > > selected.
          > >
          > > My interpretation:
          > >
          > > var furniture = [ unfinishedDesk, unfinishedChair,
          > unfinishedTable ];
          > > // your generic valued objects
          > > selected = furniture[1];
          > > selected.stain = "black"; // your value
          > >
          > > And your code as currently implemented, ends up storing black as the
          > > value of the unfinishedChair, after the first time it's been
          > selected
          > > and a value has been set, so that the next time an unfinishedChair
          > is
          > > selected and it's stain is set to "black", it doesn't fire a change
          > > event?
          > >
          > > If the above description is accurate (it may not be, again, my
          > > interpretation), then it seems like value should be reset when
          > > something is unselected [ or a new default valued object should be
          > > created on selection, but I can see there would be performance
          > reasons
          > > to avoid this, if it can just be reset ] to correctly reflect the
          > > application.
          > >
          > > Even otherwise, it seems like the selectedIndex change is what is
          > > initiating the update in the UI and should drive subsequent UI
          > updates
          > > for the item (so it's not really an update to it's value, but an
          > > initial rendering of the selected item)?
          > >
          > > This is not to say that attribute shouldn't have a way to configure
          > > the "same value" notification (it's pretty trivial to add). Just
          > > trying to figure out the use case behind it so it's not added as a
          > > knee jerk reaction.
          > >
          > > As mentioned, if you want to file an enhancement request for it, if
          > > possible with a URL/example, we can keep track of the conversation
          > in
          > > the request.
          > >
          > > Regards,
          > > Satyen
          > >
          > > On Sep 23, 2009, at 5:36 PM, Andrew wrote:
          > >
          > > > I'm building a widget that has an array of objects from which a
          > user
          > > > can choose. When a user selects an object, they must then give a
          > > > value to that object. If the user completes both of these steps
          > > > (essentially a two-phase commit), that object is marked as the
          > > > selected object and I want to fire an event to update some text on
          > > > the page reflecting the user's choice.
          > > >
          > > > My implementation of this is to attach a listener to the
          > > > "valueChange" event of each of the objects. The subscribed method
          > > > then updates an attribute that is the index of the object that was
          > > > just updated and then calls a method to update the text describing
          > > > which object was selected and what value was passed to it.
          > > >
          > > > This doesn't work if a user selects an object and inputs the value
          > > > that is already stored within that object.
          > > >
          > > > One idea would be to "reset" the value of that object and then
          > allow
          > > > the user to update it. I'd have to ignore the reset value in the
          > > > subscribed method, which might not be too bad.
          > > >
          > > > Any ideas?
          > > >
          > > > --- In yui3@yahoogroups.com, Satyen Desai <sdesai@> wrote:
          > > > >
          > > > > Hi,
          > > > > It would need to be something added to the attribute layer, as
          > an
          > > > > attribute configuration property.
          > > > >
          > > > > If you file an enhancement request, I can look into it for the
          > next
          > > > > 3.x release, however I'm not certain it's the right approach.
          > If you
          > > > > can file some details about your code/application in the
          > enhancement
          > > > > request, I can look into whether or not there's a better way
          > to go
          > > > > about what you're trying to achieve.
          > > > >
          > > > > - Satyen
          > > > >
          > > > > On Sep 22, 2009, at 8:47 PM, Andrew wrote:
          > > > >
          > > > > > I need to have the attribute "after" event fire regardless of
          > > > > > whether that attribute has been updated. I need a hook that
          > says
          > > > the
          > > > > > user tried to change that value and it succeeded -- either
          > because
          > > > > > the value changed or because they input the same, valid value.
          > > > > >
          > > > > > Any thoughts on a way to do this or is this going to be
          > integrated
          > > > > > into the Event utility at some point?
          > > > > >
          > > > > >
          > > > > >
          > > > >
          > > >
          > > >
          > > >
          > >
          >
          >
          >
          >
          >
        • Eric Ferraiuolo
          See you write stuff like: I can see a Form plugin/extension, which would bind a Widget s attributes to a Form [ mapping input elements to attributes ] and
          Message 4 of 10 , Sep 25, 2009
            See you write stuff like: "I can see a Form plugin/extension, which would bind a Widget's attributes to a Form [ mapping input elements to attributes ] and handle the two way sync with loop avoidance" and it will get me off track for today's work and want to implement it :-)

            I do agree, this would be useful, and something I'd be able to utilize in my current application and large set of custom widgets. I'm pretty happy with were I landed with the Widget I posted code sample from in this thread; I think I'll update my supressSyncUI to src like the code in Widget and what it does for the focused attribute.

            The hard part, I feel, is trying to figure out wether to group this type of functionality into an Extension or Plugin…



            Eric

            On Fri, Sep 25, 2009 at 2:18 PM, Satyen Desai <sdesai@...> wrote:
            Hey Eric,

            The additional argument to add "src" data to the attribute event
            payload was added specifically for the use case you describe:

                http://yuilibrary.com/projects/yui3/ticket/2527933
                http://yuilibrary.com/forum/viewtopic.php?f=92&t=792&p=2917&hilit=Attribute+silent#p2917

            I can see a Form plugin/extension, which would bind a Widget's
            attributes to a Form [ mapping input elements to attributes ] and
            handle the two way sync with loop avoidance, to avoid the pain you
            mention.

            Regards,
            Satyen

            On Sep 25, 2009, at 10:11 AM, Eric Ferraiuolo wrote:

            > Just to try to add a little something here…
            >
            >
            > I've also been using Attribute definitions which allow null and a
            > string with a length > 0 as valid values.
            >
            > e.g.
            >
            > subject : {
            >
            >       value : null,
            >
            >       validator : function (v) {
            >
            >               return this._validateNewSubject(v);
            >
            >       }
            >
            > },
            >
            >
            >
            > Where _validateNewSubject looks like:
            >
            > _validateNewSubject : function (v) {
            >
            >
            >       return ( isNull(v) || (isString(v) && v.length > 0) );
            >
            > },
            >
            >
            > This works and allows me to call this.reset('subject'); to put the
            > value back to null; I did notice that if I didn't provide a default
            > value for the Attribute, reset didn't behave as I expected.
            >
            > Not sure how much this will help, but I've been using a feature of
            > the Event and Attribute API to add some extra metadata about the
            > change to an attribute. My _afterSubjectChange event handler looks
            > like this:
            >
            > _afterSubjectChange : function (e) {
            >
            >
            >       if ( ! e.supressSyncUI ) {
            >
            >               this._syncSubject(e.newVal);
            >
            >       }
            >
            > },
            >
            >
            > And in certain cases I set the Attributes value as follows:
            >
            > this.set(SUBJECT, subjectNode.get(VALUE), { supressSyncUI:true });
            >
            >
            > Which is called from within my _syncSubject methods:
            >
            > _syncSubject : function (subject) {
            >
            >
            >       var subjectNode = this.get(SUBJECT_NODE);
            >
            >
            >       if (this._validateNewSubject(subject) && subjectNode) {
            >
            >               subjectNode.set(VALUE, subject);
            >
            >       } else if (subjectNode) {
            >
            >               this.set(SUBJECT, subjectNode.get(VALUE), {supressSyncUI:true });
            >
            >       }
            >
            > },
            >
            >
            > This is where I ended up with my custom Widget code to prevent an
            > endless update loop. This widget has an input[type=text] Node and a
            > managed Attribute for Subject. I wanted to use an Attribute to
            > define the default value and validation for a Subject, and provide a
            > textbox for the user to be able to update the subject through the
            > web form. The hard part here was keeping these things in sync. I
            > wanted to make sure I could programmatically update the value of the
            > input, as well as allow the user to edit the input's value, and sync
            > the value back to the Attribute.
            >
            > Event listeners can be attached to the Subject textbook Node, e.g.
            > onBlur, to call this._syncSubject(); which will set the value of the
            > Subject Attribute to the value of the input Node, and suppress a UI
            > change since the input already has this value.
            >
            > I've been finding that developing Widgets which have forms for users
            > to change inputs being a pretty complicated thing; I'm wondering
            > what could be done to make this easier?
            >
            >
            >
            > Eric
            >
            > On Thu, Sep 24, 2009 at 3:25 PM, Andrew <andrew.bialecki@...>
            > wrote:
            >
            > You're spot on and your reasoning is basically the exact same line
            > of reasoning I've had. The one requirement we have is that if I
            > select "unfinishedChair" but then decline to set the stain color, I
            > want the UI to act as if I hadn't selected "unfinishedChair" at all.
            >
            > I like the reset idea so I'll try to implement that. A related
            > question is when you have an attribute that can have an
            > "uninitialized" state, what's a good way to handle that. TO do this,
            > I have attributes that can either be null or an integer, say. I
            > basically check to see if the value is not null to see if it's
            > initialized and then use it.
            >
            > This is a little inefficient since my validation method must now
            > allow null and there isn't a great API for this, but it could be
            > formalized like:
            >
            > this.clear("myAttribute"); // Different from reset, which might set
            > it to some default value.
            >
            > this.isSet("myAttribute"); // return true or false based on whether
            > it's been initialized.
            >
            > Anyways, maybe there's a way to do this already or you have some
            > better ideas.
            >
            > Thanks for all the input.
            >
            > - Andrew
            >
            >
            >
            > --- In yui3@yahoogroups.com, Satyen Desai <sdesai@...> wrote:
            > >
            > > Hey Andrew,
            > > Is the value state of the unselected objects in your array reflected
            > > anywhere?
            > >
            > > From your description (or rather my interpretation of "they must
            > then
            > > give a value to that object") it seems like the array is a source of
            > > default/generic objects/options, which users set a value for when
            > > selected.
            > >
            > > My interpretation:
            > >
            > > var furniture = [ unfinishedDesk, unfinishedChair,
            > unfinishedTable ];
            > > // your generic valued objects
            > > selected = furniture[1];
            > > selected.stain = "black";    // your value
            > >
            > > And your code as currently implemented, ends up storing black as the
            > > value of the unfinishedChair, after the first time it's been
            > selected
            > > and a value has been set, so that the next time an unfinishedChair
            > is
            > > selected and it's stain is set to "black", it doesn't fire a change
            > > event?
            > >
            > > If the above description is accurate (it may not be, again, my
            > > interpretation), then it seems like value should be reset when
            > > something is unselected [ or a new default valued object should be
            > > created on selection, but I can see there would be performance
            > reasons
            > > to avoid this, if it can just be reset ] to correctly reflect the
            > > application.
            > >
            > > Even otherwise, it seems like the selectedIndex change is what is
            > > initiating the update in the UI and should drive subsequent UI
            > updates
            > > for the item (so it's not really an update to it's value, but an
            > > initial rendering of the selected item)?
            > >
            > > This is not to say that attribute shouldn't have a way to configure
            > > the "same value" notification (it's pretty trivial to add). Just
            > > trying to figure out the use case behind it so it's not added as a
            > > knee jerk reaction.
            > >
            > > As mentioned, if you want to file an enhancement request for it, if
            > > possible with a URL/example, we can keep track of the conversation
            > in
            > > the request.
            > >
            > > Regards,
            > > Satyen
            > >
            > > On Sep 23, 2009, at 5:36 PM, Andrew wrote:
            > >
            > > > I'm building a widget that has an array of objects from which a
            > user
            > > > can choose. When a user selects an object, they must then give a
            > > > value to that object. If the user completes both of these steps
            > > > (essentially a two-phase commit), that object is marked as the
            > > > selected object and I want to fire an event to update some text on
            > > > the page reflecting the user's choice.
            > > >
            > > > My implementation of this is to attach a listener to the
            > > > "valueChange" event of each of the objects. The subscribed method
            > > > then updates an attribute that is the index of the object that was
            > > > just updated and then calls a method to update the text describing
            > > > which object was selected and what value was passed to it.
            > > >
            > > > This doesn't work if a user selects an object and inputs the value
            > > > that is already stored within that object.
            > > >
            > > > One idea would be to "reset" the value of that object and then
            > allow
            > > > the user to update it. I'd have to ignore the reset value in the
            > > > subscribed method, which might not be too bad.
            > > >
            > > > Any ideas?
            > > >
            > > > --- In yui3@yahoogroups.com, Satyen Desai <sdesai@> wrote:
            > > > >
            > > > > Hi,
            > > > > It would need to be something added to the attribute layer, as
            > an
            > > > > attribute configuration property.
            > > > >
            > > > > If you file an enhancement request, I can look into it for the
            > next
            > > > > 3.x release, however I'm not certain it's the right approach.
            > If you
            > > > > can file some details about your code/application in the
            > enhancement
            > > > > request, I can look into whether or not there's a better way
            > to go
            > > > > about what you're trying to achieve.
            > > > >
            > > > > - Satyen
            > > > >
            > > > > On Sep 22, 2009, at 8:47 PM, Andrew wrote:
            > > > >
            > > > > > I need to have the attribute "after" event fire regardless of
            > > > > > whether that attribute has been updated. I need a hook that
            > says
            > > > the
            > > > > > user tried to change that value and it succeeded -- either
            > because
            > > > > > the value changed or because they input the same, valid value.
            > > > > >
            > > > > > Any thoughts on a way to do this or is this going to be
            > integrated
            > > > > > into the Event utility at some point?
            > > > > >
            > > > > >
            > > > > >
            > > > >
            > > >
            > > >
            > > >
            > >
            >
            >
            >
            >
            >



            ------------------------------------

            Yahoo! Groups Links

            <*> To visit your group on the web, go to:
               http://groups.yahoo.com/group/yui3/

            <*> Your email settings:
               Individual Email | Traditional

            <*> To change settings online go to:
               http://groups.yahoo.com/group/yui3/join
               (Yahoo! ID required)

            <*> To change settings via email:
               mailto:yui3-digest@yahoogroups.com
               mailto:yui3-fullfeatured@yahoogroups.com

            <*> To unsubscribe from this group, send an email to:
               yui3-unsubscribe@yahoogroups.com

            <*> Your use of Yahoo! Groups is subject to:
               http://docs.yahoo.com/info/terms/


          • Satyen Desai
            ... That was the idea :). ... I think a plugin is the right place to start - something which can be added to an instance of any widget, if it s content
            Message 5 of 10 , Sep 25, 2009
              > See you write stuff like: "I can see a Form plugin/extension, which
              > would bind a Widget's attributes to a Form [ mapping input elements
              > to attributes ] and handle the two way sync with loop avoidance" and
              > it will get me off track for today's work and want to implement it :-)
              >
              That was the idea :).

              > The hard part, I feel, is trying to figure out wether to group this
              > type of functionality into an Extension or Plugin…


              I think a plugin is the right place to start - something which can be
              added to an instance of any widget, if it's content "happens" to
              contain a form.

              I think it would make sense as an extension if there was a particular
              "Class" of Widget, which was "required" to have form content (a Dialog
              or Wizard comes to mind).

              Regards,
              Satyen

              On Sep 25, 2009, at 12:17 PM, Eric Ferraiuolo wrote:

              > See you write stuff like: "I can see a Form plugin/extension, which
              > would bind a Widget's attributes to a Form [ mapping input elements
              > to attributes ] and handle the two way sync with loop avoidance" and
              > it will get me off track for today's work and want to implement it :-)
              >
              >
              > I do agree, this would be useful, and something I'd be able to
              > utilize in my current application and large set of custom widgets.
              > I'm pretty happy with were I landed with the Widget I posted code
              > sample from in this thread; I think I'll update my supressSyncUI to
              > src like the code in Widget and what it does for the focused
              > attribute.
              >
              > The hard part, I feel, is trying to figure out wether to group this
              > type of functionality into an Extension or Plugin…
              >
              >
              >
              > Eric
              >
              > On Fri, Sep 25, 2009 at 2:18 PM, Satyen Desai <sdesai@...>
              > wrote:
              > Hey Eric,
              >
              > The additional argument to add "src" data to the attribute event
              > payload was added specifically for the use case you describe:
              >
              > http://yuilibrary.com/projects/yui3/ticket/2527933
              > http://yuilibrary.com/forum/viewtopic.php?f=92&t=792&p=2917&hilit=Attribute+silent#p2917
              >
              > I can see a Form plugin/extension, which would bind a Widget's
              > attributes to a Form [ mapping input elements to attributes ] and
              > handle the two way sync with loop avoidance, to avoid the pain you
              > mention.
              >
              > Regards,
              > Satyen
              >
              > On Sep 25, 2009, at 10:11 AM, Eric Ferraiuolo wrote:
              >
              > > Just to try to add a little something here…
              > >
              > >
              > > I've also been using Attribute definitions which allow null and a
              > > string with a length > 0 as valid values.
              > >
              > > e.g.
              > >
              > > subject : {
              > >
              > > value : null,
              > >
              > > validator : function (v) {
              > >
              > > return this._validateNewSubject(v);
              > >
              > > }
              > >
              > > },
              > >
              > >
              > >
              > > Where _validateNewSubject looks like:
              > >
              > > _validateNewSubject : function (v) {
              > >
              > >
              > > return ( isNull(v) || (isString(v) && v.length > 0) );
              > >
              > > },
              > >
              > >
              > > This works and allows me to call this.reset('subject'); to put the
              > > value back to null; I did notice that if I didn't provide a default
              > > value for the Attribute, reset didn't behave as I expected.
              > >
              > > Not sure how much this will help, but I've been using a feature of
              > > the Event and Attribute API to add some extra metadata about the
              > > change to an attribute. My _afterSubjectChange event handler looks
              > > like this:
              > >
              > > _afterSubjectChange : function (e) {
              > >
              > >
              > > if ( ! e.supressSyncUI ) {
              > >
              > > this._syncSubject(e.newVal);
              > >
              > > }
              > >
              > > },
              > >
              > >
              > > And in certain cases I set the Attributes value as follows:
              > >
              > > this.set(SUBJECT, subjectNode.get(VALUE), { supressSyncUI:true });
              > >
              > >
              > > Which is called from within my _syncSubject methods:
              > >
              > > _syncSubject : function (subject) {
              > >
              > >
              > > var subjectNode = this.get(SUBJECT_NODE);
              > >
              > >
              > > if (this._validateNewSubject(subject) && subjectNode) {
              > >
              > > subjectNode.set(VALUE, subject);
              > >
              > > } else if (subjectNode) {
              > >
              > > this.set(SUBJECT, subjectNode.get(VALUE),
              > {supressSyncUI:true });
              > >
              > > }
              > >
              > > },
              > >
              > >
              > > This is where I ended up with my custom Widget code to prevent an
              > > endless update loop. This widget has an input[type=text] Node and a
              > > managed Attribute for Subject. I wanted to use an Attribute to
              > > define the default value and validation for a Subject, and provide a
              > > textbox for the user to be able to update the subject through the
              > > web form. The hard part here was keeping these things in sync. I
              > > wanted to make sure I could programmatically update the value of the
              > > input, as well as allow the user to edit the input's value, and sync
              > > the value back to the Attribute.
              > >
              > > Event listeners can be attached to the Subject textbook Node, e.g.
              > > onBlur, to call this._syncSubject(); which will set the value of the
              > > Subject Attribute to the value of the input Node, and suppress a UI
              > > change since the input already has this value.
              > >
              > > I've been finding that developing Widgets which have forms for users
              > > to change inputs being a pretty complicated thing; I'm wondering
              > > what could be done to make this easier?
              > >
              > >
              > >
              > > Eric
              > >
              > > On Thu, Sep 24, 2009 at 3:25 PM, Andrew <andrew.bialecki@...>
              > > wrote:
              > >
              > > You're spot on and your reasoning is basically the exact same line
              > > of reasoning I've had. The one requirement we have is that if I
              > > select "unfinishedChair" but then decline to set the stain color, I
              > > want the UI to act as if I hadn't selected "unfinishedChair" at all.
              > >
              > > I like the reset idea so I'll try to implement that. A related
              > > question is when you have an attribute that can have an
              > > "uninitialized" state, what's a good way to handle that. TO do this,
              > > I have attributes that can either be null or an integer, say. I
              > > basically check to see if the value is not null to see if it's
              > > initialized and then use it.
              > >
              > > This is a little inefficient since my validation method must now
              > > allow null and there isn't a great API for this, but it could be
              > > formalized like:
              > >
              > > this.clear("myAttribute"); // Different from reset, which might set
              > > it to some default value.
              > >
              > > this.isSet("myAttribute"); // return true or false based on whether
              > > it's been initialized.
              > >
              > > Anyways, maybe there's a way to do this already or you have some
              > > better ideas.
              > >
              > > Thanks for all the input.
              > >
              > > - Andrew
              > >
              > >
              > >
              > > --- In yui3@yahoogroups.com, Satyen Desai <sdesai@...> wrote:
              > > >
              > > > Hey Andrew,
              > > > Is the value state of the unselected objects in your array
              > reflected
              > > > anywhere?
              > > >
              > > > From your description (or rather my interpretation of "they must
              > > then
              > > > give a value to that object") it seems like the array is a
              > source of
              > > > default/generic objects/options, which users set a value for when
              > > > selected.
              > > >
              > > > My interpretation:
              > > >
              > > > var furniture = [ unfinishedDesk, unfinishedChair,
              > > unfinishedTable ];
              > > > // your generic valued objects
              > > > selected = furniture[1];
              > > > selected.stain = "black"; // your value
              > > >
              > > > And your code as currently implemented, ends up storing black as
              > the
              > > > value of the unfinishedChair, after the first time it's been
              > > selected
              > > > and a value has been set, so that the next time an unfinishedChair
              > > is
              > > > selected and it's stain is set to "black", it doesn't fire a
              > change
              > > > event?
              > > >
              > > > If the above description is accurate (it may not be, again, my
              > > > interpretation), then it seems like value should be reset when
              > > > something is unselected [ or a new default valued object should be
              > > > created on selection, but I can see there would be performance
              > > reasons
              > > > to avoid this, if it can just be reset ] to correctly reflect the
              > > > application.
              > > >
              > > > Even otherwise, it seems like the selectedIndex change is what is
              > > > initiating the update in the UI and should drive subsequent UI
              > > updates
              > > > for the item (so it's not really an update to it's value, but an
              > > > initial rendering of the selected item)?
              > > >
              > > > This is not to say that attribute shouldn't have a way to
              > configure
              > > > the "same value" notification (it's pretty trivial to add). Just
              > > > trying to figure out the use case behind it so it's not added as a
              > > > knee jerk reaction.
              > > >
              > > > As mentioned, if you want to file an enhancement request for it,
              > if
              > > > possible with a URL/example, we can keep track of the conversation
              > > in
              > > > the request.
              > > >
              > > > Regards,
              > > > Satyen
              > > >
              > > > On Sep 23, 2009, at 5:36 PM, Andrew wrote:
              > > >
              > > > > I'm building a widget that has an array of objects from which a
              > > user
              > > > > can choose. When a user selects an object, they must then give a
              > > > > value to that object. If the user completes both of these steps
              > > > > (essentially a two-phase commit), that object is marked as the
              > > > > selected object and I want to fire an event to update some
              > text on
              > > > > the page reflecting the user's choice.
              > > > >
              > > > > My implementation of this is to attach a listener to the
              > > > > "valueChange" event of each of the objects. The subscribed
              > method
              > > > > then updates an attribute that is the index of the object that
              > was
              > > > > just updated and then calls a method to update the text
              > describing
              > > > > which object was selected and what value was passed to it.
              > > > >
              > > > > This doesn't work if a user selects an object and inputs the
              > value
              > > > > that is already stored within that object.
              > > > >
              > > > > One idea would be to "reset" the value of that object and then
              > > allow
              > > > > the user to update it. I'd have to ignore the reset value in the
              > > > > subscribed method, which might not be too bad.
              > > > >
              > > > > Any ideas?
              > > > >
              > > > > --- In yui3@yahoogroups.com, Satyen Desai <sdesai@> wrote:
              > > > > >
              > > > > > Hi,
              > > > > > It would need to be something added to the attribute layer, as
              > > an
              > > > > > attribute configuration property.
              > > > > >
              > > > > > If you file an enhancement request, I can look into it for the
              > > next
              > > > > > 3.x release, however I'm not certain it's the right approach.
              > > If you
              > > > > > can file some details about your code/application in the
              > > enhancement
              > > > > > request, I can look into whether or not there's a better way
              > > to go
              > > > > > about what you're trying to achieve.
              > > > > >
              > > > > > - Satyen
              > > > > >
              > > > > > On Sep 22, 2009, at 8:47 PM, Andrew wrote:
              > > > > >
              > > > > > > I need to have the attribute "after" event fire regardless
              > of
              > > > > > > whether that attribute has been updated. I need a hook that
              > > says
              > > > > the
              > > > > > > user tried to change that value and it succeeded -- either
              > > because
              > > > > > > the value changed or because they input the same, valid
              > value.
              > > > > > >
              > > > > > > Any thoughts on a way to do this or is this going to be
              > > integrated
              > > > > > > into the Event utility at some point?
              > > > > > >
              > > > > > >
              > > > > > >
              > > > > >
              > > > >
              > > > >
              > > > >
              > > >
              > >
              > >
              > >
              > >
              > >
              >
              >
              >
              > ------------------------------------
              >
              > Yahoo! Groups Links
              >
              >
              >
              >
              >
              >
            Your message has been successfully submitted and would be delivered to recipients shortly.