Rails spinoffs - Jan 2008 - InPlaceEditor question

Context: I have an inPlaceEditor on an element. When that element is
edited, there are several other elements on that same page that need
to be updated (each a different appearance of the same underlying
domain object).

Can InPlaceEditor be configured (or modified) so that upon an edit, it
accepts from the server a replacement for a different DOM sub-tree?
How do I do this?

Thanks.

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

Have you looked into extending the existing behavior of the
InPlaceEditor? If you want to perform some extra actions when going
into edit mode, you can wrap the enterEditMode method (or another one,
if it is more fitting) such that you can either do something before or
after enterEditMode is called. Nicolas helped with this very thing
just last week when I asked a similar question to yours.

Take for example the following code, which would reside in your
applicaiton.js file or somewhere else more fitting:

Ajax.InPlaceEditor.prototype.enterEditMode
Ajax.InPlaceEditor.prototype.enterEditMode.wrap( function(){
  var args = $A(arguments), proceed = args.shift();

  // Your custom code before #enterEditMode is called goes here
  proceed();
  // Your custom code after #enterEditMode is called goes here
});

Take a look at controls.js in Scriptaculous if you''d like to override
a different method or access any attributes (element IDs, form
objects, etc..).

-justin

--~--~---------~--~----~------------~-------~--~----~
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 Jan 13, 10:11 pm, "Justin Perkins"
<justinperk...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> Have you looked into extending the existing behavior of the
> InPlaceEditor?
I think the **** line below from controls.js is the one I want:

  handleFormSubmission: function(e) {
    ....
    new Ajax.Updater({ success: this.element }, this.url, options); //
****
    ....
   }

If I understand right, this means: upon success (from server), update
the node "this.element".  Which means the node containing the just-
edited text. I don''t think I can wrap anything around it. It is almost
like I need to InPlaceEditor to
- accept some new options  e.g. the id of the node for Ajax.Updater.
- then use those in the handleFormSubmission (and perhaps elsewhere
that I have not yet realized)

I''m somewhat new to Prototype/Scriptaculous (have been mostly using
them from the server side through Seaside/Smalltalk).

Thanks.

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

Maybe I misunderstood your original question. I thought you wanted to
do some extra stuff *before* the form submission occurs, as-if to
prepare the page for switching to edit mode.

If you want to do stuff after the form submission (or even just
before), you may want to checkout the various callback methods you can
supply to the InPlaceEditor, such as: onComplete, onFailure, and
callback. You can also set the option htmlResponse to false and have
the response from the form submission be raw JavaScript to be
executed.

new Ajax.InPlaceEditor( ''element-id'', { htmlResponse: false }
);

And a sample response would be:

$(''element-id'').update(''new value'')

This page may be helpful in learning more about the
Ajax.InPlaceEditor:
http://wiki.script.aculo.us/scriptaculous/show/Ajax.InPlaceEditor

-justin

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

{ htmlResponse: false } may be exactly what I need, I will try
that ...

Thank you very much, Justin !!


On Jan 13, 11:19 pm, "Justin Perkins"
<justinperk...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> Maybe I misunderstood your original question. I thought you wanted to
> do some extra stuff *before* the form submission occurs, as-if to
> prepare the page for switching to edit mode.
>
> If you want to do stuff after the form submission (or even just
> before), you may want to checkout the various callback methods you can
> supply to the InPlaceEditor, such as: onComplete, onFailure, and
> callback. You can also set the option htmlResponse to false and have
> the response from the form submission be raw JavaScript to be
> executed.
>
> new Ajax.InPlaceEditor( ''element-id'', { htmlResponse:
false } );
>
> And a sample response would be:
>
> $(''element-id'').update(''new value'')
>
> This page may be helpful in learning more about the
>
Ajax.InPlaceEditor:http://wiki.script.aculo.us/scriptaculous/show/Ajax.InPlaceEditor
>
> -justin
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

itsme213-PkbjNfxxIARBDgjK7y7TUQ@public.gmane.org wrote:
> Can InPlaceEditor be configured (or modified) so that upon an edit, it
> accepts from the server a replacement for a different DOM sub-tree?
> How do I do this?
I''ve been thinking about the InPlaceEditor and how specialized it
really
turns out to be.  Without hacking it, the only situation it works in is 
for one field to be edited and returned without sending any other values 
to the server and only updating the one value on return.  This actually 
seems like a rare case to me - most of the time if I''m editing a value
I
probably also need to send the id of the record, or on return I have to 
update other values to match the one that was edited.

