Rails spinoffs - May 2007 - Prototype: Element.replace vs. Element.update

Any of you! Can you explain what''s the real difference between
Element.replace and Element.update in prototype?


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

Luca a écrit :
> Any of you! Can you explain what''s the real difference between
> Element.replace and Element.update in prototype?
Exactly as doc''d [1]: replace replaces the element itself (and all its
contents, too), while update replaces only the element''s contents.

Multiple examples in the doc.  Please check it out before posting :-)
Also consider saying Hi, and thanking people in advance.  Your post
sounds like a pop quizz by a vicious teacher...

[1] http://prototypejs.org/api/element/update
    http://prototypejs.org/api/element/replace

-- 
Christophe Porteneuve a.k.a. TDD
"[They] did not know it was impossible, so they did it." --Mark Twain
Email: 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
-~----------~----~----~----~------~----~------~--~---

Also, the gotcha that is not well documented is this:  if you replace an 
element, any event observation being done by the original element is not 
done by the the new one.  But, if you simply update the original 
element, you may not have to reconstruct your observations.

 - Dash -

Christophe Porteneuve wrote:
> Hey Luca,
>
> Luca a écrit :
>   
>> Any of you! Can you explain what''s the real difference between
>> Element.replace and Element.update in prototype?
>>     
>
> Exactly as doc''d [1]: replace replaces the element itself (and all
its
> contents, too), while update replaces only the element''s contents.
>
> Multiple examples in the doc.  Please check it out before posting :-)
> Also consider saying Hi, and thanking people in advance.  Your post
> sounds like a pop quizz by a vicious teacher...
>
> [1] http://prototypejs.org/api/element/update
>     http://prototypejs.org/api/element/replace
>
>   
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

David Dashifen Kees a écrit :
> Also, the gotcha that is not well documented is this:  if you replace an 
> element, any event observation being done by the original element is not 
> done by the the new one.  But, if you simply update the original 
> element, you may not have to reconstruct your observations.
Well, yes.  It''s just obvious *when you know how events are attached*
in
the DOM: to the DOM object, not to any id= or whatnot.  If you replace
the DOM object, the new one has no reason to steal the handlers from the
old one...

-- 
Christophe Porteneuve a.k.a. TDD
"[They] did not know it was impossible, so they did it." --Mark Twain
Email: 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
-~----------~----~----~----~------~----~------~--~---

I agree, but the semantics of the word replace, outside of a programming 
paradigm, seems to indicate that the new thing will be similar and act 
similarly to the old thing.  If I replace, for example, one of my old 
bookshelves, it seems logical that I would do so with an object that 
stores books.  While I recognize that the extension of function names 
semantically outside a programming paradigm doesn''t always work 
perfectly, when I started using replace and update, it took me quite 
some time to figure out why all of my events stopped happening and, it 
still happens to me now and again and I have to rethink things.   
Anyway, I just thought I'' mention it to try and save Luca some time.

 - Dash -

Christophe Porteneuve wrote:
> David Dashifen Kees a écrit :
>   
>> Also, the gotcha that is not well documented is this:  if you replace
an
>> element, any event observation being done by the original element is
not
>> done by the the new one.  But, if you simply update the original 
>> element, you may not have to reconstruct your observations.
>>     
>
> Well, yes.  It''s just obvious *when you know how events are
attached* in
> the DOM: to the DOM object, not to any id= or whatnot.  If you replace
> the DOM object, the new one has no reason to steal the handlers from the
> old one...
>
>   
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

David Dashifen Kees a écrit :
> I agree, but the semantics of the word replace, outside of a programming 
> paradigm, seems to indicate that the new thing will be similar and act 
> similarly to the old thing.  If I replace, for example, one of my old 
Point taken, but are you seriously suggesting that we should use words
that make sense *even outside of a programming paradigm*?  Why would we?
 Prototype is very much about programming.  What about upcoming methods
like "curry" then? :-)

-- 
Christophe Porteneuve a.k.a. TDD
"[They] did not know it was impossible, so they did it." --Mark Twain
Email: 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
-~----------~----~----~----~------~----~------~--~---

David Dashifen Kees wrote:
> If I replace, for example, one of my old 
> bookshelves, it seems logical that I would do so with an object that 
> stores books. 
I think that''s a flawed example. If I replace my car with a new one I
wouldn''t
expect that the new car has the same stereo system as my old car with the same
radio stations as presets. Sure they are both cars (just like both of your
elements were elements) but it won''t retain any of the customization
(event
handlers) that I added to my old car.

If I want my new car stereo to behave like my old one I have to customize it in
the same way as my old one.

-- 
Michael Peters
Developer
Plus Three, LP


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

I personally don''t know what you mean by curry, but if it
doesn''t result
in tasty food, then I''m not sure how it works.  However, I am actually 
saying that the best results are names which have logical, semanitc 
meanings outside of a programming paradigm because not everyone who uses 
a language like JavaScript (and enhancements to it like Prototype) are 
going to be programmers.  Even as a programmer with advanced degrees and 
over a decade of web programming, I was completely floored when 
replace() didn''t keep event listeners.  Granted, when I read the code 
and analyzed things more carefully rather than extending my 
understanding of the word "replace" onto the function named the same,
I
understood how my assumptions were flawed.  I just wanted to help Luca 
out in the hopes that if she/he made the same assumptions, then as 
little time as possible would be lost.

 - Dash -

