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

17597Re: [ydn-javascript] Editable datatable..

Expand Messages
  • Satyam
    Sep 3, 2007
    • 0 Attachment
      It is better that you don't change the original distribution files, I did that once and when the update came, it was tough to check the changes. 
       
      What I now have is a separate file with all my patches that I load after the file to be patched so that its definitions overwrite the original ones.  That makes it easy when a new version comes to pick the methods that were patched and check if they are still necesary.
       
      I actually have my own customized version of DataTable (using YAHOO.lang.extend) where I have several of the basic settings already taken care of and I can redefine the methods in that inherited DataTable.  If there were to be any licensing issues with modifying the original library, this would take care of them. 
       
      Anyway, redefining the original or your inherited version makes no difference when update time comes, you'll have to check those patches anyway, so it is good to have them all in one place. 
       
      Satyam
       
      ----- Original Message -----
      Sent: Monday, September 03, 2007 10:05 AM
      Subject: RE: [ydn-javascript] Editable datatable..

      Thanks a lot Satyam….

       

      I have a very basic question here….

      This solution involves changing the yui code.

       

      Is this allowed, I mean are we supposed to give this as a patch and then make use of the new release?

       

      Thanks

      Prasanna

       

       

       


      From: ydn-javascript@yahoogroups.com [mailto:ydn-javascript@yahoogroups.com] On Behalf Of Satyam
      Sent: Friday, August 31, 2007 10:38 PM
      To: ydn-javascript@yahoogroups.com
      Subject: Re: [ydn-javascript] Editable datatable..

       

      That is, indeed, a problem.  The best alternative I found is to redefine the saveCellEditor method. 

       

      This is how the original looks like, with the original comments stripped and my own added:

       

      YAHOO.widget. DataTable. prototype. saveCellEditor = function() {

          if(this._oCellEdito r.isActive) {
              var newData = this._oCellEditor. value;
              var oldData = this._oCellEditor. record.getData( this._oCellEdito r.column. key);

       

              if(this._oCellEdito r.validator) {
                  this._oCellEditor. value = this._oCellEditor. validator. call(this, newData, oldData);
                  if(this._oCellEdito r.value === null ) {

              //  -----  This is what you do on error
                      this.resetCellEdito r();
                      this.fireEvent( "editorRevertEve nt",
                              {editor:this. _oCellEditor, oldData:oldData, newData:newData} );
              // ----- up to here
                      return;

                  }
              }

      // ----- This is what you do on success

              this._oRecordSet. updateKey( this._oCellEdito r.record, this._oCellEditor. column.key, this._oCellEditor. value);

              this.formatCell( this._oCellEdito r.cell);

              this.resetCellEdito r();

              this.fireEvent( "editorSaveEvent ",
                      {editor:this. _oCellEditor, oldData:oldData, newData:newData} );

      // ---- up to here.

       


          }
          else {
          }
      };

       

      So, what I did is to have the part that handles a failed validation made into an inner function, since it will be called in several places.  Where the failure secion is I put a call to this inner function.

       

      I cut the 'success' part and save it elsewhere since we are going to use id.  In its place, I put the call to asyncRequest and end the function.  In the success callback to asyncRequest I put the success section I saved. 

       

      On the 'failure' callback to asyncRequest I call the failure function, that's why I put it in an inner function.  Actually, even on a sucess return from the server, you have to check if there was any error from the database since the failure callback only handles communication errors, if there are any logic errors, you have to handle those.  In case of error, I call the failure function.  My own is somewhat different, bits and pieces that I added or deleted from the original so I am making this one right here on the message, cutting and pasting and writing here.  It probably doesn't work as is, but I hope it will give you the general idea.  I tried to preserve as much of the original function as possible, even the comments I put in the one above.

       

      YAHOO.widget. DataTable. prototype. saveCellEditor = function() {

         // ++++ this is the inner function to handle the several possible failure conditions

          var onFailure = function (msg) {

              alert(msg);
              //  -----  This is what you do on error
                 this.resetCellEdito r();
                 this.fireEvent( "editorRevertEve nt",
                              {editor:this. _oCellEditor, oldData:oldData, newData:newData} );

              // ----- up to here
        };

      // +++ this comes from the original exdcept for the part I cut to place in the function above.

          if(this._oCellEdito r.isActive) {
              var newData = this._oCellEditor. value;
              var oldData = this._oCellEditor. record.getData( this._oCellEdito r.column. key);

       

              if(this._oCellEdito r.validator) {
                  this._oCellEditor. value = this._oCellEditor. validator. call(this, newData, oldData);
                  if(this._oCellEdito r.value === null ) {

                      onFailure('validati on');

                      return;

                  }
              }

       

      // ++++++ from here on I added new, except for the 'success' case pasted in.

          YAHOO.util.Connecti on.asyncRequest( 'GET','yourURL with newData,fieldname and primary as arguments ',

              {

                  success: function (o) {

                      if (no error on reply from server) {

                      // ----- This is what you do on success

                          this._oRecordSet. updateKey( this._oCellEdito r.record, this._oCellEditor. column.key, this._oCellEditor. value);

                          this.formatCell( this._oCellEdito r.cell);

                          this.resetCellEdito r();

                          this.fireEvent( "editorSaveEvent ",
                                  {editor:this. _oCellEditor, oldData:oldData, newData:newData} );

                      // ---- up to here.

                  } else {

                      onFailure(o. responseText) ;

              },

              failure: function(o) {

                  onFailure(o. statusText) ;

              },

              scope: this

          );

       


          }
          else {
          }
      };


      In my version I don't close the inline editor on error.  The user has either to fix the error (if it is a validation error, client or server side, he can probably fix it) or cancel out of it. 

       

      I don't fire the editorRevertEvent and editorSaveEvent since I don't listen to them.  I particularly feel the editorSaveEvent fires too late. That is where you would normally hook for the AJAX call to the server, but the DataTable is already changed and the editor closed as if everything was ok and if there is an error, the user might have already navigated away from the page trusting everything was Ok.  Anyhow, moving that event up doesn't help much since, due to the A in AJAX , you cannot wait in the event for an answer, so the whole thing doesn't quite work. 

       

      I also have a Dialog which I use instead of both alert() and confirm(), just for the look and feel. 

       

      I also use a POST request instead of GET to allow for large field contents.

       

       

      Finally, if you are using JSON, I found that using an 'envelope' in the reply makes things more flexible.  My 'envelope' looks like this:

       

      {
          replyCode:200, replyText:"Ok" ,
          data:[{ ... } , ... ]
      }

       

      You could do more or less the same thing with XML.  Whichever the message format, make sure to the reply codes are easy to reach.

       

      The data element is optional and may contain whatever was requested, but sometimes you just want to know whether it succ

      (Message over 64 KB, truncated)

    • Show all 21 messages in this topic