Rails spinoffs - Nov 2007 - Bizarre defaults for InPlaceEditor

I''ve been upgrading a Rails 1.2.5 webapp to use the newly release
prototype
1.6 and script.aculo.us 1.8. One thing I ran into was a bizarre change to
the defaults for Ajax.InPlaceEditor. First off, I can sort of understand
how it might make sense to expect an HTML (rather than JS) response from
the Ajax request, but it would seem to make more sense to autodetect based
on the returned MIME type if no setting for the htmlResponse option is
given.

Second, and a much bigger deal, is that the Ajax request is being defaulted
to a GET instead of a POST. Given that this is semantically an edit
(it''s
even in the name!), it really should be a POST (and the web server should
not respond to a GET request by changing state). Why should it default to
GET? What''s the justification behind that change?

--Greg


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Hey Gregory,

Gregory Seidman a écrit :
> I''ve been upgrading a Rails 1.2.5 webapp to use the newly release
prototype
> 1.6 and script.aculo.us 1.8. One thing I ran into was a bizarre change to
> the defaults for Ajax.InPlaceEditor. First off, I can sort of understand
> how it might make sense to expect an HTML (rather than JS) response from
> the Ajax request, but it would seem to make more sense to autodetect based
> on the returned MIME type if no setting for the htmlResponse option is
> given.
IIRC, the current behavior is backawards-compatible with the old IPE 
code (however, it''s not as spiffy as the new Ajax.Response thing, 
granted;  the IPE code was developed around Prototype 1.5.1 and doesn''t
always seize the whole power of 1.6.0).
> Second, and a much bigger deal, is that the Ajax request is being defaulted
> to a GET instead of a POST. Given that this is semantically an edit
(it''s
> even in the name!), it really should be a POST (and the web server should
> not respond to a GET request by changing state). Why should it default to
> GET? What''s the justification behind that change?
INDEED!  Copy/paste error from another part, I guess.  Definitely 
incorrect as per W3C rec''s and plain common sense.

I''m swamped right now, can you please file a clean ticket about this? 
The patch is a one-liner, but some specific tests would be nice to 
warrant inclusion in the trunk.  I''ll try and find some time soon for 
this, unless Thomas jumps in and whacks the bug down.

Thanks for the heads up,

-- 
Christophe Porteneuve aka TDD
tdd-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.org

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

The default behavior of the request in the InPlaceEditor seems to be
that it sends the entire serialized params object, which is an
extended object, as the parameters of the request.  So all of the
methods like all(), any(), and so on are serialized and sent as
parameters.  When I view the headers of the request I can see all of
them.

Is that the intended behavior?  It seems wrong, since my server-side
code obviously has no use for JavaScript methods.  If my server-side
code happens to be looking for a parameter named include or size, it''s
not going to be happy.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Since we are discussing the IPE''s defaults, there''s something
that bugs me,
but since I haven''t looked much into it, I could have missed something:
The
ajaxOptions are shared between loadText requests and when saving the
serialized form.

Now, if I want to save the form with a PUT request (using rails restfulness
bliss :)), since the default when saving is using POST, I have to pass it in
the ajaxOptions. But that will overwrite the GET method of the loadText
request :-\

Am I missing something? I will need the IPE soon, so I guess I''ll
either
find out if I read it all wrong or I''ll come up with a patch :)

-Nicolas

On Nov 16, 2007 3:55 PM, mcrawford-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
<mcrawford-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> The default behavior of the request in the InPlaceEditor seems to be
> that it sends the entire serialized params object, which is an
> extended object, as the parameters of the request.  So all of the
> methods like all(), any(), and so on are serialized and sent as
> parameters.  When I view the headers of the request I can see all of
> them.
>
> Is that the intended behavior?  It seems wrong, since my server-side
> code obviously has no use for JavaScript methods.  If my server-side
> code happens to be looking for a parameter named include or size,
it''s
> not going to be happy.
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Never mind, my parameters object was an Array (extended by default),
not an Object (not extended).  Apologies.

On Nov 16, 9:55 am,
"mcrawf...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
<mcrawf...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> The default behavior of the request in theInPlaceEditorseems to be
> that it sends the entire serialized params object, which is an
> extended object, as the parameters of the request.  So all of the
> methods like all(), any(), and so on are serialized and sent as
> parameters.  When I view the headers of the request I can see all of
> them.
>
> Is that the intended behavior?  It seems wrong, since my server-side
> code obviously has no use for JavaScript methods.  If my server-side
> code happens to be looking for a parameter named include or size,
it''s
> not going to be happy.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Okay, now that my credibility is shot, I have another question about
the in-place editor code.  There is this function in the
InPlaceEditor:

triggerCallback: function(cbName, arg) {
    if (''function'' == typeof this.options[cbName]) {
      this.options[cbName](this, arg);
    }
  }

then the default onFailure method, which gets called from
triggerCallback, is:
onFailure: function(transport, ipe) {
      alert(''Error communication with the server: '' +
transport.responseText.stripTags());
    }

Aren''t the arguments backwards?  When I submit a request that fails, I
never see an alert because the "transport" variable in the onFailure
method is really the InPlaceEditor.

I tried to submit it as a bug from the scriptaculous website but do
not have the proper privileges.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

On Nov 16, 2007 10:16 PM, mcrawford-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
<mcrawford-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> Okay, now that my credibility is shot, I have another question about
> the in-place editor code.  There is this function in the
> InPlaceEditor:
>
> triggerCallback: function(cbName, arg) {
>    if (''function'' == typeof this.options[cbName]) {
>      this.options[cbName](this, arg);
>    }
>  }
>
> then the default onFailure method, which gets called from
> triggerCallback, is:
> onFailure: function(transport, ipe) {
>      alert(''Error communication with the server: '' +
> transport.responseText.stripTags());
>    }
>
> Aren''t the arguments backwards?  When I submit a request that
fails, I
> never see an alert because the "transport" variable in the
onFailure
> method is really the InPlaceEditor.
>
> I tried to submit it as a bug from the scriptaculous website but do
> not have the proper privileges.

To submit bugs to script.aculo.us, or Prototype, you have to do it from
http://dev.rubyonrails.org/
You can register an account on the trac there and then post tickets
normally.

Read http://prototypejs.org/contribute for more details :)

Best,
-Nicolas


>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---