Christophe Porteneuve wrote:
> David Dashifen Kees a écrit :
>   
>> I agree, but the semantics of the word replace, outside of a
programming
>> paradigm, seems to indicate that the new thing will be similar and act 
>> similarly to the old thing.  If I replace, for example, one of my old 
>>     
>
> Point taken, but are you seriously suggesting that we should use words
> that make sense *even outside of a programming paradigm*?  Why would we?
>  Prototype is very much about programming.  What about upcoming methods
> like "curry" then? :-)
>
>   
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

True, but the interface of the stereo -- the knobs and buttons you turn 
and push -- should remain the same from one to the other.  Or, your new 
car that replaces your old one should probably continue to respond in 
some way to an event with a congruous result.  In other words, pressing 
the gas pedal the Toyota Prius you just picked up to replace the 
mid-70''s VW Bug you''ve been driving should still accelerate
your card.
That the Prius accelerates in a mechanically different way than the VW 
Bug is not important to you as the driver, but if newer cars suddenly 
switched the gas and the break, there''d be some problems.

In some ways, I suppose my argument breaks down; as Christophe said in 
his other post, there may not be any way to name the methods of 
Prototype objects and object enhancements that''s going to work for all 
people.  But, I knew that when I think of a replacing object A with 
object B, I would expect object B to respond in ways similar to A.  In 
Prototype, that means B has the same methods and may have some of the 
same properties as B but will not respond to the events that A did.  I 
felt that, while logical, this point was unclear to me and may be 
unclear to others.  Perhaps I was wrong.

Anyway, I should get back to work, though I appreciate the stimulating 
"conversation."

 -- Dash --

Michael Peters wrote:
> David Dashifen Kees wrote:
>   
>> If I replace, for example, one of my old 
>> bookshelves, it seems logical that I would do so with an object that 
>> stores books. 
>>     
>
> I think that''s a flawed example. If I replace my car with a new
one I wouldn''t
> expect that the new car has the same stereo system as my old car with the
same
> radio stations as presets. Sure they are both cars (just like both of your
> elements were elements) but it won''t retain any of the
customization (event
> handlers) that I added to my old car.
>
> If I want my new car stereo to behave like my old one I have to customize
it in
> the same way as my old one.
>
>   
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Alrighty, having read up on currying in JavaScript (I knew it as lambda 
functions) I agree, there''s no good way to name that function so that
it
has a meaning outside of a programing paradigm because it is a 
programing technique.  I suppose you could argue that you can build half 
a car and later, when new materials are available, finish the car but 
either way, the concept of partially evaluating functions and waiting 
until other input is ready is a technique, not really an interface.  
Plus, since currying has a well-known programming meaning, it approaches 
concepts like flow-control or function scoping which are technical terms 
with technical meanings that I would expect a new or old programmer to 
invest the time in learning.  That argument could be made for the 
Prototype API, and in some cases should be made.

Any way, I admit that there are limitations to naming schemes that are 
as accurate as possible inside and outside of the paradigm for which 
they''re intended.  However, when it is possible to rename something so 
that it''s interface -- in this case the name of a function -- is 
recognizable and understandable to people by name, the ability to use 
that interface is enhanced and the code becomes more beautiful. 

I guess you may wonder, then, if I have a better name the replace 
method, I do not.  I tend to avoid it in my code because of the 
perceptual problems I have with it and, instead, use remove() to 
explicitly get ride of an object and then appendChild() to add a new one 
back into the DOM.  More work? Yes.  More code? Yes.  But it my 
experience, the maintainability of clearly written code is greater than 
that of concise code.

 - Dash -

Christophe Porteneuve wrote:
> David Dashifen Kees a écrit :
>   
>> I agree, but the semantics of the word replace, outside of a
programming
>> paradigm, seems to indicate that the new thing will be similar and act 
>> similarly to the old thing.  If I replace, for example, one of my old 
>>     
>
> Point taken, but are you seriously suggesting that we should use words
> that make sense *even outside of a programming paradigm*?  Why would we?
>  Prototype is very much about programming.  What about upcoming methods
> like "curry" then? :-)
>
>   
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

David,

I think you are mixing up tow different things: presentation and
behavior.

Replacing an element only has to do with the presentation layer.

To take your car example:

If you replace your car, you don''t expect your new car''s gas
tank to
contain the same amount of gas your previous car had.

You''ll have to refill if you want to drive.

Same with handlers IMHO.

-- Tobie



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

David Dashifen Kees wrote:
> Alrighty, having read up on currying in JavaScript (I knew it as lambda 
> functions) I agree, there''s no good way to name that function so
that it
> has a meaning outside of a programing paradigm because it is a 
> programing technique. 
Actually there was some discussion on the prototype-core list for names. I like
given(). Like "this function given these arguments". That''s
what Perl 6 calls
it''s currying method. But I''m a little biased since
I''m a Perl guy :)

-- 
Michael Peters
Developer
Plus Three, LP


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

True, but I think things work best when presentation suggests behavior.

 -- Dash --

tobie wrote:
> David,
>
> I think you are mixing up tow different things: presentation and
> behavior.
>
> Replacing an element only has to do with the presentation layer.
>
> To take your car example:
>
> If you replace your car, you don''t expect your new car''s
gas tank to
> contain the same amount of gas your previous car had.
>
> You''ll have to refill if you want to drive.
>
> Same with handlers IMHO.
>
> -- Tobie
>
>
>
> >
>
>   
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

> Actually there was some discussion on the prototype-core list for names. I
like
> given(). Like "this function given these arguments".
That''s what Perl 6 calls
> it''s currying method. But I''m a little biased since
I''m a Perl guy :)
I liked ''given'' too, but it was ruled out for a very good
reason I
actually rally to:

Curry, like bind, wrap, defer and delay, is a verb. Given isn''t.

best,

-- tobie



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