[Rails-spinoffs] Re: AJAX vs. SJAX and single threaded javascript
On 10/5/07, Ryan Gahl [EMAIL PROTECTED] wrote: When you call setTimout the buttonhandler reference becomes a closure :) I don't quite understand what you mean. A variable is not a closure. When the function gets executed by the timeout, it does not share neither scope nor execution context with the first invocation. There is no forming of a closure anywhere. --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~--~~~~--~~--~--~---
[Rails-spinoffs] Re: AJAX vs. SJAX and single threaded javascript
We might be speaking about different things here.
When calling setTimeout() with a function reference, the JS engine
does not form a new closure as part of the setTimeout inner workings.
If setTimeout would create a closure, this example sould log 1 and
not undefined:
function foo(){
console.log(test);
}
function bar(){
var test = 1;
setTimeout(foo, 100);
}
bar();
What you see in your example is that buttonhandler itself forms a
closure as it accesses a variable in its outer scope. There is a
closure because of the way the function is defined, not because
setTimeout got a function reference.
Please correct me anyone if my understanding of the situation is off.
--~--~-~--~~~---~--~~
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@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~--~~~~--~~--~--~---
[Rails-spinoffs] Re: AJAX vs. SJAX and single threaded javascript
On 10/5/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
The user types in some text then immediately clicks the button, after a
brief pause for the auto-save to complete the button action should go.
function buttonhandler(){
if (autosave_in_progress){
setTimeout(buttonhandler, 100);
} else {
button_action();
}
}
and set this as the event handler for the button.
--~--~-~--~~~---~--~~
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@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~--~~~~--~~--~--~---
[Rails-spinoffs] Re: AJAX vs. SJAX and single threaded javascript
On 10/5/07, Ryan Gahl [EMAIL PROTECTED] wrote: Indeed... OP dude - it's all about the closures. Except there are no closures involved :-) --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~--~~~~--~~--~--~---
[Rails-spinoffs] Re: Event.stop() and Safari 1.3.9 don't get along
On 8/24/07, Walter Lee Davis [EMAIL PROTECTED] wrote:
The page works perfectly in Safari 2 and Firefox 2, but stubbornly
navigates to the target of the link when clicked in Safari 1.3.9.
My Event.stop() function (Prototype 1.4 based):
stop: function(event) {
if (event.preventDefault) {
event.preventDefault();
event.stopPropagation();
if (isKHtml) {
var element = Event.element(event);
var oldhref = element.href;
element.href = 'javascript:void 0';
(function(){ element.href = oldhref; }).delay(1);
}
} else {
event.returnValue = false;
event.cancelBubble = true;
}
},
You will need to adapt it, obviously. .delay() is a setTimeout wrapper
and isKHtml is true for Safari.
--~--~-~--~~~---~--~~
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@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~--~~~~--~~--~--~---
[Rails-spinoffs] Re: About X-JSON header and evil things... ;)
On 1/25/07, tobie [EMAIL PROTECTED] wrote: Colin, Michael, sanitizeJSON is an option and is off by default. Regarding your patch: Shouldn't the X-JSON processing also use evalJSON() ? And WRT to options.sanitizeJSON, how about a AJAX.sanitizeJSON global option for the default behaviour? Then a developer he want to sanitize every response can set this to true once and he does not have to specifiy this option on every call. string.evalJSON() returns Object if everything is OK null if eval failed undefined if sanitize was requested and failed Shouldn't the last case also return null? On the Ajax object, a seed for a discussion on how it should behave: transport.responseJSON is always initialized with undefined. Users can compare with undefined to see if there was JSON data in the response at all. If content-type is application/json: - a possible X-JSON header is disregarded. - the responseText is eval'd via string.evalJSON() transport.responseJSON is set to the returned value, thous it is * an Object, if evalJSON() succeeds * null, if evalJSON() fails because the eval() failed * null, if sanitize was requested and the data did not pass Question: should failing the sanitize process in evalJSON() trigger onException? I believe yes. If content-type is not application/json: (only the X-JSON part) - the X-JSON header is eval'd via string.evalJSON() transport.responseJSON is set to the returned value, thous it is * an Object, if evalJSON() succeeds * null, if evalJSON() fails because the eval() failed * null, if sanitize was requested and the data did not pass Result: transport.responseJSON always contains the JSON object returned (if there was any), regardless how it was transported. Question: The callbacks get a parameter list of (transport, json). The json parameter is not needed any more, if transport.responseJSON is used consistently, but we cannot let it go for compatibility reasons. If If content-type is not application/json, json gets its value from the X-JSON header. If If content-type is application/json, should it gets its value from from the responseText? I say yes. It should not matter what way (header / body) was used to transfer the data. If is data created by a user, you better sanitize it. Sure, but the server script creating the JSON response should create a valid JSON representation of the user supplied data. If it cannot assure this, then this is the component to fix first. Bye, Martin --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~--~~~~--~~--~--~---
[Rails-spinoffs] Re: About X-JSON header and evil things... ;)
On 1/25/07, Martin Bialasinski [EMAIL PROTECTED] wrote: Regarding your patch: Shouldn't the X-JSON processing also use evalJSON() ? Oops. It does, of cause. --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~--~~~~--~~--~--~---
[Rails-spinoffs] Re: About X-JSON header and evil things... ;)
On 1/25/07, tobie [EMAIL PROTECTED] wrote: I had thaught about a global AJAX.sanitizeJSON option. It certainly something we could implement at some point, but there are some potential issues with that (especially if you rely on some third party libs also using Prototype). That would be only a problem, if the third party module depends on evalJSON() to not only return an object, but to also execute some commands contained in the data, which makes the data not a JSON structure in the first place and it is then an error to call evalJSON. Bye, Martin --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~--~~~~--~~--~--~---
[Rails-spinoffs] Re: getElementsBySelector broken in IE
On 1/24/07, tobie [EMAIL PROTECTED] wrote: I think the issue is in how you have specified your selector (as I mentioned in my last comment). Doesn't adding the universal selector make it work? I can't say, I am not the OP :-) It is just strange that the selector would work in Firefox, but not in IE. Bye, Martin --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~--~~~~--~~--~--~---
[Rails-spinoffs] Re: Form.focusFirstElement
On 1/23/07, Christophe Porteneuve [EMAIL PROTECTED] wrote: On the other hand, I believe it would make a lot of sense to have findFirstElement rely on tabindex attributes when they exist, which would provide spec consistency and maximum flexibility for page developers. This is an excellent idea. --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~--~~~~--~~--~--~---
[Rails-spinoffs] Re: About X-JSON header and evil things... ;)
On 1/23/07, Tom Gregory [EMAIL PROTECTED] wrote: My bad. I found it list here: http://prototypejs.org/discuss Full group address: http://groups-beta.google.com/group/prototype-core Most of my interaction with Prototype/S.a.us comes from this list. I don't quite see the reason for the second list. Is there any problem using this list for discussing changes and future developement? --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~--~~~~--~~--~--~---
[Rails-spinoffs] Re: About X-JSON header and evil things... ;)
On 1/23/07, Christophe Porteneuve [EMAIL PROTECTED] wrote: - Spinoffs is for assistance with Prototype and script.aculo.us both. It's mostly a helpdesk. - Prototype-Core is the list for discussion on the evolution of Prototype, at all levels: global architecture, individual features, etc. These are the topics, but I was wondering why it was felt necessary to divide the group. Changes are mostly because of users' needs and uses. When the needs and uses manifest themselves on the first list, and the discussion about how and what to change happens on the second list, then I fear the code created might not address the problems in the best way because of missing input from divers users. Kind of an artificial barrier between the two groups. Time will tell, I wish you best luck. I just don't feel the necessity to divide the two topics. They pollinate each other, the message count is not overwhelming and the different topics are easily manageable in any decent reader. --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~--~~~~--~~--~--~---
[Rails-spinoffs] Re: Form.focusFirstElement
On 1/23/07, RobG [EMAIL PROTECTED] wrote: Why does Prototype use its lengthy and (to me) very clumsy method rather than the elements collection? Beats me. One solution is to use the form's elements collection, but since that is unreliable in IE with dynamic forms, It is? Interesting. Do you have a reference for this? When using DOM methods to add form controls, IE doesn't properly add the name attribute so you can't use it to reference them with the elements collection. Well, anyone not using builder.js or some other lib should know to use the createNode(string) IE-method. But: The form control does not need a name attribute to be part of elements, if I read my sources correctly. Or is this another IE bug? I don't know, that looks like overkill. How far should that go? As a real-live case, a container with a label and the input whould be made hidden, not the input alone, so you would have to check for this as well. No, you need to check the computed/current style of the element. And how would you do this without walking the DOM? document.defaultView.getComputedStyle() will tell you if the element is visible according to its own style declaration. But it will not tell you that the element is not visible becaue one of its parents is not visible. At least according to my quick tests. and finally ignoring those that are readonly. There is a !element.disabled condition present. readonly != disabled. Oh yes, my bad. Should be checked as well. There are proably good reasons to not skip disabled or hidden elements - if you use it to disable the first element in the form, it will subsequently skip that element if you try to use it to re-enable the element. You are speaking about findFirstElement(), right? Yes, the way the function is described currently this is the case. It is a function that is very specific in its scope. There is no design documentation describing the intention behind the function, so it is rather difficult to tell right from wrong. Return the first input where the user can enter some data or something. findFirstElement() by the letter of the name would be form.elements[0]. And I wonder if anyone actually uses findFirstElement() somewhere and to what purpose (why one wants a reference to the first form control? And without a iterator like findNextElement?). Real life usage, not hypothetical cases. IIRC, it was introduced during a refactoring of focusFirstElement() and looks designed specifically for focusFirstElement(). - As the original poster requests, to focus a button at the top of the form. (creative use of z-index instead of a introducing a include submits option to focusFirstElement() ) No, the request was to focus on the first text input and skip the button. I mixed that up. Well, then it would be a substitute for a do not include submit/reset/button option. I don't think any general function is going to provide such fine control without a large number of paramters and good documentation. Agreed. The tab-index would basically be used as a override for cases where focusFirstElement() does not do the right thing. But how does anyone know what the right thing is? Documentation. Once the default case is specified, addressing readonly, disabled, input type, etc. --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~--~~~~--~~--~--~---
[Rails-spinoffs] Re: afterfinish not being called
On 1/24/07, noah_ten [EMAIL PROTECTED] wrote: I'm having some trouble getting afterfinish to be called properly. It is called afterFinish. Javascript is case-sensitive. --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~--~~~~--~~--~--~---
[Rails-spinoffs] Re: this.loop.bind is not a function
There was a threat (or even a bug on Trac) about a bug in Firefox 2 relating to window.open(). I think this is what you see. --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~--~~~~--~~--~--~---
[Rails-spinoffs] Re: Should Event.stopObserving() remove itself from cache?
On 12/14/06, heidmotron [EMAIL PROTECTED] wrote:
script is:
Event.observe('test', 'click', function(){ alert('I am so happy') })
Your Event.observers.length is 1
then you want to remove test, so before you actually remove it from the
dom you are kind enough to say,
hey, test div, stop observing that click and go have a beer
Event.stopObserving('test', 'click', function(){ alert('I am so happy')
})
You would think that observer would have beer and get out of the
Event.observers array so length would equal Zero.
The observers array is not the problem. You want the browser to stop
executing the function on click, and stopObserving does work this way.
The problem with your code is, that you say react to click by
executing anonymous function1 and then say do not longer react to
click by executing anonymous function2. Your functions look the same,
but they are not the same objects. So the browser can't remove the
event listener.
Try this in firebug:
(function(){ foo }) === (function(){ foo })
The result is false.
You need to save the function on observe and pass it on stopObserving.
var mycallback = function(){ alert('I am so happy') };
// function(ev){ alert('I am so happy') }.bindAsEventListener(); to
get the event object
Event.observe('test', 'click', mycallback);
Event.stopObserving('test', 'click', mycallback);
It will not remove the entry from the observers array, but it will
remove the event listener, and this is what counts.
--~--~-~--~~~---~--~~
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@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~--~~~~--~~--~--~---
[Rails-spinoffs] Re: IE7 Drag Drop
Your problem description is rather confused. It is always best to put an example online and to describe what steps to perform to see the problem. If you are talking about an OL-List where the number of an element gets set to 1 when you start to drag it, then it is a bug in Internet Explorer. Microsoft still has not fix it with IE7? Gosh. See http://www.satzansatz.de/cssd/onhavinglayout.html#list --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~--~~~~--~~--~--~---
[Rails-spinoffs] Re: Strange behaviour enabling Show XMLHttpRequests
On 12/9/06, Miguel [EMAIL PROTECTED] wrote: I'm experiencing a strange problem when trying to visualize XMLHttpRequests. I've got Show XMLHttpRequests checked in the options of the console window, but Firebug won't show until I disable and re-enable the option. There is a Firebug group on Google Groups. You will have better luck asking there. --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~--~~~~--~~--~--~---
[Rails-spinoffs] Re: Shrinking Prototype's timed form observer code
On 12/9/06, Peter Michaux [EMAIL PROTECTED] wrote: But we are still distributing the code every time it needs to be used If you don't use sane clientside caching. So Prototype made the decision to have a cryptic API It is not. and long-named, short-lived local variables. Seems like the wrong way around to me. Eat your own dog food. Convert all variables to two letter ones in yout fork project first. --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~--~~~~--~~--~--~---
[Rails-spinoffs] Re: Shrinking Prototype's timed form observer code
On 12/9/06, Martin Bialasinski [EMAIL PROTECTED] wrote:
On 12/9/06, Peter Michaux [EMAIL PROTECTED] wrote:
Note also that in the Prototype code
if (this.lastValue != value) {
should probably be
if (this.lastValue !== value) {
because both 0 and the empty string '' typecast to false and so 0!=''
returns false.
This is true.
I have to retract this statement. lastValue and value are both either
strings or booleans, so a type-safe comparison is not needed. But it
would not hurt either, of cause.
--~--~-~--~~~---~--~~
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@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~--~~~~--~~--~--~---
[Rails-spinoffs] Re: Ajax.Request, Form.Serialize
On 12/2/06, Mislav Marohnić [EMAIL PROTECTED] wrote: How about adding an optional parameter to the existing function? With it you could control the return type (hash or string). Would work as well, when the default is as string. That said, the parameter should be string|hash and not false|true to make it easier to understand when reading the code. And your fully functional hash proposal should really replace the current implementation which looks like its origins were a need for a simple fromQuery / toQuery mechanism. New bug report where the current implementation bites the users: http://dev.rubyonrails.org/ticket/6788 --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~--~~~~--~~--~--~---
[Rails-spinoffs] Re: 3 prototype/scriptaculous effects in order on one div
On 11/27/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I need it to go like this...
Effect.Fade,Ajax.Update,Effect.Appear
but everytime I try to do it it just trys to do all of them at once,
You need to start the next step in the callback that gets executed
when the previous step finishes. Pseudo code:
Effect.Fade(..., {
afterFinish: function(){
Ajax.Update(..., {
onComplete: function(){
Effect.Appear(...)
}
})
}
})
onComplete is a guess, I do not use Prototype's Ajax. Please look up
the proper callback in the docs.
--~--~-~--~~~---~--~~
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@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~--~~~~--~~--~--~---
[Rails-spinoffs] Re: 3 prototype/scriptaculous effects in order on one div
On 12/3/06, Christophe Porteneuve [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] a écrit : Effect.Fade,Ajax.Update,Effect.Appear The best way to go is element-scoped effect queues. With Ajax.Update inbetween? --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~--~~~~--~~--~--~---
[Rails-spinoffs] Re: 3 prototype/scriptaculous effects in order on one div
On 12/3/06, Fabian Lange [EMAIL PROTECTED] wrote:
Actually this was the first post I made here. I solved it this way:
loop: function(timePos) {
if(timePos = this.startOn) {
Element.update(this.element,this.options.newContent);
this.cancel();
return;
}
}
new Effect.Fade(el,{queue:'front'});
new Effect.Updater(el,{newContent:ajax.responseText,queue:'end'});
new Effect.Appear(el,{queue:'end'});
I don't see how this would work in the desired way. Element.update()
is asyncronous. The Effect.Appear() will start just after the request
was made, it will not wait until the response is in.
--~--~-~--~~~---~--~~
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@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~--~~~~--~~--~--~---
[Rails-spinoffs] Re: Prototype question....
On 12/1/06, Stripe-man [EMAIL PROTECTED] wrote:
function menu_action(item){
var menuitem = 'div.'+item+':click';
Event.addBehavior({
// click on the green div (for fun ;-)
menuitem : function(event) {
new Effect.Highlight(this, { queue: 'end' });
}
});
}
This does not work, as { foo: bar } equals { foo: bar}. The
property part of the object literal does not get extrapolated.
Event.addBehavior({
// click on the green div (for fun ;-)
'div#'+item+':click' : function(event) {
new Effect.Highlight(this, { queue: 'end' });
}
});
should do it.
--~--~-~--~~~---~--~~
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@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~--~~~~--~~--~--~---
[Rails-spinoffs] Re: Ajax.Request, Form.Serialize
On 11/24/06, Mislav [EMAIL PROTECTED] wrote: On Nov 20, 11:29 pm, Martin Bialasinski [EMAIL PROTECTED] wrote: You mean it accepts both a String or an Object as the values to be transmitted, but does the round-trip for strings? Seems unnecessary. The reason behind this was to reduce the number of string hacks (inspecting, appending) to add parameters internally in the framework. That makes sense. - my next ticket/patch will be about Form.serialize returning a hash (not a string) Uuh, changing the default return type of the function? Sounds like a bad idea. APIs change. Destruction is the form of creation. On the other hand, maybe the ticket will be rejected - who knows? But, it is my opinion that there is really no sense for Form to urlencode serialized data anymore - Ajax now handles that. How about adding a new function that returns an Object. and change the Ajax functions to use this new function, ... People pass the results of Form.serialize directly to Ajax.Request anyway. ... and document the new function as the preferred way from then on. This would not disrupt existing code. --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~--~~~~--~~--~--~---
[Rails-spinoffs] Re: Event.observe for onSubmit event of a form
On 11/14/06, Andrei Popov [EMAIL PROTECTED] wrote:
When I am tracing execution of [1] in Drosera (or Venkman, for that
matter), I see that for some reason $('myform') returns undefined
(this is n prototype.js 1.5.0_rc0). However, CSS does not seem to
have any problem styling it.
Looks like you have the script before the 'myform' element in your
document. Also Ken is right about .bindAsEventListener().
--~--~-~--~~~---~--~~
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@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~--~~~~--~~--~--~---
[Rails-spinoffs] Re: Ajax parameter issue in Prototype SVN (1.5RC2)
On 11/13/06, Mark Reginald James [EMAIL PROTECTED] wrote: does not work in the current SVN prototype because an equals sign is appended to the post string. Of course it is, as per docs, specs, and common sense. There should also be the field's VALUE sent there, right after the '=' sign. If the value is empty at the time, of course there won't be anything. Should I submit a patch to Prototype's toQueryString function, .toQueryString() is perfectly fine, especially on SVN. I'm just saying (and warning) that what once worked now doesn't, and was asking whether my usage was a quirk that just happened to work, or whether the breakage was unintentional and a patch is in order. Your usage depended on a bug in .toQueryString() that was fixed recently. --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~--~~~~--~~--~--~---
[Rails-spinoffs] Re: Why Struts2 use dojo instead of Scriptaculous?
On 11/5/06, Angelo zerr [EMAIL PROTECTED] wrote: Again, in a portal environment, where you aren't developing a complete page and therefore can't be sure what might be present on the page at any given time, you can run into some big problems because of this. This is very true. I don't know what I must answer to Struts forum to use scriptaculous. They have compelling reason to use Dojo, and given their environment, it is a good decision, IMHO. Prototype is not made for this kind of usage. --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~--~~~~--~~--~--~---
[Rails-spinoffs] Re: Forcing a dropdown selection?
On 11/2/06, Deco Rior [EMAIL PROTECTED] wrote: was kind of suprised I could not find an elegant extension of this in autocompleter The best explanation: No one needed this so far. Bye, Martin --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs -~--~~~~--~~--~--~---
[Rails-spinoffs] Re: Viewing returned header
On 11/2/06, Succhan [EMAIL PROTECTED] wrote:
I just watched a screencast on how to use Firebug for debugging. So I
gave that a go.
Trying to run request.header('My-Header-Name') throws an exception that
is caught, TypeError: request.header is not a function
I would have used Firebug to set a breakpoint and inspect the
request argument.
--~--~-~--~~~---~--~~
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@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs
-~--~~~~--~~--~--~---
[Rails-spinoffs] Re: I upgraded to 1.5.0 and my old code stopped working
On 11/1/06, Fred [EMAIL PROTECTED] wrote: Incorrect. The forms collection is a formal collection in the W3C DOM HTML specification: alert(document.forms[0].docid.value); Not quite. HTMLFormElement does not have a docid property defined in the above mentioned specification. You have to go through its elements properties. document.forms[0].elements[docid].value When using forms, both $() and hence $F() have problems if id and name attributes share the same value. Only in Internet Explorer and only there is more than one element involved in this sharing, no? Using names for form controls is valid HTML and provides support for old browsers. The name attribute is required for all but submit and reset inputs. Bye, Martin --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs -~--~~~~--~~--~--~---
[Rails-spinoffs] Re: Is a Draggable region constraint possible?
On 10/30/06, Christophe Porteneuve [EMAIL PROTECTED] wrote: I tried subscribing and leaving an announcement about this group There is also a group named prototype.js --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs -~--~~~~--~~--~--~---
[Rails-spinoffs] Re: Prototype: Form.serialize includes disabled elements
On 10/24/06, Thomas Fuchs [EMAIL PROTECTED] wrote: Btw, just applied the patch to Prototype trunk, see http://dev.rubyonrails.org/changeset/5354 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs -~--~~~~--~~--~--~---
[Rails-spinoffs] Re: Prototype: Form.serialize includes disabled elements
On 10/24/06, Zyclops [EMAIL PROTECTED] wrote: When using form.serialize, it also includes disabled elements. This is a bug. Would it be possible to alter future versions of prototype to not include disabled elements, or have an option not to include disabled elements. http://dev.rubyonrails.org/ticket/4586 Is there a trac(or similar program) for prototype? See above. --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs -~--~~~~--~~--~--~---
[Rails-spinoffs] Re: Prototype question regarding Form.Element.EventObserver
On 10/23/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
in header, i have
script type=text/javascript
new Form.Element.EventObserver(id1, function(ele,value){
$('id2').innerHTML=bal} );
/script
Execution of JS code happens as the HTMl file is parsed. The time this
code is executed, there is no id2 element in the DOM.
--~--~-~--~~~---~--~~
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@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs
-~--~~~~--~~--~--~---
[Rails-spinoffs] Re: why this code is not working in IE?
On 9/28/06, Javier Martinez [EMAIL PROTECTED] wrote: I have this code that creates a select multiple and three options on it. The I select all options. In firefox and Opera it works well, but in IE the select is not multiple and in another code, the select is multiple but only select the last options :S A IE bug. See http://channel9.msdn.com/wiki/default.aspx/Channel9.InternetExplorerProgrammingBugs for a kludge. --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs -~--~~~~--~~--~--~---
[Rails-spinoffs] Enumerable.inGroupsOf() should fill up with undefined instead of null?
Hi, I cannot add comments to the bugtracker, it seems, so here we go: There is this new method for Enumerables: [1,2,3,4,5].inGroupsOf(3) - [[1,2,3],[4,5,null]] To me, null is something explicitly set by the user / developer to no value, not applicable, whereas undefined means this value was not set explicitly at all. So I wonder, if undefined would be the better default value to indicate not part of the initial dataset. Bye, Martin --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs -~--~~~~--~~--~--~---
[Rails-spinoffs] Re: Enumerable.inGroupsOf() should fill up with undefined instead of null?
On 9/22/06, Christophe Porteneuve aka TDD [EMAIL PROTECTED] wrote:
I do believe the latter values ARE undefined. What you *see* in the
text representation is a result of a pending bug in Object.inspect, that
displays undefined's as null's.
They are null alright:
inGroupsOf: function(number, fillWith) {
fillWith = fillWith || null;
--~--~-~--~~~---~--~~
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@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs
-~--~~~~--~~--~--~---
[Rails-spinoffs] Re: Enumerable.inGroupsOf() should fill up with undefined instead of null?
On 9/22/06, Thomas Fuchs [EMAIL PROTECTED] wrote: hmm-- i've modelled it after the rails ruby extension[1]. Which uses nil. Note that the german version of the article is much clearer and mentions the synonymity of null and nil explicitly. I believe the english version has some good points, see below. So null in JavaScript should be equal to nil in Ruby. There are reasons to say nil in Ruby == undefined in Javascript. The Wikipedia article distinguishes between two meanings: Quote: Null is a special value for a pointer (or other kind of object reference) used to signify that the pointer intentionally does not have a target. [...] Some languages use other nomenclature for such a pointer, e.g., nil, undefined, void reference, etc. = undefined in Javascript, nil in Ruby Quote: In many disciplines, the concept of null allows a three-valued logic, with null indicating unknown value. = null in Javascript. What about Ruby, does it have something similar? Javascript supports both concepts with null and undefined respectively. Using undefined instead of null makes sure, that you can have an array with members using this three-valued logic. Furthermore: var foo; depicts a variable that does not have a value. foo is undefined, not null. And I believe this is what the filler elements are. Array members that do not have a value (that are undefined), because they were not part of the original array. Of cause, you can do arr[3] = undefined;, but still: choosing between null and undefined, undefined seems to carry the meaning better than null. --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs -~--~~~~--~~--~--~---
[Rails-spinoffs] Re: How to deal with Unicode chars inside X-JSON HTTP header (besides UCS)?
I am sorry, I did not understand you correctly. And I also have to revise my understanding of the matter. RFC2616, Section 2.2 says: The TEXT rule is only used for descriptive field contents and values that are not intended to be interpreted by the message parser. Words of *TEXT MAY contain characters from character sets other than ISO- 8859-1 [22] only when encoded according to the rules of RFC 2047 [14]. TEXT = any OCTET except CTLs, but including LWS What seems to happen is that Firefox assumes the X-JSON header to contain a ISO-8859-1 encoded value and performs a conversion ISO-8859-1 - UTF8. So multi-byte codepoint don't work. I tried quoted printable but had no luck, but it might be just me. And there is also the question how the various browsers handle this. --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs -~--~~~~--~~--~--~---
[Rails-spinoffs] Re: Prototype: element-id.$() instead of $('element-id')
On 9/12/06, Christophe Porteneuve [EMAIL PROTECTED] wrote: Aside from the '$ overuse' issue, for/in indeed doesn't work too good on Prototype-extended objects, what with all the methods. for ( in ) loops are supposed to work with Objects and they do flawlessly. This is why Object.prototype is not tempered with. for ( in ) loops do not make sense for the other native data types, and user defined classes can't mark properties non-enumerable anyway (a ECMAScript omission), so for ( in ) can only be used for introspection on them. Object.keys() is not there because for ( in ) does not work (it does), it is a syntactic sugar. If you look at the implementation, it is just a for ( in ) loop. If it would not work properly, Object.keys() could not have used it, obviously. --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs -~--~~~~--~~--~--~---
[Rails-spinoffs] Re: Prototype: element-id.$() instead of $('element-id')
On 9/11/06, Nic Williams [EMAIL PROTECTED] wrote: So would it still be useful for a revised $() function? There is no need to change $(). What you see is the legacy of Netscape taking a stride away from the ECMAScript standard. Netscape's JS engine treated (and still treats) strings as array of strings to allow things like test[0] to return t. I do not know the internal working, but from observation: When using this in a function defined in String.prototype, this behaves like a string, when the context of the use requires a string. And it looks like the engine knows document.getElementById() requires a string. If the context does not require a string, like when using this as a function argument to a user defined function, this evaluates to an array of chars. Therefore, the error is not with $(). Besides the before mentioned $(String(this)), $(this.valueOf()) will work as well. --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs -~--~~~~--~~--~--~---
[Rails-spinoffs] Re: Prototype: element-id.$() instead of $('element-id')
On 9/11/06, Dr Nic [EMAIL PROTECTED] wrote:
Object.prototype.$H = function() {
Vade retro, Satanas!
This breaks the Object is an empty container and can be safely looped
with for( in ) convention.
http://erik.eae.net/archives/2005/06/06/22.13.54
--~--~-~--~~~---~--~~
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@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs
-~--~~~~--~~--~--~---