It seems that maybe the functionality of the InPlaceEditor might be much 
more useful if it were broken up into pieces which could be used 
together in full compatibility with what''s there now, but also by 
themselves for more flexibility.  So much of the editor''s real bang for
the buck is the dynamic form it creates, after that a lot of the other 
pieces are pretty simple.  How about refactoring this code out into a 
dynamic form builder which can take an existing element, save the old 
contents, and fill it with some form variants (simple text field, pull 
down selector, <insert your idea here>.  This would be amazingly useful!

Steve

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

Hi Steve,

You can easily subclass it to fit your needs.

Best,

Tobie

On Jan 14, 5:54 pm, Steve Prior
<spr...-k+eNSbF9ABhWk0Htik3J/w@public.gmane.org>
wrote:
> itsme...-PkbjNfxxIARBDgjK7y7TUQ@public.gmane.org wrote:
> > Can InPlaceEditor be configured (or modified) so that upon an edit, it
> > accepts from the server a replacement for a different DOM sub-tree?
> > How do I do this?
>
> I''ve been thinking about the InPlaceEditor and how specialized it
really
> turns out to be.  Without hacking it, the only situation it works in is
> for one field to be edited and returned without sending any other values
> to the server and only updating the one value on return.  This actually
> seems like a rare case to me - most of the time if I''m editing a
value I
> probably also need to send the id of the record, or on return I have to
> update other values to match the one that was edited.
>
> It seems that maybe the functionality of the InPlaceEditor might be much
> more useful if it were broken up into pieces which could be used
> together in full compatibility with what''s there now, but also by
> themselves for more flexibility.  So much of the editor''s real
bang for
> the buck is the dynamic form it creates, after that a lot of the other
> pieces are pretty simple.  How about refactoring this code out into a
> dynamic form builder which can take an existing element, save the old
> contents, and fill it with some form variants (simple text field, pull
> down selector, <insert your idea here>.  This would be amazingly
useful!
>
> Steve
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

> ... - most of the time if I''m editing a value I
> probably also need to send the id of the record
The ID can be in the URL for the form submission, or if not there, you
can append it to the request with the callback() handler.
> or on return I have to
> update other values to match the one that was edited.
For that I would typically turn evalScripts on (htmlResponse:false)
and have my response contain one or more lines of raw JavaScript to
execute. Optionally you could use an onComplete handler as well.
> ... How about refactoring this code out into a
> dynamic form builder
The Ajax.InPlaceEditor and it''s related classes just made through a
major overhaul with the most recent version of Scriptaculous, it''s now
easier to customize and also less code, easier to understand.

Also, as Tobie said, subclassing (or wrapping/extending)
Ajax.InPlaceEditor is a pretty straight forward way to bend it to your
individual needs.

-justin


On Jan 14, 2008 10:54 AM, Steve Prior
<sprior-k+eNSbF9ABhWk0Htik3J/w@public.gmane.org>
wrote:
>
> itsme213-PkbjNfxxIARBDgjK7y7TUQ@public.gmane.org wrote:
> > Can InPlaceEditor be configured (or modified) so that upon an edit, it
> > accepts from the server a replacement for a different DOM sub-tree?
> > How do I do this?
>
> I''ve been thinking about the InPlaceEditor and how specialized it
really
> turns out to be.  Without hacking it, the only situation it works in is
> for one field to be edited and returned without sending any other values
> to the server and only updating the one value on return.  This actually
> seems like a rare case to me - most of the time if I''m editing a
value I
> probably also need to send the id of the record, or on return I have to
> update other values to match the one that was edited.
>
> It seems that maybe the functionality of the InPlaceEditor might be much
> more useful if it were broken up into pieces which could be used
> together in full compatibility with what''s there now, but also by
> themselves for more flexibility.  So much of the editor''s real
bang for
> the buck is the dynamic form it creates, after that a lot of the other
> pieces are pretty simple.  How about refactoring this code out into a
> dynamic form builder which can take an existing element, save the old
> contents, and fill it with some form variants (simple text field, pull
> down selector, <insert your idea here>.  This would be amazingly
useful!
>
> Steve
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Tobie Langel wrote:
> Hi Steve,
> 
> You can easily subclass it to fit your needs.
> 
> Best,
> 
> Tobie
Well sure, but it still seems that the dynamic form creation part would 
be a useful component to have around in its own right - possibly even 
more useful than the IPE itself.

Steve

--~--~---------~--~----~------------~-------~--~----~
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 Jan 13, 11:44 pm,
"itsme...-PkbjNfxxIARBDgjK7y7TUQ@public.gmane.org"
<itsme...-PkbjNfxxIARBDgjK7y7TUQ@public.gmane.org>
wrote:
> { htmlResponse: false } may be exactly what I need, I will try
> that ...
Progress: I got it working using onComplete: to return some JS from
the server that updated appropriate elements.

Turning htmlReponse on or off did not seem to make a difference. I
think that may be because my server-side Seaside framework turns on
evalScripts by default.

If others here do much of their computation on the server I would
recommend taking a look at Seaside http://seaside.st/  It has a
definite learning curve (due in part to Seaside and in part to the
underlying Smalltalk style of development) ... but after that
productivity is astonishing.

Thanks again !
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

> Turning htmlReponse on or off did not seem to make a difference. I
> think that may be because my server-side Seaside framework turns on
> evalScripts by default.
Setting htmlResponse to false means that the form submission will use
a plain Ajax.Request instead of an Ajax.Updater. See the method
Ajax.InPlaceEditor#handleFormSubmission for usage.

Also, if you have htmlResponse:false then it looks like you
additionally need to pass in an extra option for the response from
your server to be evaluated. Here is an improved call:

new Ajax.InPlaceEditor( ''element-id'', { htmlResponse:false,
ajaxOptions:{evalScripts:true} } );

Sorry for any confusion this caused.

-justin

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

Steve Prior a écrit :
> pieces are pretty simple.  How about refactoring this code out into a 
> dynamic form builder which can take an existing element, save the old 
> contents, and fill it with some form variants (simple text field, pull 
> down selector, <insert your idea here>.  This would be amazingly
useful!
The onFormCustomization callback lets you easily inject extra fields in 
the form, although removing the text-based editor will likely break some 
stuff.

As the rewriter of IPE back in May, I''m interested in the ideas out 
there, although we have to draw the line somewhere, or we''ll end like 
Apache: being all to all, but being bloated for specific cases.  Plus, 
the tests alone would become way unwieldy.

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

Christophe Porteneuve wrote:
> Steve Prior a écrit :
>> pieces are pretty simple.  How about refactoring this code out into a 
>> dynamic form builder which can take an existing element, save the old 
>> contents, and fill it with some form variants (simple text field, pull 
>> down selector, <insert your idea here>.  This would be amazingly
useful!
> 
> The onFormCustomization callback lets you easily inject extra fields in 
> the form, although removing the text-based editor will likely break some 
> stuff.
> 
> As the rewriter of IPE back in May, I''m interested in the ideas
out
> there, although we have to draw the line somewhere, or we''ll end
like
> Apache: being all to all, but being bloated for specific cases.  Plus, 
> the tests alone would become way unwieldy.
> 
Well for starters the new IPE doesn''t handle the cancel button 
"correctly" when htmlResponse is false.  I think cancel should restore
what was there before the edit started, and that doesn''t happen.  I 
wrote a patch and think I posted it to the list, but never got any 
response on that.

I still think that the existing code from IPE could be refactored out to 
  expose the dynamic form building capability and that this would be 
both useful on its own and could still be used by IPE without bloating 
anything.  The dynamic form building piece would have methods for build, 
takedown, and restore old contents.  Then the IPE itself would use that 
and manage the submission of the request and the breakout would make the 
code more readable/modular.  Without making the code more bloated I 
think that this division would make it more easy if someone wanted to 
override the current editor with the example pull down selector I 
mentioned - the form builder part would need to be overridden, but maybe 
the rest of the IPE code could be reused.  With the current 
implementation a selector editor control wouldn''t be able to share 
common code with the IPE.

An interesting exercise would be to see if the onFormCustomization from 
above would naturally move to the form building class or would it stay 
in IPE itself.

Steve

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

> Christophe Porteneuve wrote:
> Well for starters the new IPE doesn''t handle the cancel button
> "correctly" when htmlResponse is false.
Indeed, I hadn''t noticed that until now. I can see that the keydown
listener is not properly attached to the input box and is instead
attached to the span (or whatever is used to trigger the IPE), which
will never fire when we expect it to, if ever.

-justin

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

Justin Perkins wrote:
>> Christophe Porteneuve wrote:
>> Well for starters the new IPE doesn''t handle the cancel button
>> "correctly" when htmlResponse is false.
> 
> Indeed, I hadn''t noticed that until now. I can see that the
keydown
> listener is not properly attached to the input box and is instead
> attached to the span (or whatever is used to trigger the IPE), which
> will never fire when we expect it to, if ever.
I thought the error was caused by the fact that the old value is never 
saved before the form is created, so if the cancel button is pressed 
then nothing reassigns the old value back to the element to set it to 
whatever it was before the IPE was invoked.

Steve

--~--~---------~--~----~------------~-------~--~----~
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 Jan 14, 2008 5:12 PM, Steve Prior
<sprior-k+eNSbF9ABhWk0Htik3J/w@public.gmane.org>
wrote:
> I thought the error was caused by the fact that the old value is never
> saved before the form is created, so if the cancel button is pressed
> then nothing reassigns the old value back to the element to set it to
> whatever it was before the IPE was invoked.
No, it''s a bug (or at least seems like it to me). I''ve patched
my
version and created a new discussion thread with my patch code in it.

-justin

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