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

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

Expand Messages
  • Eric Ferraiuolo
    Sep 25, 2009
    • 0 Attachment
      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.


      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 ) {




      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?


      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?
      > > > >
      > > > >
      > > > >
      > > >
      > >
      > >
      > >

    • Show all 10 messages in this topic