0

Unhappy about onRefreshView

I don't like onRefreshView.  It seems to me that a change of names and a little functionality would help to develop better coding habits.   I would like to suggest that instead of this:
bind: function (node) {  this.node = node;  // attach events to nodes  // instantiate complex Widgets},onRefreshView: function (node) {  // destroy Widgets  // detach events  this.bind(node);}
I think it would be better to have this: 
bind: function (node) {  this.node = node;  // attach events to nodes  // instantiate complex Widgets},unBind: function (node) {  // destroy Widgets  // detach events}
Two changes:  onRefreshView turns into unBind, which associates its functionality much closer to that of bind.  Second, it calls bind.  This would promote a more healthier coding process:  whatever you do in bind, you should undo in unBind.

An even better, though more radical change would be to have this part:  <div id="{{mojit_view_id}}"></div> added automatically by Mojito and never removed.  After all, if that part must always be there, why doesn't Mojito do it for me, that is the purpose of automation isn't it?  But the really important part is that with that part, lets call it the envelope, always there, you can attach events, via delegation, to the envelope and avoid attaching them and detaching them every time.  The lifecycle of the binder would then be: 
bind: function (envelopeNode) {   this.node = envelopeNode;   // attach events to the envelope with envelopeNode.delegate()},afterContentInserted: function () {   // instantiate complex Widgets},beforeContentRemoved: function () {  // destroy Widgets}
The names of the last two methods are awful, but I just meant to describe them.  In this case, there is no unBind method since the envelope is never removed.  The last two methods don't receive any node reference since they already have this.node.   And, BTW, talking about automation, can't Mojito store the reference to the envelope node into this.node after creating the instance?  It seems silly to have to do so much bean counting.  Then, none of the methods would need to have it as an argument and, since it is never destroyed, it would be safe to keep it in the binder instance.  If the parent Mojito was to be redrawn, this.node would still contain the reference to the envelope, possibly removed from the document body, which can be easily re-attached wherever it should go.

by
2 Replies
  • (sorry about the code blocks, I don't know why it sharnk it to one line.  Let me try again:
    Unhappy about onRefreshView.  

    I don't like onRefreshView.  It seems to me that a change of names and a little functionality would help to develop better coding habits.   I would like to suggest that instead of this:

     
    bind: function (node) {  this.node = node;  // attach events to nodes  // instantiate complex Widgets},onRefreshView: function (node) {  // destroy Widgets  // detach events  this.bind(node);}


    I think it would be better to have this:

     
    bind: function (node) {  this.node = node;  // attach events to nodes  // instantiate complex Widgets},unBind: function (node) {  // destroy Widgets  // detach events}


    Two changes:  onRefreshView turns into unBind, which associates its functionality much closer to that of bind.  Second, it calls bind.  This would promote a more healthier coding process:  whatever you do in bind, you should undo in unBind.

    An even better, though more radical change would be to have this part:  <div id="{{mojit_view_id}}"></div> added automatically by Mojito and never removed.  After all, if that part must always be there, why doesn't Mojito do it for me, that is the purpose of automation isn't it?  But the really important part is that with that part, lets call it the envelope, always there, you can attach events, via delegation, to the envelope and avoid attaching them and detaching them every time.  The lifecycle of the binder would then be:

     
    bind: function (envelopeNode) {   this.node = envelopeNode;   // attach events to the envelope with envelopeNode.delegate()},afterContentInserted: function () {   // instantiate complex Widgets},beforeContentRemoved: function () {  // destroy Widgets}



    The names of the last two methods are awful, but I just meant to describe them.  In this case, there is no unBind method since the envelope is never removed.  The last two methods don't receive any node reference since they already have this.node.   And, BTW, talking about automation, can't Mojito store the reference to the envelope node into this.node after creating the instance?  It seems silly to have to do so much bean counting.  Then, none of the methods would need to have it as an argument and, since it is never destroyed, it would be safe to keep it in the binder instance.  If the parent Mojito was to be redrawn, this.node would still contain the reference to the envelope, possibly removed from the document body, which can be easily re-attached wherever it should go.

    It would be even better if events could be attached via an event configuration object such as that found in Y.View, (see: http://yuilibrary.com/yui/docs/view/#handling-dom-events) or my own Gallery MakeNode (see: http://satyam.github.com/apiDocsGallery/classes/MakeNode.html#property__EVENTS , the property is protected, you may have to show protected properties to see it)



    0
  • One work around is for onRefreshView is in your binder to include a function like the one below. This will make sure your previous node instance was properly unbound as the next one is generated:
            onRefreshView: function (node, element) {
                Y.log('onRefreshView', 'debug');
                this.unbind(node);
                this.bind(node, element);
            },
    If that doesn't format correctly, see: http://pastebin.com/ffbuKraY

    Of course, it would be better if Mojito did this automatically :)
    0

Recent Posts

in Yahoo! Mojito