jEditable question

[Barry Nauta-3]

Hi all,

I have recently discovered jquery and jeditable.

When using jeditable, I discovered two things:

- Using firefox 1.0.8 jeditable does not return.
I can edit my text and the changes are saved in the database. However, after
hitting the enter butting (and thus submitting the changes), the busy icon is
show forever, it does not return. This is also true for the demos on
jeditable the site. Does ayone know how to fix this?

- Instead of a string, I would rather have some json structure returned from
my backend with an optional error message. Anyone already done this?

Barry

_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/

[Miel]

Barry,

I've added some code to show an error message.
Quite ugly solution though:
I catch all returned text, and look for the following string '[error]',
if it's found, I revert the form field text and alert the error.

The trick is to format the error texts well (ie containing the search
string). A more elegant solution would be something parameterized or
something like JSON, but this worked for me:

            /* show the saving indicator */
            $(self).html(options.indicator);
            $(self).load(settings.url, p, function(str) {
                self.editing = false;
                    var curTxt = $(self).html();
                    /* check for error and revert if found.
                if(curTxt.indexOf('[ERROR]') != -1 ) {
                self.innerHTML = self.revert;
                alert(curTxt);
                }
            });

Cheers,
Miel

-----Original Message-----
From: discuss-bounces@... [mailto:discuss-bounces@...] On
Behalf Of Barry Nauta
Sent: dinsdag 24 oktober 2006 11:06
To: discuss@...
Subject: [jQuery] jEditable question

Hi all,

I have recently discovered jquery and jeditable.

When using jeditable, I discovered two things:

- Using firefox 1.0.8 jeditable does not return.
I can edit my text and the changes are saved in the database. However,
after
hitting the enter butting (and thus submitting the changes), the busy
icon is
show forever, it does not return. This is also true for the demos on
jeditable the site. Does ayone know how to fix this?

- Instead of a string, I would rather have some json structure returned
from
my backend with an optional error message. Anyone already done this?

Barry

_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/

_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/

[Robert Wagner-3]

2006/10/24, Miel Soeterbroek <Miel@...>:

> Barry,
>
> I've added some code to show an error message.
> Quite ugly solution though:
> I catch all returned text, and look for the following string '[error]',
> if it's found, I revert the form field text and alert the error.
>
> The trick is to format the error texts well (ie containing the search
> string). A more elegant solution would be something parameterized or
> something like JSON, but this worked for me:
>
>             /* show the saving indicator */
>             $(self).html(options.indicator);
>             $(self).load(settings.url, p, function(str) {
>                 self.editing = false;
>                     var curTxt = $(self).html();
>                     /* check for error and revert if found.
>                 if(curTxt.indexOf('[ERROR]') != -1 ) {
>                         self.innerHTML = self.revert;
>                         alert(curTxt);
>                 }
>             });
>
> Cheers,
> Miel
>

how about that:
if an error occours, let the server send a 500 header and the error
message as a content.

header("HTTP/1.1 500 Internal Server Error");
print("this cannot be done.");


to get this working you have to replace $(self).load(..) call with
$.ajax() call:

$.ajax({
               url:settings.url,
               type: "POST",
               data: $.param(p),
               complete: function(str){self.editing = false;},
               success: function(r){self.innerHTML=r;},
               error: function(r){alert("ERROR: "+ r.responseText);}
            });

error: alerts the message or does whatever you want. i contacted the
author who wants to think about that.
another solution could be to use ajaxError (i just stumbled across).
but that leads me to another question: is it possible to populate the
error response there?
-robert

_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/

[Mika Tuupola]

On Oct 24, 2006, at 12:06, Barry Nauta wrote:

> - Using firefox 1.0.8 jeditable does not return.
> I can edit my text and the changes are saved in the database.  
> However, after
> hitting the enter butting (and thus submitting the changes), the  
> busy icon is
> show forever, it does not return. This is also true for the demos on
> jeditable the site. Does ayone know how to fix this?

1.0.8 is already a bit old. Will downgrade from 1.5.x series and try  
it out.

> - Instead of a string, I would rather have some json structure  
> returned from
> my backend with an optional error message. Anyone already done this?

As you said, returning JSON object is backend job. Currently  
jEditable itself does not have methods for handling JSON responses. I  
have plans to add call user defined callback methods though. This  
would do the job.

--
Mika Tuupola
http://www.appelsiini.net/~tuupola/



_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/

[Barry Nauta-3]

> 1.0.8 is already a bit old. Will downgrade from 1.5.x series and try
> it out.

It is indeed ;-) Nevertheless it would be great if this can be fixed.

By the way, you do not mention that it works with IE on your website. It does
work on XP SP2 with version 6.0.2900........and some more version digits

> As you said, returning JSON object is backend job. Currently
> jEditable itself does not have methods for handling JSON responses. I
> have plans to add call user defined callback methods though. This
> would do the job.

That would be great!

Barry

_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/

[Mika Tuupola]

On Oct 24, 2006, at 14:43, Robert Wagner wrote:

> how about that:
> if an error occours, let the server send a 500 header and the error
> message as a content.
>
> header("HTTP/1.1 500 Internal Server Error");
> print("this cannot be done.");

Agreed. I find error headers to be more elegant and universal  
solution than sending "ERROR" string in a reply.  Will implement this  
soon(ish).

--
Mika Tuupola
http://www.appelsiini.net/~tuupola/



_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/

[Barry Nauta-3]

On Tuesday 24 October 2006 15:58, Mika Tuupola wrote:

> On Oct 24, 2006, at 14:43, Robert Wagner wrote:
> > how about that:
> > if an error occours, let the server send a 500 header and the error
> > message as a content.
> >
> > header("HTTP/1.1 500 Internal Server Error");
> > print("this cannot be done.");
>
> Agreed. I find error headers to be more elegant and universal
> solution than sending "ERROR" string in a reply.  Will implement this
> soon(ish).

Just my $0.02: I find this odd. Imagine that you want some processing to be
done based on the input (i.e. server side email address checking) (We all
agree that any validation also needs to be performed at the serverside,
right?).

If the provided email address appears to be incorrect, I would never think
about throwing a 500 server error.... A small JSON object with an
error/exception message would seem much more logical to me...

_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/

[Robert Wagner-3]

2006/10/24, Barry Nauta <barry.nauta@...>:

> On Tuesday 24 October 2006 15:58, Mika Tuupola wrote:
> > On Oct 24, 2006, at 14:43, Robert Wagner wrote:
> > > how about that:
> > > if an error occours, let the server send a 500 header and the error
> > > message as a content.
> > >
> > > header("HTTP/1.1 500 Internal Server Error");
> > > print("this cannot be done.");
> >
> > Agreed. I find error headers to be more elegant and universal
> > solution than sending "ERROR" string in a reply.  Will implement this
> > soon(ish).
>
> Just my $0.02: I find this odd. Imagine that you want some processing to be
> done based on the input (i.e. server side email address checking) (We all
> agree that any validation also needs to be performed at the serverside,
> right?).
>

that was my attempt too at first. error checking = application logic =
write my own structures etc.
but then think about error handling as a very basic thing that is
already implementet in webserver, ajax functions etc. why not using
this infrastructure? it's straightforward, ready to use...
-robert

_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/

[Barry Nauta-3]

> that was my attempt too at first. error checking = application logic =
> write my own structures etc.
> but then think about error handling as a very basic thing that is
> already implementet in webserver, ajax functions etc. why not using
> this infrastructure? it's straightforward, ready to use...

I certainly do not think about error handling as a very basic thing, I think
it is heavily underestimated.

The problem for me is that treating simple business logic as server errors
might be straightforward, but imHo, it is not clean. Using JSON structures is
still using the full capabilities of AJAX, I just wouldn't use webservers way
of telling that it has encountered un unrecoverable error while all there is
is a small check that fails.

This is a non-portable, non-reusable solution (talking about the email
checking funtionality, used as example), but I guess for smaller things it
will do.

_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/

[Mika Tuupola]

On Oct 24, 2006, at 17:54, Robert Wagner wrote:

>> Just my $0.02: I find this odd. Imagine that you want some  
>> processing to be
>> done based on the input (i.e. server side email address checking)  
>> (We all
> that was my attempt too at first. error checking = application logic =
> write my own structures etc.

I always try to write reusable code and not force users to one  
specific implementation (for example hardcoding
  effects into jEditable). I also like to keep things simple.  
Checking for HTTP response codes is universal approach. I do however  
see cases when it is not the best solution and another approach such  
as JSON object is more suitable.

I see two possible solutions here.

1) Add an configuration option what kind of response jEditable  
expects. This requires less coding from end user. Bad thing is it  
adds bloat to jEditable since all different response types need their  
own handlers inside plugin code.

2) Add user defined callback (and/or callbefore) handlers. Requires  
more coding from the end user but everyone can write their own  
implementation for their own needs. Those who don't need special  
implementations can still use the easy defaults.

Any other suggestions?

--
Mika Tuupola
http://www.appelsiini.net/~tuupola/



_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/

[Miel]

Mika

In order to keep the code as reusable as possible, i'd just go for the custom callback method, and leave the way of handling the response to the user. That way, i (and perhaps others) will be able to implement quick and dirty error handling, and others can go with JSON or anything else.

That way, the jEditable code stays as clean as possible, without too much extra's.
Leave writing custom handlers to the ones using them ;)

Cheers,
Miel

>> Just my $0.02: I find this odd. Imagine that you want some  
>> processing to be
>> done based on the input (i.e. server side email address checking)  
>> (We all
> that was my attempt too at first. error checking = application logic =
> write my own structures etc.

I always try to write reusable code and not force users to one  
specific implementation (for example hardcoding
  effects into jEditable). I also like to keep things simple.  
Checking for HTTP response codes is universal approach. I do however  
see cases when it is not the best solution and another approach such  
as JSON object is more suitable.

I see two possible solutions here.

1) Add an configuration option what kind of response jEditable  
expects. This requires less coding from end user. Bad thing is it  
adds bloat to jEditable since all different response types need their  
own handlers inside plugin code.

2) Add user defined callback (and/or callbefore) handlers. Requires  
more coding from the end user but everyone can write their own  
implementation for their own needs. Those who don't need special  
implementations can still use the easy defaults.

Any other suggestions?

--
Mika Tuupola
http://www.appelsiini.net/~tuupola/



_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/



_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/

[Robert Wagner-3]

2006/10/24, Mika Tuupola <tuupola@...>:

>
> On Oct 24, 2006, at 17:54, Robert Wagner wrote:
>
> >> Just my $0.02: I find this odd. Imagine that you want some
> >> processing to be
> >> done based on the input (i.e. server side email address checking)
> >> (We all
> > that was my attempt too at first. error checking = application logic =
> > write my own structures etc.
>
> I always try to write reusable code and not force users to one
> specific implementation (for example hardcoding
>   effects into jEditable). I also like to keep things simple.
> Checking for HTTP response codes is universal approach. I do however
> see cases when it is not the best solution and another approach such
> as JSON object is more suitable.
>
> I see two possible solutions here.
>
> 1) Add an configuration option what kind of response jEditable
> expects. This requires less coding from end user. Bad thing is it
> adds bloat to jEditable since all different response types need their
> own handlers inside plugin code.
>
> 2) Add user defined callback (and/or callbefore) handlers. Requires
> more coding from the end user but everyone can write their own
> implementation for their own needs. Those who don't need special
> implementations can still use the easy defaults.
>

i think the 2nd one is best. every one with special needs should be
able to implement it by overriding the default ajax options. that
said, these options must be handed over...

like here :)
http://wiki.script.aculo.us/scriptaculous/show/Ajax.InPlaceEditor

where options are merged with ajaxOptions and important ones
(onComplete ..) are even direct setable.
-robert

> Any other suggestions?
>
> --
> Mika Tuupola
> http://www.appelsiini.net/~tuupola/
>
>
>
> _______________________________________________
> jQuery mailing list
> discuss@...
> http://jquery.com/discuss/
>

_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/

[Barry Nauta-3]

> 1) Add an configuration option what kind of response jEditable
expects.
> This requires less coding from end user. Bad thing is it adds bloat to

> jEditable since all different response types need their own handlers
> inside plugin code.

Yep, this doesn't sound right to me... Sometimes you just have to make
choices for the user, this sounds like a compromise which is in noones
advantadge

> 2) Add user defined callback (and/or callbefore) handlers. Requires
more
> coding from the end user but everyone can write their own
implementation
> for their own needs. Those who don't need special implementations can
> still use the easy defaults.

This would be great. I personally think that the little bit of extra
coding largely makes up for the flexibility and reusability that this
approach offers.

Barry

_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/

[saf_]

I am submitting to a function instead of url. This function makes an ajax request. If server cannot save the edited data or some other error. It will return "ErRoR" in the string. I check if there is "ErRoR" text in the return string I am displaying an message box.

Now i want the edit form to be visible with textbox containing the value entered by the user. Now if the user hits cancel or hits escape it should revert back to the original value.

Below is the my code.


$('.edit').editable(function(value, settings){
               
        $.ajax({
                type: 'POST',
                url: 'save.html',
                async: false,
                success: function(data){
                        if (/ErRoR:/.test(data))
                        {
                                data = data.replace(/ErRoR:/g, '');
                                alert(data + ' Could not save data.');
                                //Back to edit
                        }
                }
        });
        return(value);
        }, {
         indicator : 'Saving...',
         width     : '170px',
         cssclass  : 'inlineEdit',
         cancel    : 'Cancel',
         submit    : '<br><input type="button" value="Save">',
 });