[Prototype-core] Opera 9 support
Hi, Although Opera 9 is *not* officially supported by Prototype, it passes nearly all tests. It would be great to be able to officialy support Opera 9 in upcoming versions of Prototype. This would at least imply dealing with the currently failing tests. Here's a list for Opera 9.02 (on Mac OSX 10.4). in form.js: * testFormActivating and * testFormRequest. in position.js: * testWithin. in dom.js: * testElementUpdateInTableRow, * testElementUpdateInTable, * testElementGetStyle and * testElementReadAttribute. As you see, there's not that much to do (although there might be other issues that the unit tests don't cover). So if anybody is willing to help me out on this issue, that would be very much appreciated. Tobie --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Documentation typos (new Ajax.Request)
That's been corrected. Thanks for the heads-up. Tobie --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Running in circles!
Richard, Could you please kindly post this into - http://groups-beta.google.com/group/rubyonrails-spinoffs ? The Prototype Core list is for discussion of patches, releases, and other issues related to the development of Prototype. It is not for support questions - please use the users mailing list for this. Thanks! Tobie --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Spelling/grammar error on website
That's now been corrected. Thanks! On Feb 24, 5:03 pm, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: The first red warning box onhttp://prototypejs.org/learn/introduction-to-ajax has an incorrect word. In the italicized portion Ajax requests can on be made to URLs of the same protocol, host and port of the page containing the Ajax request., the first on should instead be only. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: new Event functionality
Hi, Just to let you know that I have a very lightweight custom event implementation which is available here (and which I'd hapilly donate to Prototype if need be): http://sandbox.tobielangel.com/custom_event/src/custom_event.js A demo logging the results to the console is available here: http://sandbox.tobielangel.com/custom_event/index.html It's basically a publisher/subscriber system which allows total decoupling by storing the relationships in a global cache. Which means that you can subscribe to an event even before the publisher of that event exists. Another thing which might be interesting to dig into is Aspects - this is what Dojo uses for their cusom event system. Regards, Tobie --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Ajax.Request - eval()'ing the responseText
Hi DK, You should have a look at this: http://groups.google.com/group/prototype-core/browse_thread/thread/43c13d4b233b20fb/?hl=en# Should solve your problems in the near future. Regards, Tobie --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Prototype.Date.Succ
Don't know from where i got that link Probably from trac ;-) http://dev.rubyonrails.org/ticket/6342 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: cosmetic documentation updates needed
That's now been corrected. Thanks for the heads up. Tobie On Mar 13, 1:44 am, Marius Feraru [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 While updating the PJS Firefox sidebar I noticed some classes are missing their table of contents (//[EMAIL PROTECTED]sidebar]/[EMAIL PROTECTED]methods]/li/a) Not really important, but anyway, for conformity: http://prototypejs.org/api/objecthttp://prototypejs.org/api/objectrangehttp://prototypejs.org/api/periodicalExecuterhttp://prototypejs.org/api/prototype All subsequent pages - e.g.http://prototypejs.org/api/prototype/K- have their TOC. cheers - -- Marius Feraru -BEGIN PGP SIGNATURE- iD8DBQFF9joktZHp/AYZiNkRAl6zAJ9wdcHiWAeBKpTAKtP818ZCJvHFEwCfRj8s BuHcwe6jM3AKAO8jNuQsqzM= =iHeo -END PGP SIGNATURE- --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Hash.toQueryString changes
Trac should be back up now... so you're welcome to submit that. On Mar 15, 1:31 am, Colin Mollenhour [EMAIL PROTECTED] wrote: Trac isn't responding at the moment so I can't explore and see what other problems Hash.toQueryString is having, but I completely rewrote it myself to support nested structures and the rewrite handles all of the cases mentioned in this thread correctly (including for servers out there that aren't running Rails). The string returned reproduces the original data structure on the server-side flawlessly and is only 26 lines of code total! For your consideration, I've included the code and a test page that allows you to run your own tests and includes a good default test case that also shows off it's abilities nicely. It can be tested alongside the Prototype 1.5.1_rc1 version which obviously does not encode arrays correctly and cannot encode the nested structures. Code:http://pastie.caboo.se/47059 Test:http://colin.mollenhour.com/posttest.php I'd appreciate your opinions and tests if you think you can break it. Thanks, Colin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: DOM builder in Prototype core?
I'd favor writeAttribute to be consistant with readAttribute... and setStyle (which is not pluralized). Some heated debate in perspective! On Mar 15, 8:42 am, Mislav Marohnić [EMAIL PROTECTED] wrote: On 3/15/07, Martin Ström [EMAIL PROTECTED] wrote: FYI: tests and code are now submitted to trac: http://dev.rubyonrails.org/ticket/7476#comment:2 Nice! This is a very solid foundation for a more featured Builder (IMO). But, I would rename writeAttributes to setAttributes for consistency with setStyle (which also takes a hash). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Ajax help
no problem. Thanks for your understanding.
Tobie
On Mar 18, 7:30 pm, Gareth Evans [EMAIL PROTECTED] wrote:
Oops sorry Tobie, didnt notice this was core- just subscribe to the thread
via email.
My bad.
Gareth
On 3/19/07, Tobie Langel [EMAIL PROTECTED] wrote:
Hi guys,
Don't want to sound rude, but this thread doesn't belong in Prototype
core.
Could you kindly pursue in the spinoffs mailing list (http://
groups.google.com/group/rubyonrails-spinoffs?lnk=lihl=en) ?
Thanks and best regards,
Tobie
On Mar 18, 7:23 pm, andymadonna [EMAIL PROTECTED] wrote:
Hi Gareth,
The create_year function creates all the dates for that year on the
timeline. I have it on my live site to test the code:
http://the60s.andrewmadonna.com/timeline.html
Here is the actual function:
function create_year(transport) {
alert(I am being executed!);
var timeline_content = document.createElement(div);
timeline_content.setAttribute(id,timeline_content);
var timeline = document.createElement(div);
timeline.setAttribute(id,timeline);
var line = document.createElement(div);
line.setAttribute(id,line);
var xmlDoc = transport.responseXML.documentElement;
var loop_length = xmlDoc.getElementByTagName(date).length;
var isBottom = false;
for (var i=0;iloop_length;i++) {
var date_title = xmlDoc.getElementByTagName(date)
[i].childNodes[0].childNodes[0].nodeValue;
var date_text =
document.createTextNode(xmlDoc.getElementByTagName(date)
[i].childNodes[1].nodeValue);
var date = document.createElement(div);
date.setAttribute(title,date_title);
var date_line = document.createElement(div);
date_line.setAttribute(class,date_line);
if (!isBottom) {
date.setAttribute(class,date);
date.appendChild(date_text);
date.appendChild(date_line);
isBottom = true;
} else {
date.setAttribute(class,date_bottom);
date.appendChild(date_line);
var date_bottom_text = document.createElement(div);
date_bottom_text.setAttribute(class,date_element_text);
date_bottom_text.appendChild(date_text);
date.appendChild(date_bottom_text);
isBottom = false;
}
timeline.appendChild(date);
}
timeline.appendChild(line);
timeline_content.appendChild(timeline);
var next_arrow = document.createElement(div);
next_arrow.setAttribute(id,next);
next_arrow.setAttribute(class,arrows);
next_arrow.setAttribute(onclick,slide_timeline_next(););
var next_arrow_text = document.createTextNode(gt;br /br
/br /gt;);
next_arrow.appendChild(next_arrow_text);
timeline_content.appendChild(next_arrow);
var previous_arrow = document.createElement(div);
previous_arrow.setAttribute(id,previous);
previous_arrow.setAttribute(class,arrows);
previous_arrow.setAttribute(onclick,slide_timeline_previous(););
var previous_arrow_text = document.createTextNode(lt;br /br
/br /lt;);
previous_arrow.appendChild(previous_arrow_text);
timeline_content.appendChild(previous_arrow);
document.body.appendChild(timeline_content);
$('timeline').setStyle({
width: 8 * loop_length + 'em'
});
}
On Mar 18, 7:18 pm, Gareth Evans [EMAIL PROTECTED] wrote:
What is in your create_year function?
On 3/19/07, andymadonna [EMAIL PROTECTED] wrote:
Thanks Tom,
I modified it to what you said. But now it doesn't create the
loader,
and I know its executing the create_year function because I put in
an
alert to test it but it doesn't perform anything past that.
Modified:
new Ajax.Request('timeline_backend.php', {
method: 'get',
parameters: {action: 'year', year: request_year},
onCreate: create_loader,
onFailure: function () {alert(Oops!);},
onSuccess: create_year
});
On Mar 18, 6:36 pm, Tom Gregory [EMAIL PROTECTED] wrote:
You are not passing function references to the callbacks as you
perhaps intend. You are instead passing the results of functions.
Modify these lines:
onCreate: create_loader, // No parenthesis
onFailure: function () {alert(Oops!);}, // anonymous function
onSuccess: create_year // Again, use a function reference, not a
function result
TAG
On Mar 18, 2007, at 4:32 PM, andymadonna wrote:
Hi, I'm new to using Prototype. I trying to use Ajax to make an
interactive timeline of the 60s, but my Ajax request keeps
failing.
I have it on my live site for testing: http
[Prototype-core] Re: Node Insertion Methods
Definitely aggreed. Could we go for somethign a bit more consistent in the naming though ? append = Insertion.Top prepend = Insertion.Bottom addBefore = Insertion.Before addAfter = Insertion.After Best, Tobie On Mar 20, 12:15 pm, Mislav Marohnić [EMAIL PROTECTED] wrote: On 3/20/07, Ken Snyder [EMAIL PROTECTED] wrote: insertAfter (complement of insertBefore) prependChild (complement of appendChild) addNodeBefore addNodeAfter I like these. I used similar ones for some time now as a part of an add-on script. I think these should be a part of the Insertion rewrite. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Node Insertion Methods
lol On Mar 20, 1:58 pm, Christophe Porteneuve [EMAIL PROTECTED] wrote: Hey, Tobie Langel a écrit : append = Insertion.Top prepend = Insertion.Bottom OK, but... the other way around! :-) -- Christophe Porteneuve aka TDD [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: documentation suggestion for $F()/Form.Element.getValue()
There are rumors of a probable deprecation of $F... So use $ (element).getValue() instead. -- tobie --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: setStyle() throwing errors in IE when object does not exist in DOM
That's one of the cool things about the upcoming new Element feature
btw.
It already extends the elements for you.
So you'll be able to do:
new Element('div').setStyle({height: '100px'});
well... or (in that particular case):
new Element('div', {style: 'height: 100px;'});
you can read more about it here: http://prototypejs.org/2007/5/12/dom-builder
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Prototype.insertScript? (with code)
Mislav, I think Sylvain is just using the iframe to get an onload event triggered. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Documentation Error: Position.withinIncludingScrolloffsets()
Ya, Mephisto doesn't handle clearing the cache of mixed-cased pages. It has to be done manually. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: next(Number) slowdown in Internet Explorer (6,7)
As a side note, the bigger the document you are working with is, the slower the methods will be - obviously! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Opera and Form.serialize
Are you using Prototype 1.5.1 ? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Event.element() oddity
event.currentTarget is the element the event was attached to (i.e.
it's equivalent to this).
event.target == event.srcElement is the element that triggered the
event.
So for example:
ul id=myUl
li id=myLiclick me/li
/ul
$('myUl').observe('click', callback);
If I now click on the click me text: event.target should be (if
following the specs) li#myLi and event.currentTarget should be
ul#myUl.
On Jun 13, 7:38 pm, Mislav Marohnić [EMAIL PROTECTED]
wrote:
Thanks for the report. This sounds serious enough to open up a ticket, can
you do that?
While we're at it, does anyone really know the difference between target
and currentTarget? Doesn't one of them correspond to what the this
keyword references when the event handler is executed?
On 6/13/07, jdalton [EMAIL PROTECTED] wrote:
Hi Guys,
I was using Event.element(event) in an image onload observer and I
noticed that in IE,
it would return the Image element while in FireFox it would return a
[object HTMLDocument].
I used the guts of the Event.element and changed it to $
(event.currentTarget || event.srcElement)
and that fixed it.
This is probably an edge case.
More info about event targets can be found here.
http://developer.mozilla.org/en/docs/DOM:event:Comparison_of_Event_Ta...
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: $ function
And for my solution, it is too ugly, I won't use it, just prove you can change the name and fix it. Ya, unfortunately, in the process you've also removed any event handler that could have been set on the element. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: $ function
outerHTML is proprietary... so we can't really say it misbehaves ;) On Jun 18, 6:23 am, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Tks, I quite do not understand outerHTML, oh this would remove all the event handlers, in opera only change name attribute won't remove the event handlers? I think so. IE, misbahaving make me confused on you, why does IE implement the DOM basic method like this, any reasonable reason? Thanks ;) On Jun 18, 6:07 pm, Tobie Langel [EMAIL PROTECTED] wrote: And for my solution, it is too ugly, I won't use it, just prove you can change the name and fix it. Ya, unfortunately, in the process you've also removed any event handler that could have been set on the element. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: $ function
As advised here: http://www.w3.org/TR/html401/types.html#type-name ID and NAME tokens must begin with a letter ([A-Za-z]) [...] Which clearly implies that ids cannot be number only. On Jun 24, 1:25 pm, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I'd like to add a bit of OT to the discussion, but relating to the $ function itself. Currently, $ wil not return an element, whose id is a number, whereas getElementById will. The fix, as you can imagine, is pretty simple. I myself just changed the following line: if (typeof element == 'string') to: if (typeof element == 'string' || typeof element == 'number') I don't know if this is the most optimized way though. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Inheritance: your thoughts?
I personally prefer the following syntax:
var Animal = new Class({
...
});
var Cat = new Class(Animal, {
...
});
Also, I think that this.sup or this.$super would be safer than using
this.parent, which, in the realm of DOM scripting might be used pretty
often inside classes already.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Inheritance: your thoughts?
Yes, keep it lower-case and add an s so it reads better :) Cow-Class extends Animal (and) includes Eatable, Breadable ... Remember that the idea is to distinguish them easily from instance methods, hence capitalizing or prepending a $ sign. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Inheritance: your thoughts?
still a no-go for me. Classnames are capitialized, methods and vars are lowercase. Its always been that way in all the common coding guidlines .. But if you insist, what about an underscore instead? In JS that's usually implies that the property/method should be considered as private, so I don't think it would be a good fit. I personally have no problem to remember that the interface is made out of three reserved names. Well... we're possibly talking about more than just three: ClassMethods, Include, Extend (?), Alias (?) Note that you need to distinguish initialize from the others as it's an instance methods. The others aren't. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Inheritance: your thoughts?
I question whether new Class makes sense as an equivalent to Class.create. The new keyword connotes an instance in JavaScript -- with its own scope and method chain. Not all things being *created* are instances. That's a very valid point. It's unfotunately impossible to make a constructor for constructors in JS. So Class isn't a constructor here. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Inheritance: your thoughts?
Subclassing:
var Cat = Class.extend(Animal, instanceMethods, classMethods)
This is much smarter than Animal.extend(...) because you may wish to have
a class method named extend on your classes.
Agreed. though I think the Class.create({Extend: Animal, ... })
syntax suggested earlier is interesting if we intend to go the magical
property way.
Other OO stuff:
Class.include(Animal, Enumerable)
Class.alias(Animal, ...)
How do you handle precedende handled between mixin and instance
methods ?
And the name of the superchaining method (by my order of preference):
1. sup
2. $super
3. $parent
fine by me.
I vote against:
- parent (naming collisions)
- base (ugh!)
- uber
In conclusion, my philosophy is:
- no magic properties except initialize
- keep the inheritance support code simple and short, otherwise it
makes no sense in having it
Well, I'm not convinced about that. A proper an easy way to include
mixins and aliases is simple to implement, clean and a pleasure to
use.
- leave room for users to make their own additions to the inheritance
support code
- no dollar-signs and underscores because they indicate bad design
(exceptions from this rule are $super/$parent)
how so ?
- don't try to make defining of classes look like you're writing Ruby,
it simply won't work.
This is some class definition in Ruby:
class Cat Animal
include Enumerable
alias :peach, :each
def say
meow!
end
def self.food
super + [birds, gold fishes]
end
end
You can't achieve this in JavaScript. Simply let it go.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Inheritance: your thoughts?
How do you handle precedende handledbetween mixin and instance methods ? Can you rephrase the question please? Sure (there was a handled too many in there): do instance method always have precende over mixins ones ? (from the API you suggest, I suppose mixins are included *after* class creation). Remember: mixins and aliases are not so frequent. I completely disagree. If you look at Prototype you can hardly say its the case. I don't knwo how other people code, but I've got mixins included in about every class I write. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Element.replace()... would be nice if it worked with elements as well as html...
that's planned. On Jun 27, 4:51 pm, jdalton [EMAIL PROTECTED] wrote: to get the replaced element i usually do: element = $(element); element.parentNode.insertBefore( newElement, element); return element.remove(); --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Inheritance: your thoughts?
Hi DK,
Well that's really exciting! And might allow us to have dynamic class
methods.
I'll have a better look at it as soon as possible - I'm in the middle
of a move right now so it's a bit cmplicated.
Thanks fro your report,
Tobie
On Jun 29, 4:54 am, DK [EMAIL PROTECTED] wrote:
On Jun 25, 1:07 pm, Tobie Langel [EMAIL PROTECTED] wrote:
It's unfotunately impossible to make a
constructor for constructors in JS. So Class isn't a constructor here.
Actually, it is possible. See the code below:
code
var Class = function(classDef) {
// this = function() { } // throws error - assigning to 'this' not
allowed (not to mention it would be very ugly)
var theConstructor = function() {
this.initialize.apply(this, arguments);
}
// add classDef to the definition of the class (add all elements
of classDef to 'this')
Object.extend(theConstructor.prototype, classDef);
// returning class object constructron, instead of Class object
constructor
return theConstructor;// * THE HACK *
};
// creating the Animal class - the Class object called Animal
var Animal = new Class({
initialize: function() {
document.write('I am the initializer of Animal objectbr /');
},
prop1: 'foo',
say: function() {
document.write('say(): I am the instance method of the Animal
classbr /');
}});
// Animal class - class methods (static methods)
Object.extend(Animal, {
say: function() {
document.write('say(): I am the class method of the Animal
classbr /
');
}
});
// creating the Animal object
var my_pet = new Animal();
Animal.say();
my_pet.say();
/code
The secret is the line marked as * HACK *.
I know, this hack isn't very pretty, but it works in all browsers, I
tested (FF 2.0.0.4, IE6, Opera9, Safari3beta3.0.2). I've checked on
Windows only. Ergo - it IS possible for constructor, to return the
constructor :-)
Full working
example:http://dawid.krysiak.net.pl/webdev/js/21.js.constructors.for.construc...
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Object doesn't support this property or method with Element.up method in IE 6/7
Please read our tutorial: http://prototypejs.org/learn/extensions
That will explain it all.
Tobie
On Jul 2, 5:48 pm, si [EMAIL PROTECTED] wrote:
html
head
script type=text/javascript src=js/prototype.js/script
script
function foo(o){
alert(o.up('div').getAttribute('id'));
}
function bar(){
alert($('h2').up('div').getAttribute('id'));
}
/script
/head
body
div id=div1
a id=h1 href=# onclick=foo(this); return false;foo/a
a id=h2 href=# onclick=bar(this); return false;bar/a
/div
/body
/html
this code got error Object doesn't support this property or method
when click into foo link in IE 6/7. with FF/Opera both links work
properly.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Number.prototype - my proposal
Hi Andi,
You can open a ticket for this, but it'll need tests.
I'd favor a more concise notation:
Number.prototype.setInRange = function(from, to) {
return Math.min(Math.max(from, this), to);
};
and I'm not really sure bout the use of that method not the api.
For some reason, I think it should be tied to $R more closely.
Regards,
Tobie
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: String.strip enhancement
Jean-Philippe, Thanks for the link to Steven's blog. It's great and full of very insightful research. I'll be sure to check it out and improve our regexp where necessary. Regards, Tobie On Jul 8, 3:49 pm, Mislav Marohnić [EMAIL PROTECTED] wrote: Moal- Sorry, but if you're posting a patch that changes the implementation but keeps everything the same, you'll have to provide benchmarks. This isn't like a bugfix or a new feature - it's supposed to be speed optimization, so we need to see it for real. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Prototype and JavaScript 1.6 Array methods
Hi Jeff, That was in the works for a while. Your post just triggered a commit (http://dev.rubyonrails.org/ changeset/7170). Check SVN for the latest implementation. Hope this helps, Tobie On Jul 9, 3:04 pm, Jeff Watkins [EMAIL PROTECTED] wrote: Howdy, I'm investigating switching the online Apple Store from dojo to prototype (we're going to have to make big changes anyway if we're to track dojo's development from 0.4 to 0.9), however we've been making extensive use of the JavaScript 1.6 methods on Array (indexOf, map, forEach). I noticed in my initial testing that prototype (v1.5.1.1) stomps on the browser native versions of these methods. This doesn't seem like an ideal situation, as browsers are implementing these methods in compiled code. So the native version seems like it would be considerably faster. There's an open ticket for changes to make prototype compatible with JavaScript 1.6 (http://dev.rubyonrails.org/ticket/6650), any word on when this will be appearing in a release? -jeff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Assigning an unique ID
Pretty funny I actually ended up needing this very feature two days later... Anyway, working on a patch for it. Jeff, Ryan: could you give me a use case for the scoped prefixes ? My intial thought is to think they're overkill / too specific... but I don't mind being prooved wrong. I'm also concerned about naming the method adequately. Sam suggested Element#denominate which looks nicer than (generate|assign)Id but which I fear could be confused with setting the name attribute. The only other option I came up with is Element#identify. Thoughts on this issue ? Also, I'm wondering whether the method should return the element - for chaining purposes and to follow the general pattern of the other DOM methods - or the generated id itself, which IMHO would proove more useful here. Again, what are your thoughts ? Thanks for your valuable input, Tobie On Jul 14, 2:32 pm, Tobie Langel [EMAIL PROTECTED] wrote: Hi, I'm failing to see what advantage it has over directly storing a reference to the element like so: this.myElement = $(e); ... var e = this.myElement; Regards, Tobie --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Assigning an unique ID
Sorry for the triple posts, as you may have noticed, Google Groups went really crazy today, and I really thought my messages just weren't going through. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: A Lightweight Set
Or said another way, I can't store keys, values, map, find, etc in a
Hash (unless I'm missing something clever).
Yes you can... but they override the existing methods.
So for example: $H({map: 2}) works as expected except you won't be
able to use map or any method that relies on it anylonger.
Regards,
Tobie
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Event.observe should fix this problem in attachEvent
Have a look at the event branch for this.
On Jul 21, 11:57 pm, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
You must know the attachEvent can only put a function to be a
element's event handler, andd in that function this should be the
element itself, but the internet explorer linked it with window
object, and Event.observe doesn't fix this bug, same as $ input's name
bug, I think the Prototype library should fix it, my modification:
.
_observeAndCache: function(element, name, observer, useCapture) {
if (!this.observers) this.observers = [];
if (element.addEventListener) {
this.observers.push([element, name, observer, useCapture]);
element.addEventListener(name, observer, useCapture);
} else if (element.attachEvent) {
var f=function(){observer.call(element,window.event)};// this line I
add
this.observers.push([element, name, f, useCapture]);
element.attachEvent('on' + name, f);
}
},
.
use closure to fix this bug, I think this should be added into
Prototype, any ideas?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Event.observe should fix this problem in attachEvent
Sorry, here's the link for it:
http://dev.rubyonrails.org/browser/spinoffs/prototype/branches/event
On Jul 22, 12:30 am, Tobie Langel [EMAIL PROTECTED] wrote:
Have a look at the event branch for this.
On Jul 21, 11:57 pm, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
You must know the attachEvent can only put a function to be a
element's event handler, andd in that function this should be the
element itself, but the internet explorer linked it with window
object, and Event.observe doesn't fix this bug, same as $ input's name
bug, I think the Prototype library should fix it, my modification:
.
_observeAndCache: function(element, name, observer, useCapture) {
if (!this.observers) this.observers = [];
if (element.addEventListener) {
this.observers.push([element, name, observer, useCapture]);
element.addEventListener(name, observer, useCapture);
} else if (element.attachEvent) {
var f=function(){observer.call(element,window.event)};// this line I
add
this.observers.push([element, name, f, useCapture]);
element.attachEvent('on' + name, f);
}
},
.
use closure to fix this bug, I think this should be added into
Prototype, any ideas?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: newgrounds.com is now using Prototype and Scripty (NT)
Mislav, man, are you in a bad mood or something !? ;) John-David probably just suggested we should add it to the real-world page. Best, Tobie On Jul 25, 3:37 pm, Mislav Marohnić [EMAIL PROTECTED] wrote: You already know that this is a list for core discussion only. The news is cool, but it's more suited for Spinoffs list. Keep this in mind for the future, thanks! On 7/25/07, jdalton [EMAIL PROTECTED] wrote: subject says it all. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Suggestion: getElementsByClassName wrapper for firefox 3.0
I'm not saying we should do that, but can't we just wrap it HTMLElement.prototype too ? Tobie On Aug 24, 6:49 am, Mislav Marohnić [EMAIL PROTECTED] wrote: On 8/24/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: ... this difference may cause some bugs, so I suggest a small wrapper for getElementsByClassName in firefox3.0 This is just a wrapper for document.gEBCN, but don't forget that the method itself is available on every node in the DOM. We can't wrap them all, therefore we mustn't wrap the document method either. I suggest leaving everything as-is and simply mixing Enumerable methods in NodeList.prototype (if it doesn't already inherit them from Array). And as for the dynamic nature of the nodeList, I wouldn't worry too much; most users use the collection immediately after the gEBCN call. If that is not the case, the user is always free to wrap the method call in $A(). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: iterable/$A
Can we have benchmarks ? On Sep 1, 7:32 pm, Robert Katić [EMAIL PROTECTED] wrote: I have another question about $A and similar. Why you prefer do this var results = []; for (var i = 0, length = iterable.length; i length; i++) results.push(iterable[i]); instead of var length = iterable.length, results = new Array(length); for (var i = 0; i length; i++) results[i] = iterable[i]; It's more faster! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: iterable/$A
You're getting conflicting results there with an array of length == 10. Any idea why that is ? On Sep 2, 5:58 am, Robert Katić [EMAIL PROTECTED] wrote: In Opera I was able to perform similar timing with much more repetitions. Conclusion: 'init' function is double faster then 'push' function On Sep 2, 5:16 am, Robert Katić [EMAIL PROTECTED] wrote: I wrote small profilehttp://pastie.textmate.org/93190thatI paste on firebug. This is results on my laptop: Size: 100 Times: 1 push: 4672ms init: 2922ms Size: 10 Times: 1 push: 266ms init: 594ms Size: 4 Times: 1 push: 141ms init: 79ms On Sep 2, 4:31 am, Tobie Langel [EMAIL PROTECTED] wrote: Can we have benchmarks ? On Sep 1, 7:32 pm, Robert Katić [EMAIL PROTECTED] wrote: I have another question about $A and similar. Why you prefer do this var results = []; for (var i = 0, length = iterable.length; i length; i++) results.push(iterable[i]); instead of var length = iterable.length, results = new Array(length); for (var i = 0; i length; i++) results[i] = iterable[i]; It's more faster! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Indiscriminate use of breaking into words function $w()
FYI, some rough benchmarking in Safari using the benchmarking function
of unit tests:
benchmark(function(){
var colors = $('blue red green violet');
}, 1)
benchmark(function(){
var colors = ['blue', 'red', 'green', 'violet'];
}, 1)
Info: Operation finished 1 iterations in 4.246s
Info: Operation finished 1 iterations in 3.179s
So that's clearly not somewhere we should sacrifice readability for
speed.
Regards,
Tobie
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Ajax.Request.getStatus() new in 1.6
Hi Ken,
I didn't push the getStatus method further than that because there are
some issues with the file protocol in Safari (status is always equal
to 0 in that case if I remember well).
Proper support for the file protocol is something I'd like to have for
1.6 final.
It implies rewritting Ajax.getTransport to deal with IE7's poor xhr
object implementation.
If we want to properly handle network exceptions, we might need to
special case the getStatus method for requests using the file
protocol.
Regarding your suggestion for an onNetworkError callback, have you
considered throwing a NetworkError exception instead and catching it
via the onException callback ? I'm unsure which solution is better,
thoughts?
Regards,
Tobie
On Sep 7, 12:56 am, Ken Snyder [EMAIL PROTECTED] wrote:
I see that Sam added a new function to 1.6
svn--Ajax.Request.getStatus(). I'm curious because I just did some
research on status codes when the network connection is dropped and
wondered if any of you (especially Sam) have any additional insight.
To summarize the situation: when ajax calls encounter network errors,
FF2 throws an exception when reading transport.status; Opera 9 and
Safari 3 show transport.status = 0; IE6 and IE7 show transport.status =
12029 (or one of 5 other values).
I see the new getStatus() function now accounts for exceptions and
transport.status of 0 (O9, S3, FF2), and thus has an on0 callback. I
propose adding IE support and changing the callback name to
onNetworkError.
Here is the code (I will submit a patch):
Ajax.Request = {
...
success: function() {
var status = this.getStatus();
return status != 'NetworkError' status = 200 status 300;
},
getStatus: function() {
try {
var status = this.transport.status;
if ([0, 1223, 12002, 12029, 12030, 12031, 12152].include(status))
return 'NetworkError';
return status;
} catch(e) {
// allow callback functions to access properties without
generating an Exception
this.transport = {};
return 'NetworkError';
}
},
...
Network error scenarios:
FF - throws exception
IE6/7 - transport.status = 12029 (or other, see below)
S3 - transport.status = 0
O9 - transport.status = 0
IE status Error codes:
1223 : Client canceled request
12002: Server timeout
12029: Dropped connection
12030: Dropped connection
12031: Dropped connection
12152: Connection closed by server
Also of note is that FF 1.x returns a status of 200 on network errors
(no Exception), so the developer is left to see that the response is
empty to know of a failure.
references:http://dev.rubyonrails.org/changeset/7265http://developer.yahoo.com/yui/docs/connection.js.htmlhttp://www.thescripts.com/forum/thread573352.htmlhttp://trac.dojotoolkit.org/ticket/2418
- Ken Snyder
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Ajax.Request.getStatus() new in 1.6
So Tobie, how would you use the file protocol for an ajax request? It's mainly a backwards compatibility issue (plus it can be useful for testing purposes). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: JSON conversion isn't adequate
Hi,
Regarding your first and 3rd point, Prototype's JSON implementation is
based on RFC 4627 (http://www.ietf.org/rfc/rfc4627.txt?number=4627)
and maps Douglas Crockford's JS implementation (http://json.org/
json.js).
JSON is a language agnostic data exchange format which happens to be
easily evaluated in JS, there's absolutely no guarantee that
converting an object to JSON and evalutating it will yield back the
original object.You can read more about JSON here: http://json.org/
Regarding your 2nd point, Prototype is built so that you can implement
you're own Element#toJSON method depending on your own needs, see our
tutorial for more details: http://prototypejs.org/learn/json.
As this is not part of the specs and rather application specific, it
will stay like that too.
Hope this helps... and happy prototyping!
Tobie
On Sep 26, 12:20 am, Andrew Red [EMAIL PROTECTED] wrote:
To explain the subject line, I believe, the concept of JSON strings
should be described by the following formula:
eval(obj.toJSON()) - obj,
i.e. toJSON methods should return such a string from an object that if
evaluated, the result to be identical to that original object.
I believe, this formula should be tested by unit tests everywhere the
toJSON method is implemented.
And this concept is many times violated in Prototype. Examples:
1. Date#toJSON returns a string, if evaluated, it won't become that
same date again:
I'd like to note that this unit test passes in IE and FF:
testDate: function() {with(this) {
var date = new Date();
assert((eval('new Date(' + (date - 0) + ')') - 0) == (date -
0));
}},
I'd like to propose this method instead of the current one:
Date#toJSON = function() {
return '(new Date(' + (this - 0) + '))';
};
2. Also, Object.toJSON returns undefined if the argument is Element.
However, it might return a script that re-creates the structure of
their childern.(Like, using your ingenious DOM Bulider.)
3. Number.NaN is not null, it's Number.NaN. The string 'Number.NaN'
evaluates to this type and instance of JS object. 'null' evaluates to
null instead, it also loses the original type of the Number object.
Would you see my point?
Thank you!
Best regards,
Andrew Revinsky
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: JSON conversion isn't adequate
Also consider that JSON is not eval'ed unless the regex detects that there are no illegal tokens such as function calls that would open up a script to hacking That's only true if you've passed true to String#evalJSON's sanitize argument - see http://prototypejs.org/api/string/evalJSON for more details. Regards, Tobie --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: String#times performance pit in IE
Brilliant Martin!
as usual...!
Martin Ström wrote:
Try benchmarking this solution as well, it doesn't even use an for
loop which could make it even a bit faster:
String.prototype.times3 = function(count) {
return new Array(count + 1).join(this);
}
Hej
Martin
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Why PeriodicalUpdater doesn't work on Internet Explorer?
Hi, You'll get an answer much faster on the prototype user mailing list: http://groups-beta.google.com/group/rubyonrails-spinoffs Best, Tobie --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: DOMContentLoaded bug?
yup, we're going to correct this asap. Regards, Tobie On Sep 28, 3:49 pm, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I noticed that when using the DOMContentLoaded functionality of the new beta in IE, the browser will receive 404 calls (test it using filder). I believe the error is from this line (4014) in the latest beta (1.6) src='://javascript:void(0)'\/script); It should read: src='javascript:void(0)'\/script); Anyone else notice this? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: *Bug* - transport.responseJSON doesn't work with konqueror
Hi Luke,
Thanks for the info.
Mind opening a bug report for it ? That would be really helpful.
Have you run the test suite on Konqueror, any ajax related tests
failing ?
I'm suspecting it might be an issue with the content headers, could
you please let me know what you get for the following:
t.getHeader('Content-type')
Thanks,
Tobie
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Getting patches reviewed and applied
I feel like we're turning the corner there, though; we should probably start following the Report 12 process for Prototype. What does the rest of Core think? +1 ;) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: `new Element' does not take care to properly set up event attributes in IE
Hey Viktor,
This syntax is just not supported at the moment.
Use:
new Element('div').observe('click', callback);
instead.
Regards,
Tobie
On Oct 19, 2:37 pm, Viktor Kojouharov [EMAIL PROTECTED] wrote:
This is a really troublesome bug, which is exhibited in IE browsers.
Consider this code:
new Element('div', {onclick: 'alert(this)'});
In every other browser, this will produce a div, that, when clicked,
will alert. In IE, on* events are not registered, since internally
prototype uses setAttribute. setAttribute cannot set these. The only
way such attributes can be registered is in the createElement method
itself. For this reason, I've written a drop-in replacement for 'new
Element' which fixes this issue. I seriously urge you to fix this
issue (by either using the code below, or using your own methods),
otherwise `new Element' will not create elements that are identical
throughout all browsers.
That being said, this is my drop-in replacement:
(function() {
var element = this.Element;
this.Element = function(tagName, attributes) {
attributes = attributes || { };
tagName = tagName.toLowerCase();
var cache = Element.cache;
if (Prototype.Browser.IE) {
var conflicts = $H(attributes).grep(/(?:name|on\w+)/);
if (conflicts.length) {
var attributeString = '';
conflicts.each(function (tuple) {
delete attributes[tuple[0]];
attributeString += tuple[0] + '=' + tuple[1] + '';
});
tagName = '' + tagName + ' ' + attributeString + '';
return
Element.writeAttribute(document.createElement(tagName), attributes);
}
}
if (!cache[tagName]) cache[tagName] =
Element.extend(document.createElement(tagName));
return Element.writeAttribute(cache[tagName].cloneNode(false),
attributes);
};
Object.extend(this.Element, element || { });
}).call(window);
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Implementing Cross site Ajax support for prototype
Hi, What would be great would be to include writing capacities similar to what Google came up with. I have no idea how complex that is to set up - probably very - nor how their code is licensed. Regards, Tobie On Oct 21, 3:10 pm, Thierry [EMAIL PROTECTED] wrote: I am looking for cross site ajax support for prototype. Currently this does not seem to be supported. I think I will rewrite the code of other libraries to be useful for prototype. The best functionality out there, which i found so far, are:http://trainofthoughts.org/blog/2007/04/12/jquery-plugin-xsajax/http://trainofthoughts.org/repo/export/jquery/jquery.xsajax.js http://cows-ajax.sourceforge.net/index.php Suggestions and help would be appreciated off course :) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Implementing Cross site Ajax support for prototype
http://ajaxian.com/archives/google-launches-javascript-api-that-allows-you-to-write-back On Oct 21, 4:03 pm, Thierry [EMAIL PROTECTED] wrote: What did google come up with? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Event.extend not a function in firefox
Fixed in http://dev.rubyonrails.org/changeset/7986 cheers, Tobie On Oct 19, 5:11 pm, kangax [EMAIL PROTECTED] wrote: Sam, I think this issue is well documentedhttp://dev.rubyonrails.org/ticket/9421 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: a few more additions to Element._attributeTranslations
Hi Viktor,
Could you possibly open a ticket, or better yet, write a patch with
corresponding tests?
Thanks,
Tobie
On Oct 25, 11:12 am, Viktor Kojouharov [EMAIL PROTECTED] wrote:
Currently, cellspacing|padding cannot be set using writeAttribute (or
new Element) in Internet explorer, since it expects cellSpacing|
Padding instead. I suggest the following be added to
Element._attributeTranslations.write (and maybe .read too). This is
what I'm currently using until the issue is resolved:
if (Prototype.Browser.IE) {
Object.extend(Element._attributeTranslations.write.names, {
'cellspacing': 'cellSpacing',
'cellpadding': 'cellPadding'
});}
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Ticket 10030 - is Ajax.Request.success() broken?
Hi Ken, Thanks for the extended research. That's really helpful! Could you please clarify what kind of errors FF is throwing ? Also, could you please kindly advise if Safari 2's behaviour is consistent with Safari 3 ? Thanks, Tobie On Nov 14, 12:27 am, Ken Snyder [EMAIL PROTECTED] wrote: Tobie Langel wrote: Some browsers - I can't remember witch - always return a status of 0 for the file: protocol, others don't return a value at all in that case, hence this hack. We're going to be doing more work on Ajax for 1.6.1, but I'm not even sure there is a real solution ot his issue. Regards, Tobie I think the trick here is to return a separate status code for files instead of zero. I believe it is possible to handle all situations. Here is the result of my research on status codes: Calling HTTP(S) ajax url Network error scenarios: FF2 - throws exception S3 - transport.status == 0 O9 - transport.status == 0 IE6/7 - transport.status == (one of the following) 1223 : Client canceled request 12002: Server timeout 12029: Dropped connection 12030: Dropped connection 12031: Dropped connection 12152: Connection closed by server Calling file-based ajax url Success: ALL BROWSERS - transport.status == 0 Failure: ALL BROWSERS - transport.status == 0 Note: for network errors on FF 1.x transport.status == 200 and no exception is thrown so the developer is left to see that the response is empty to know of a failure. I don't think there is a workaround. So how can we know the difference between a network error and a file-based url call?--Both url and location.protocol give clues. IMHO it is important that we properly route all these codes: file-based requests should always fire onSuccess (unless we can figure out how to detect a file-based failure) and any of the network error codes should throw onException. Right now, we get all sorts of kooky callbacks such as on0 and on12029. For more info and links to my sources, see the discussion from Sept:http://groups.google.com/group/prototype-core/browse_thread/thread/1e... - Ken Snyder --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: IE not updating div element working fine in FF
Hi,
Please use something like http://pastie.caboo.se/ to paste code as
it's just unreadable like that.
Also, please post assistance requests to the spinoffs mailing list
http://groups-beta.google.com/group/rubyonrails-spinoffs.
This list is for development purposes only.
Thanks!
Tobie
On Nov 14, 4:33 pm, kavan [EMAIL PROTECTED] wrote:
JSP file code snippet:
Code: ( html4strict )
1.
div id=adapterList style=display:none
2.
center
3.
h5 Adapter
Selection/h5
4.
/center
5.
h1
class='info'Click on the arrow to expand or collapse an Adapter's
Viewer./h1
6.
7.
c:forEach
var=adapterInfo items=${campaignManager.contentAdaptersInfo}
varStatus=status
8.
div
class=CollapsiblePanel id='c:out value=${adapterInfo.id}/'
9.
!-- button row --
10.
div
class=CollapsiblePanelTab title='click here to open catalog'
11.
a href =#
title='click here to open catalog' onclick=showCatalogDetail('c:out
value=${campaign.name}/','c:out value=${adapterInfo.name}/','c:out
value=${status.count}/','c:out value=$
{adapterInfo.id}/');h5c:out value=${adapterInfo.name}//h5/
a/div
12.
div
class=CollapsiblePanelContent id='adapterDetails-c:out value=$
{adapterInfo.id}/'
13.
/div
14.
/div
15.
script type=text/
javascript
16.
17.
CollapsiblePanel[c:out value=${status.count}/]
= new Spry.Widget.CollapsiblePanel('c:out value=${adapterInfo.id}/',
{contentIsOpen:false, enableAnimation:false});
18.
if(($('remoteCatalogList').options).length == 0)
19.
{
20.
Element.hide($('remoteCatalogList'));
21.
Element.hide($('catPriorityHead'));
22.
$('catalogInfo').innerHTML = 'Currently there
no adpter selected.Please click on edit button to select catalog';
23.
}
24.
Element.hide($('newCatalogUpButton'));
25.
Element.hide($('newCatalogDownButton'));
26.
/script
27.
/c:forEach
28.
/div
29.
30.
/form
31.
!-- end panel contents --
32.
33.
34.
/div
35.
/form
36.
!-- end tabs content --
37.
/div
38.
39.
!-- end tabbed content area *
--
40.
/div
41.
!-- end main body --
I am calling showCatalogDetail( ) function on mouse click.
Java script code for JS function
Code: ( javascript )
1.
function showCatalogDetail(name,adapterName,widgetId,adapte
rId) {
2.
3.
var dummy=new Date().getTime();
4.
var divName = 'adapterDetails-'+adapterId;
5.
new Ajax.Updater(divName, 'html:rewrite page=/do/AdminGUI/
getCatalogDetails/'+'?dummy='+dummy,
6.
{ method:'post', evalScripts: true, parameters:
{campaignName: name, adapterName:
adapterName,widgetId:widgetId,adapterId:adapterId } } ) ;
7.
8.
9.
}
here divName is id of div element which is there in above shown JSP.
The particular div element should get updated on the call of the above
written function.
The functionality is working perfectly in FF but not working IE7.
I am not getting any error in IE is not displaying the updated div
content.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Ticket 10030 - is Ajax.Request.success() broken?
Ken, sorry if my last comment sounded a bit harsh - really wasn't my intention. Thanks again for your work on this, it really, really helped. Best, Tobie On Nov 14, 7:22 pm, Tobie Langel [EMAIL PROTECTED] wrote: But what about http pages accessing files? I was under the impression that this is the prime testing situation. That's a violation of SOP. It's just not possible with Ajax. (Else, imagine how a website could discretely upload most of your hard- drive's content). One question: We want the file protocol to always trigger onSuccess, but what status code should it return? 200? I'm assuming we don't want files to trigger on0 The file: protocol doesn't have http headers (these are set by a webserver) so calling on0 (or on200) in that case just doesn't make any sense. Best, Tobie --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Update a DOM element with Javascript contents
Hi,
Please kindly post help requests to the spinoffs mailing list (http://
groups.google.com/group/rubyonrails-spinoffs).
Thanks!
Tobie
On Dec 1, 3:34 pm, mevryck [EMAIL PROTECTED] wrote:
Greetings
I have a huge Javascript with inclusion of external scripts and all. I
got this by doing a XSLT .
Now I have the contents in a Javascript variable, but I'm nto able to
update the element with the
below javscript contents.
But when viewed as a seperate HTML file with the below contents I'm
able to see the milonic menu.
Please help me with this regard.
div
script type=text/javascript language=javascript
src=milonic_src.js
!-- comment inserted for Internet Explorer --/
scriptscript type=text/javascript language=javascript
src=mmenudom.js
!-- comment inserted for Internet Explorer --/
scriptscript type=text/javascript language=javascript
_menuCloseDelay=500;
_menuOpenDelay=150;
_subOffsetTop=2;
_subOffsetLeft=-2;
with(mainStyle=new mm_style()){
bordercolor=#43BAF1;
borderstyle=solid;
borderwidth=1;
separatorcolor=#CCC;
separatorpadding=0;
separatorwidth=1;
fontfamily=Arial;
fontsize=11px;
fontstyle=normal;
fontweight=bold;
itemheight=18;
menubgcolor=;
offbgcolor=transparent;
offcolor=#66;
onbgcolor=transparent;
oncolor=#43BAF1;
pagebgcolor=transparent;
pagecolor=#FFF;
outfilter=fade(duration=0.2);
overfilter=Fade(duration=0.2);
rawcss=padding-left:13px;padding-right:
13px;
separatorPadding=0;
onsubimage=ni-on_downboxed.gif;
subimage=ni-off_downboxed.gif;
}
with(menuStyle=new mm_style()){
bordercolor=#CDCDCD;
borderwidth=1;
separatorcolor=#ccc;
separatorpadding=0;
fontfamily=Arial;
fontsize=11px;
fontstyle=normal;
fontweight=normal;
image=;
itemheight=18;
offbgcolor=#F7F7F7;
offcolor=#666;
onbgcolor=#43BAF1;
onbgimage=ni-bg_highlight_btn.gif;
oncolor=#fff;
pagebgcolor=#43BAF1;
pagebgimage=ni-bg_highlight_btn.gif;
pagecolor=#F7F7F7;
menubgcolor=#F7F7F7;
styleid=1;
outfilter=fade(duration=0.2);
overfilter=Fade(duration=0.2);
padding=2;
rawcss=padding-left:5px;padding-right:5px;;
subimage=ni-menu_arrow_off.gif;
onsubimage=ni-menu_arrow_on.gif;
subimagepadding=3;
}
with(milonic=new menuname(main)) {
alwaysvisible=1;
position='relative';
orientation='horizontal';
style=mainStyle;
overflow=scroll;
aI(showmenu=Export...;text=Export...;url=;);
}
with(milonic=new menuname(Export...)) {
top='offset=0';
left='offset=-1';
style=menuStyle;
overflow=scroll;
aI(showmenu=Export Page;text=Export Page;url=;);
aI(showmenu=Export Report;text=Export
Report;url=;);
aI(showmenu=My Presentations;text=My
Presentations;url=;);
}
with(milonic=new menuname(Export Page)) {
top='offset=0';
left='offset=-1';
style=menuStyle;
overflow=scroll;
aI(text=Microsoft
Excel;url=javascript:exportPage('xls',
'58ea5cc2eab33c5ea8e3b66545c2f0a0'););
aI(text=org PDF
format;url=javascript:exportPage('pdf','58ea5cc2eab33c5ea8e3b66545c2f0a0',
'9496551d86e583f1fbe3b66580a004a0'););
}
with(milonic=new menuname(Export Report)) {
top='offset=0';
left='offset=-1';
style=menuStyle;
overflow=scroll;
aI(text=Advisor
Viewer;url=javascript:exportReport('wsv',
'58ea5cc2eab33c5ea8e3b66545c2f0a0'););
}
with(milonic=new menuname(My Presentations)) {
top='offset=0';
[Prototype-core] Re: What does the frequency option actually does in the Autocompleter controll?
Hi SK, These questions are best asked on the spinoffs mailing list http://groups.google.com/group/rubyonrails-spinoffs; Regards, Tobie On Dec 21, 2:15 am, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi, Me again :) Can anyone tell me if this is real throttling? Does this controlls according to the speed the user enters the input or just give a frequency to the requests once the user started typing? Thanks, SK --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Is there an I18N support in prototype
Hi, There is no built-in support for I18N. However, implementing it in JavaScript is trivial. For a pointer on how to do this have a look at this article http://24ways.org/2007/javascript-internationalisation Best, Tobie On Dec 21, 2:00 am, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi, i am evaluating Prototype for commercial product at my company and would like to get more details regarding I18N support. Can anyone please show me the way? Thanks, SK --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Bad approach or Bug?
Hi Tom, Thanks for your patch. Would you mind opening a ticket with it against the latest trunk ? That would be much appreciated. Also could you explain the reasoning behind the changes ? Just so I grasp it! Thanks! Tobie --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: EditInPlace Prototype ID issue
Hi, As per HTML specs, ids *must* be unique on a given page (http:// www.w3.org/TR/html4/struct/global.html#h-7.5.2). Please note that the core mailing list is reserved for discussing development issues. If you need help or have questions, pleade use the spinoffs mailing list instead (http://groups.google.com/group/rubyonrails-spinoffs). Thanks and happy new year! Tobie On Jan 1, 11:50 pm, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi, is there an issue with PrototypeJS? I am using the latest version of EditInPlace and PrototypeJS 1.6 and I cant use the same ID for more than one element when i want to do inline editing. is this a known issue or has this got to do with something else? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: A question regarding changeset 8548.
Hi,
Well, that's where it originally was, so I didn't move it.
However, I'm working on ditching document.write in IE in favor of
element.doScroll('left') and that changest includes toggling the
document.loaded property before fireing the dom:loaded event.
I'm just having issues making our tests pass (there's cases where
window.onload fires before dom:loaded).
Best,
Tobie
On Jan 4, 12:30 pm, Mislav Marohnić [EMAIL PROTECTED]
wrote:
On Jan 4, 2008 12:17 PM, Richard Quadling [EMAIL PROTECTED] wrote:
As it stands, the dom isn't loaded until all the observers have
finished executing (I think).
I may have got some or all of this wrong.
I agree with you, Richard. It comes as a surprise to me also. I don't see
why the statement shouldn't be moved to the top, instead of the bottom.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Development Roadmap
Yup, That's awsome. Very insightful remarks, too. How does the performance feel ? Best, Tobie On Jan 7, 11:26 pm, Michael Schuerig [EMAIL PROTECTED] wrote: On Monday 07 January 2008, Ken Snyder wrote: - Expand Prototype custom events to fire callbacks for Element methods such as update, setStyle, remove, replace, insert, wrap, writeAttribute, addClassName, removeClassName, scrollTo, etc. I've written about notifications for DOM changes just today. Have a look: http://schuerig.de/michael/blog/index.php/2008/01/07/dom-change-notif... Michael -- Michael Schuerig mailto:[EMAIL PROTECTED]://www.schuerig.de/michael/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Potential change to Enumerable Hash
Hi Mitchell,
There's a couple of patches about this on trac already and it's
certainly worth discussing.
Originally these iterators are mapped on ruby ones, so it's worth
checking those out, and especially the changes coming up in ruby 1.9.
Best,
Tobie
On Jan 18, 12:11 am, mostly_magic [EMAIL PROTECTED] wrote:
Hey all,
I was playing with Hash recently and I came across some unexpected
behavior. When I called certain methods inherited from Enumerable
(findAll and partition among others) they returned results as arrays
instead of hashes. After looking through the code I understand the
cause of this, but I wonder if this should be the result. I created a
solution for this and wanted your thoughts and feedback. I've placed
the (abbreviated) code below:
var Enumerable = {
// This function has been added to provide the default return type
_createNew: function() { return []; },
findAll: function(iterator, context) {
iterator = iterator.bind(context);
// Retrieve the enumerable type
var results = this._createNew();
this.each(function(value, index) {
if (iterator(value, index))
results.push(value);
});
return results;
}
};
var Hash = Class.create(Enumerable, (function() {
return {
// Override the default to return a hash object.
_createNew: function() { return $H({}); },
// Provide an implementation for Array.push to store items.
push: function(value) {
this.set(value.key, value.value);
}
}
})());
There's still some grey areas about this, such as whether the slices
in eachSlice should be hashes and whether collect and grep should
associate the new values with the keys. I also haven't given a lot of
thought about how to maintain backwards compatibility. I wanted to
put it out there, though, to see what others think of it.
Cheers,
Mitchell Cowie
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Potential change to Enumerable Hash
I had noticed ticket #10663 (http://dev.rubyonrails.org/ticket/10663)
prior to posting this. I dug further after your comments and found
the patch you referred to (http://dev.rubyonrails.org/ticket/3592).
Ya, I wasn't fully aware of the ruby implementation when I made those
comments, so I might be disagreeing with some of what I wrote there
now (haven't checked).
My only comment on it would be that I chose to use push instead of
creating a new _add method (my first incarnation used this) to remove
the added processing of wrapping push (minimal, I know, but
still...).
The problem with adding a _createNew method and an _add or push method
is backwards compatibility, as it suddenly requires any class which
mixes in Enumerable to have these methods.
In any case, I'll make sure to dig further next time
before posting :-P.
np
Good point about mapping to Ruby. Perhaps the better solution would
be to provide functionality to easily convert the returned array back
into a hash.
Ruby doesn't have one of those afaik... and for good reasons. An
Enum#toHash method would sport a totally confusing API.
If you want it to work for enumerables, you'd need something like
this:
[['foo', 1], ['bar', 2]].toHash();
// - {foo: 1, bar: 2}
However, someone using toHash on a regular array, would expect the
following:
[1, 2, 3].toHash()
// - {'0': 1, '1': 2, '2': 3}
Imagine the confusion ahead...
Converting back the result of an enumerable to a hash is pretty simple
though:
...inject($H(), function(hash, pair) {
hash.set(pair[0], pair[1]); // or hash.apply(hash, pair);
return hash;
})
Best,
Tobie
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: methodized String functions
Then the question is, why do it for the Math functions but not the String functions? AFAIK, because the Math ones were needed for script.aculo.us code. Best, Tobie --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Selector.assertions.attr() and Element.readAttribute() - null
Can anyone confirm this? Should I submit a patch to trac? Please do! Best, Tobie --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Element.update on images. Bug or Feature Request?
Seriously, what's wrong with:
$('myEmoticon').writeAttribute({ src: 'images/smiling.jpg', alt: I'm
smiling! });
On Jan 26, 12:20 pm, Gonzalo Ruiz de Villa
[EMAIL PROTECTED] wrote:
Being careful accesibility, you should't suggest update() images like
that. If you change the src on an image, probably, and before styles,
you should have to change the alternative description. Because of
this, that update() method on images becomes insufficient. To be
nice with everyone, you can complete the suggested wrapper:
Element.addMethods('IMG', {
setAlt: function(element, alt) {
return $(element).writeAttribute('alt', alt);
}
})
$('myEmoticon').setSrc('images/smiling.jpg').setAlt(I'm smiling! :)
);
$('myEmoticon).setSrc('images/sad.jpg').setAlt(I'm sad! :( );
Regards,
Gonzalo
On 26 ene, 08:12, kangax [EMAIL PROTECTED] wrote: As Nicolás pointed out,
making Element.update change src attribute of
an image is NOT the way to go. Not only is it unintuitive but
redefining existent methods could lead to some serious bugs in future
maintenance/upgrades, etc. If you feel like Element.writeAttribute is
too verbose, I would suggest to define a simple wrapper:
Element.addMethods('IMG', {
setSrc: function(element, src) {
return $(element).writeAttribute('src', src);
}
})
...
$('myImage').setSrc('images/blah.jpg');
Best,
kangax
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Element.update on images. Bug or Feature Request?
I haven't looked deep enough into the code that Prototype executes to extend even those empty elements, but maybe ignoring those elements in that code will shave some time off of Prototype's initialization. Prototype initialization certainly isn't a bottle-neck. Probably 2-3 ms at most. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: How to get the request parameters from the response?
Hi, The request and transport objects are available as a property of the Ajax.Response object (the one passed to your parameters), as described here: http://prototypejs.org/api/ajax/response Best, Tobie On Jan 26, 9:34 pm, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi, I am using ajax.request(...) and would like in the onSuccess function to do some logic based on the parameters I sent in the request (think about a field name to be validated and I would like th update it's div using name convention). How can i have acess to it? In dojo you could add it to the request as an additional option: FieldName: field.name, and then get it using: options.fieldName Is there anything in prototype? Cheers, Shy. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: How to get the request parameters from the response?
Try:
new Ajax.Request(url, {
parameters: { foo: 'hello world' },
onComplete: function(t) {
alert(t.request.parameters.foo);
}
});
Best,
Tobie
On Jan 27, 11:12 pm, Gareth Evans [EMAIL PROTECTED] wrote:
Someone correct me if i'm wrong but the parameters/postbody you sent do not
automatically come back in your response/transport.
What I do, is anything I *need* to come back, eg an element id etc, I pass
in the querystring instead of the form (append to the URL).
The reason i do this, (i use asp.net serverside) is then I take the
request.querystring collection and issue a few replaces on the string
representation of it, converting it to json.
(also set header)
replace with ,
replace = with :
append a { on the start
append a } on the end
Then, when my transport is received by the client I can use responseJSON to
access the values I sent originally.
I use this pattern because the request is asynchronous and it looses
context.
As an afterthought, bind will work for an anonymous function, you could bind
it to some custom object with the data you want...
On Jan 27, 2008 11:47 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Ok so I have the request object. Sorry for the ignorance but how to I
get for example a parameter called fieldName I sent.
request.getParameter(fieldName) Will this work?
Shy.
On 27 ינואר, 03:52, Tobie Langel [EMAIL PROTECTED] wrote:
Hi,
The request and transport objects are available as a property of the
Ajax.Response object (the one passed to your parameters), as described
here:http://prototypejs.org/api/ajax/response
Best,
Tobie
On Jan 26, 9:34 pm, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hi,
I am using ajax.request(...) and would like in the onSuccess function
to do some logic based on the parameters I sent in the request (think
about a field name to be validated and I would like th update it's div
using name convention).
How can i have acess to it?
In dojo you could add it to the request as an additional option:
FieldName: field.name,
and then get it using:
options.fieldName
Is there anything in prototype?
Cheers,
Shy.-הסתר טקסט מצוטט-
-הראה טקסט מצוטט-
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Staring noconflict support - putting $() into a namespace [reposted from Spinoffs group]
Just to clarify, I suggested reposting the thread here, not providing a noConflict mode ;) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Staring noconflict support - putting $() into a namespace [reposted from Spinoffs group]
Well, there's more elegant ways to handle that than converting each and every call to a global than the one you're using. Using a closure could be a solution. Dean's got an interesting system in base2 for that kind of stuff: http://base2.googlecode.com/svn/trunk/src/base2/Package.js Personally, I'm not too fond of namespacing, as imho it just encourages poor coding practices. There's technically no reason afaik (except laziness maybe) to include another framework on top of Prototype (and yes, I know Digg does so - shame on them !). But I'm ready to hear any sound argument in that direction. Best, Tobie --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Staring noconflict support - putting $() into a namespace [reposted from Spinoffs group]
Sure. Handling namespacing inside of the global scope is one issue, and it's pretty simple to deal with... but what about extended prototypes? How am I supposed to know that some other script / lib / framework, hasn't extended Function.prototype.bind with something else, something that would *totally* break Prototype ? What's the point in handling the global scope issue if we're not handling that issue too ? And we all know what that implies. Best, Tobie Dr Nic wrote: Lack of namespace management is thing to be fixed, not protected as sacred. Whether its unittest or a widget that needs to coshare JavaScript-land with other widgets built ontop of other frameworks, I think it should be possible, not impossible. Nic On Jan 31, 2:50 am, Nick Stakenburg [EMAIL PROTECTED] wrote: On 30 jan, 17:22, Dr Nic [EMAIL PROTECTED] wrote: Alternately, can I have permission to make unittest independent of prototype? :P I did look at it _very briefly_ and realised that I just needed to cleanup the use of $. If multi framework unittests is what you want, you should have a look at Ext.js adapters. Writing something similar for your unittests is easier then getting every framework to implement noConflict. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Prototype - version 1.6.0 - issue on Websphere Application Server 6.1
Hi, This seems like a server specific issue. You'd probably get better help on their own mailing lists / forum, etc. Make sure you grab Prototype 1.6.0.2, though as it fixes an (unrelated) bug in PeriodicalExecuter. Good luck, Tobie On Feb 1, 7:20 pm, Rajiv [EMAIL PROTECTED] wrote: I am using the Prototype framework version 1.6.0 in my application and specifically the 'PeriodicalExecuter' object to refresh the data in a span element at a given frequency. This functionality works perfectly on Tomcat 5.5 on Windows XP, but when i deployed the application EAR on Websphere Application Server 6.1 on AIX (Unix), the 'PeriodicalUpdater' stops working. Is this an issue encountered in the past and also does it have to with a setting that needs to be modified/ turned on WAS 6.1 to enable Prototype (or probably any AJAX request) to work. Any pointers in this regard will be a big help. Thanks, Rajiv Sethumadhavan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Object.isDate
Hey Jeff,
Good point.
Dean uses the following:
!!object.getTimezoneOffset;
Which seems like a reasonable enough choice, and avoids the issue you
mentioned.
Best,
Tobie
P.S.: I'm not really sure Prototype needs this in core, though.
On Feb 2, 5:02 am, Jeff Watkins [EMAIL PROTECTED] wrote:
because if you are testing a Date from another document its
constructor won't match your document's Date constructor.
On 1 Feb, 2008, at 4:20 PM, kangax wrote:
Why not simply:
Object.isDate = function(o) {
return !!(o o.constructor == Date);
}
- kangax
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Adding Prototype.Revision
Artemy,
1.6.0 1.6.0_rc1
false
Best,
Tobie
On Feb 3, 8:22 pm, artemy tregoubenko [EMAIL PROTECTED]
wrote:
I previously had success at comparing version numbers as string like that:
'1.6' '1.6.0.2'
true
'1.5.0.1' '1.6'
true
Thus I am surprised that you parse these strings
On Sun, 03 Feb 2008 21:39:56 +0300, Nick Stakenburg [EMAIL PROTECTED] wrote:
I think we should have both version string and SVN revision from which it
was built.
Also, Prototype versions could simply be compared like integers in this
fashion:
function vnum(vstring) { return parseInt(vstring.replace(/\./g, '') +
'0'.times(4-(vstring.length/2).ceil())) }
vnum('1.6') //- 1600
vnum('1.6.0.2') //- 1602
That is because none of the version fragments will ever be bigger than 9.
That's nice. I went into more trouble to make so Scriptaculous'
version could be checked, it sometimes has '_pre1' or '_beta2' in it's
version string. But I see a little more regex could do the same there,
good idea.
Even though it could be that simple, a build number will make this
more user friendly. You could then simply do:
Prototype.Build Prototype.Build = 1602
--
arty (http://arty.name)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Cross-browser Event.simulateMouse [bump via kangax]
The reason I'm not too keen on adding this two unit tests is two- folds: First I think it belongs in Prototype core, secondly, I'm in the process of rewriting a good deal of unit_tests so I really don't think it's a good time to add features to it. I'd rather strengthen it as much as possible beforehand. Best, Tobie On Feb 4, 1:19 pm, Nic Williams [EMAIL PROTECTED] wrote: Heh. If I am, then I'll be that person some time in the future :) I'm trying to work on unittest; which just happens to co-share a repo + mailing list with prototype :) On 2/4/08, Nick Stakenburg [EMAIL PROTECTED] wrote: Yes there might be a better/more complete possibility, and someone might do it in the future I think I'd rather see an incremental fix now; AND wait for someone to write an even better version later. Perhaps once this patch is in, someone else will look at it You could be that someone ;) -- Dr Nic Williamshttp://drnicacademy.com- Ruby/Rails training/dev around the worldhttp://drnicwilliams.com- Ruby/Rails/Javascript/Web2.0 (skype) nicwilliams (p) +61 412 002 126 / +61 7 3113 3033 (mail) PO Box 583 Ashgrove 4060 QLD Aus --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Cross-browser Event.simulateMouse [bump via kangax]
I don't have a timeframe for this unfortunately. And yes, the API will change quite a bit as we'd like to map it more closely to ruby's Test::Unit implementation. I'm not far enough into refactoring to know how backward-compatible this rewrite will be. Will make sure to let you know as soon as I have more info. Best, Tobie On Feb 4, 3:03 pm, Nic Williams [EMAIL PROTECTED] wrote: What's your timeframe for finishing this? Will its API change much? I started doing screencasts of how to use unittest today for peepcode. If this patch is not useful, then it suggests the current Event.simulateMouse code should be removed as part of the refactoring. Force people to go looking for a tested, known working library to perform the simulations rather than attempt to use known non-working code? On 2/4/08, Tobie Langel [EMAIL PROTECTED] wrote: The reason I'm not too keen on adding this two unit tests is two- folds: First I think it belongs in Prototype core, secondly, I'm in the process of rewriting a good deal of unit_tests so I really don't think it's a good time to add features to it. I'd rather strengthen it as much as possible beforehand. Best, Tobie On Feb 4, 1:19 pm, Nic Williams [EMAIL PROTECTED] wrote: Heh. If I am, then I'll be that person some time in the future :) I'm trying to work on unittest; which just happens to co-share a repo + mailing list with prototype :) On 2/4/08, Nick Stakenburg [EMAIL PROTECTED] wrote: Yes there might be a better/more complete possibility, and someone might do it in the future I think I'd rather see an incremental fix now; AND wait for someone to write an even better version later. Perhaps once this patch is in, someone else will look at it You could be that someone ;) -- Dr Nic Williamshttp://drnicacademy.com-Ruby/Rails training/dev around the worldhttp://drnicwilliams.com-Ruby/Rails/Javascript/Web2.0 (skype) nicwilliams (p) +61 412 002 126 / +61 7 3113 3033 (mail) PO Box 583 Ashgrove 4060 QLD Aus -- Dr Nic Williamshttp://drnicacademy.com- Ruby/Rails training/dev around the worldhttp://drnicwilliams.com- Ruby/Rails/Javascript/Web2.0 (skype) nicwilliams (p) +61 412 002 126 / +61 7 3113 3033 (mail) PO Box 583 Ashgrove 4060 QLD Aus --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: readAttribute() differences IE and Firefox
Great jobs guys... unit tests would make it even better! Best, Tobie On Feb 13, 12:22 am, John-David Dalton [EMAIL PROTECTED] wrote: http://dev.rubyonrails.org/ticket/11092 updated the ticket with an alternative fix which works for everything except child elements with duplicate id's. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: unit test stalling: enumerable.html
Have you rebuilt Prototype ? Best, Tobie On Feb 13, 12:04 pm, Dr Nic [EMAIL PROTECTED] wrote: On trunk, on both firefox and safari, the testEachSlice method in enumerable.html is stalling (seemingly indefinitely). Is reproducible by anyone else? I ran it via rake test_units and by loading the html directly into browsers. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: unit test stalling: enumerable.html
afaik, rake test_units doesn't run rake dist before. Use rake test instead, which auto builds Prototype each time. Best, Tobie On Feb 13, 12:14 pm, Tobie Langel [EMAIL PROTECTED] wrote: Have you rebuilt Prototype ? Best, Tobie On Feb 13, 12:04 pm, Dr Nic [EMAIL PROTECTED] wrote: On trunk, on both firefox and safari, the testEachSlice method in enumerable.html is stalling (seemingly indefinitely). Is reproducible by anyone else? I ran it via rake test_units and by loading the html directly into browsers. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: readAttribute() differences IE and Firefox
1) yes, well, at least, adding the necessary code and maybe html. 2) make sure you build Prototype before running the tests (use rake dist or run the tests from rake using rake test which auto build Prototype). Currently all tests pass in all supported browsers except a coouple of known issues in Opera. Note that the ajax tests are emant to be run from rake. On Feb 13, 2:33 pm, John-David Dalton [EMAIL PROTECTED] wrote: A two parter: 1) Would that mean t modifying he dom.html unit test to test for this? 2) I ran the unit test with prototype 1.6.0.2 downloaded from prototypejs.org and in each browser diff tests fail. Does this mean that there are issues with the current code base that are still needing to be resolved? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Selector.findChildElements issue
Hi,
That is indeed a regression and we'll fix it.
However, I can't stop myself from wondering what kind of bizarre HTML
actually sports children for input tags ;)
Best,
Tobie
On Feb 15, 8:58 am, Andrés Robinet [EMAIL PROTECTED] wrote:
-Original Message-
From: Andrés Robinet [mailto:[EMAIL PROTECTED] On Behalf Of Andrés
Robinet
Sent: Friday, February 15, 2008 2:51 AM
To: 'prototype-core@googlegroups.com'
Subject: Selector.findChildElements issue
Hi All,
I found what appears to be a bug in Selector.findChildElements. I'm using
prototype 1.6.0.2 and this behavior was not present in version 1.6.0. I've
experienced this behavior on both IE 7 and FF 2 (didn't test other
browsers).
Calling element.descendants() on an input element will call
element.select('*') which in turn calls Selector.findChildElements(element,
'*'). This function returns undefined for inputs, but returns an iterable
object for other empty tags such as hr and br, which is very odd (it
should either return always undefined or always return an iterable -empty-
object, shouldn't it?).
I didn't go deeper into details about why and where the bug exactly is,
but I have this sample code as a proof of concept:
form action=whatever.php method=post enctype=application/x-www-
form-urlencoded
hr id=test-hr /
input id=test-input type=text value=whatever /
br id=test-br /
/form
script language=javascript type=text/javascript
//![CDATA[
document.observe('dom:loaded', function() {
// Test HR
var hrTest = $('test-hr')
var hrDesc = hrTest.descendants();
alert(typeof hrDesc);
alert(hrDesc.each);
// Test Input
var inputTest = $('test-input');
var inputDesc = inputTest.descendants();
alert(typeof inputDesc);
// alert(inputDesc.each); // Uncomment and you get a JS
error
// Test BR
var brTest = $('test-br')
var brDesc = brTest.descendants();
alert(typeof brDesc);
alert(brDesc.each);
});
//]]
/script
I tried searching trac, but found nothing specific to this issue.
Regards,
Rob
Andrés Robinet | Lead Developer | BESTPLACE CORPORATION
5100 Bayview Drive 206, Royal Lauderdale Landings, Fort Lauderdale, FL
33308 | TEL 954-607-4207 | FAX 954-337-2695 |
Email: [EMAIL PROTECTED] | MSN Chat: [EMAIL PROTECTED] | SKYPE:
bestplace | Web: bestplace.biz | Web: seo-diy.com
I found something similarhttp://dev.rubyonrails.org/ticket/11102, but it's not
the same (though it's probably related to it)
Regards,
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Selector.findChildElements issue
ya, the easiest solution will probably be:
descendants: function(element) {
return Element.select(element, *);
},
On Feb 15, 10:02 am, Andrés Robinet [EMAIL PROTECTED] wrote:
-Original Message-
From: prototype-core@googlegroups.com [mailto:prototype-
[EMAIL PROTECTED] On Behalf Of Tobie Langel
Sent: Friday, February 15, 2008 3:16 AM
To: Prototype: Core
Subject: [Prototype-core] Re: Selector.findChildElements issue
Hi,
That is indeed a regression and we'll fix it.
However, I can't stop myself from wondering what kind of bizarre HTML
actually sports children for input tags ;)
Best,
Tobie
On Feb 15, 8:58 am, Andrés Robinet [EMAIL PROTECTED] wrote:
-Original Message-
From: Andrés Robinet [mailto:[EMAIL PROTECTED] On Behalf Of Andrés
Robinet
Sent: Friday, February 15, 2008 2:51 AM
To: 'prototype-core@googlegroups.com'
Subject: Selector.findChildElements issue
Hi All,
I found what appears to be a bug in Selector.findChildElements. I'm
using
prototype 1.6.0.2 and this behavior was not present in version 1.6.0.
I've
experienced this behavior on both IE 7 and FF 2 (didn't test other
browsers).
Calling element.descendants() on an input element will call
element.select('*') which in turn calls
Selector.findChildElements(element,
'*'). This function returns undefined for inputs, but returns an
iterable
object for other empty tags such as hr and br, which is very odd
(it
should either return always undefined or always return an iterable -
empty-
object, shouldn't it?).
I didn't go deeper into details about why and where the bug exactly
is,
but I have this sample code as a proof of concept:
form action=whatever.php method=post enctype=application/x-
www-
form-urlencoded
hr id=test-hr /
input id=test-input type=text value=whatever /
br id=test-br /
/form
script language=javascript type=text/javascript
//![CDATA[
document.observe('dom:loaded', function() {
// Test HR
var hrTest = $('test-hr')
var hrDesc = hrTest.descendants();
alert(typeof hrDesc);
alert(hrDesc.each);
// Test Input
var inputTest = $('test-input');
var inputDesc = inputTest.descendants();
alert(typeof inputDesc);
// alert(inputDesc.each); // Uncomment and you get a
JS
error
// Test BR
var brTest = $('test-br')
var brDesc = brTest.descendants();
alert(typeof brDesc);
alert(brDesc.each);
});
//]]
/script
I tried searching trac, but found nothing specific to this issue.
Regards,
Rob
Andrés Robinet | Lead Developer | BESTPLACE CORPORATION
5100 Bayview Drive 206, Royal Lauderdale Landings, Fort Lauderdale, FL
33308 | TEL 954-607-4207 | FAX 954-337-2695 |
Email: [EMAIL PROTECTED] | MSN Chat: [EMAIL PROTECTED] | SKYPE:
bestplace | Web: bestplace.biz | Web: seo-diy.com
I found something similarhttp://dev.rubyonrails.org/ticket/11102, but
it's not
the same (though it's probably related to it)
Regards,
Rob
Hi Tobie,
There's a cooltip library (same builders of modalbox). This library creates
cooltips using the title tags of elements, and part of the job is searching
for
the alt attribute on descendant tags to disable it (and avoid the browser
showing its own tooltip). You add a cooltip to a form field (pretty common to
do
so for form fields) and you get an error, since the library assumes
descendants
is at least an empty array... HOWEVER, ALL I SAID IN PREVIOUS POSTS IS NOT
TRUE.
This is the truth:
elem.descendants calls elem.select('*'), but for inputs, elem.select('*')
makes
no sense, since the select method will SELECT THE FORM CONTROL IN THE UI,
this
is a method of Form.Elementhttp://prototypejs.org/api/form/element/selectwhich
happens to have a native implementation (at least for
IEhttp://msdn2.microsoft.com/en-us/library/ms536733(VS.85).aspx) and this is
what
prototype is actually calling... it's NOT calling Selector.findChildElements
So... what should we do now? Clearly, it is ok that the select method is
overridden for input controls, but the descendants method should still return
consistent results.
I've been playing around and any of the commented lines seems to work.
However,
I think I'm not up to submit a patch (I can if you want, but never did before,
and I'm not a JS or prototype guru, so don't trust my code). If some of you
can
evaluate these or other alternatives, it would be great:
descendants: function(element) {
//return
[Prototype-core] Re: Deprecation.js
Ya, I'm just trying to figure out a good way to do so as the plan is to tie it to a specific version of Prototype. Any suggestions welcomed. Best, Tobie On Feb 15, 12:58 pm, Richard Quadling [EMAIL PROTECTED] wrote: On 14/02/2008, Richard Quadling [EMAIL PROTECTED] wrote: On 14/02/2008, Tobie Langel [EMAIL PROTECTED] wrote: Hi Richard, Thanks for the thumbs up. deprecation.js is meant to be used with prototype.js, not a subset of it, so I don't think that's really an issue for now. The plan is to keep this new prototype extension up to date with the changes in Prototype, so once we remove the Position object, we'll add it to deprecation.js. Aha. Ok. I see. I was getting ahead of the game by taking out Postition before its time. Thanks. On Feb 14, 11:02 am, Richard Quadling [EMAIL PROTECTED] wrote: Hi. If you comment out from prototype.js the deprecated functions/classes (I take out the whole Position class for example), then deprecation.js fails due to the lack of the namespace: Position. So, using v1.6.0.2, should Position be defined but unused and therefore be in the global namespace or should it be commented out and deprecation.js cope with its absence? (I can't quite decide if this is a core or a spinoff issue). Would it be possible to add a version number/build number to the extension please. -- - Richard Quadling Zend Certified Engineer :http://zend.com/zce.php?c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Overwritten native Element definition
Hi,
This should be fixed in Prototype 1.6.0.2.
Have you tried it ?
Best,
Tobie
On Feb 18, 5:54 pm, Sjoerd Mulder [EMAIL PROTECTED] wrote:
Related to this:
http://groups.google.com/group/prototype-core/browse_thread/thread/26...
( Conflict 1.6 with Virtual Earth in FireFox)
Atlascompat.js also prototypes some methods on the native Element
definition.
In this case it can be solve by first loading the atlas stuff and then
then prototype.js
On Feb 18, 5:36 pm, Sjoerd Mulder [EMAIL PROTECTED] wrote:
Hi All,
Why is prototype framework overwriting the (native) Element object /
constructor and setting it's own function?
This breaks a lot of functionality in other frameworks which are
prototyping some Methods on the (native) Element, for example:
selectNodes / selectSingleNode to emulate IE XPath in other
browsers (Fx, Op, Sf), See (http://dev.abiss.gr/sarissa/)
I have tried to access the original constructor even on different way
like:
new DOMParser().parseFromString('test /', 'text/
xml').documentElement.constructor but that also returns the
prototype.js function.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Feature suggestion: getClassName
Hi,
That unfortunately doesn't solve the problem for namespaced classes:
var Vehicles = {};
Class.create('Vehicle.Cars', {});
Best,
Tobie
On Feb 21, 12:10 pm, GarethAtFlignet [EMAIL PROTECTED]
wrote:
As prototype provides a convenient OO approach to javascript coding
through its object inheritance model it would be 'really' useful if
you could query the name of the current class through a getClassName()
method or similar like you can in many other languages.
There is a post at:
http://groups.google.com/group/rubyonrails-spinoffs/browse_thread/thr...
which discusses an approach to achieve this and seems backward
compatible.
Code and usage below. Any chance of including 'something' like this in
a future release?
---
Usage:
script
Class.create(Vehicle, { });
Class.create(Car, Vehicle, { }); // Car extends Vehicle
Class.create(Passat, Car, { }); // Passat extends Car
// create one of each
var v = new Vehicle();
var c = new Car();
var p = new Passat();
alert(v.getClassName());
alert(c.getClassName());
alert(p.getClassName());
/script
---
Class rewrite:
var Class = {
create: function() {
var parent = null, properties = $A(arguments);
// retrieve the class name
var className = ;
if(Object.isString(properties[0])) {
className = properties.shift();
}
// get the parent
if (Object.isFunction(properties[0]))
parent = properties.shift();
function klass() {
this.initialize.apply(this, arguments);
}
Object.extend(klass, Class.Methods);
klass.superclass = parent;
klass.subclasses = [];
// reference the class by name
if(className!=) {
window[className] = klass;
}
// store the classname as klass.constructor.className
// and add a method getClassName() to all classes
klass.className = className;
klass.prototype.constructor.addMethods({
getClassName: function() {
return this.constructor.className;
}
});
if (parent) {
var subclass = function() { };
subclass.prototype = parent.prototype;
klass.prototype = new subclass;
parent.subclasses.push(klass);
}
for (var i = 0; i properties.length; i++)
klass.addMethods(properties[i]);
if (!klass.prototype.initialize)
klass.prototype.initialize = Prototype.emptyFunction;
klass.prototype.constructor = klass;
return klass;
}
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Late binding for contextual iterators (patch advertisement)
Nice work!
Out of curiosity, could we see proper benchmarks for this ?
That would be awesome.
Best,
Tobie
On Mar 2, 11:04 pm, kangax [EMAIL PROTECTED] wrote:
I like #eachSlice fix (to delegate binding to #collect). From quick
test, using call over #bind (i.e. invoking method via call vs.
invoking binded method) seems to be almost twice faster (which is
pretty amazing).
Element._visible = Element.visible.bind({ });
console.time('binded');
for (var i=10001; --i;) {
Element._visible(document.body);}
console.timeEnd('binded');
console.time('call');
for (var i=10001; --i;) {
Element.visible.call({ }, document.body);}
console.timeEnd('call');
binded: ~400ms
call: ~250ms
On Mar 2, 3:23 pm, Ben Newman [EMAIL PROTECTED] wrote:
Posted this a few minutes ago:
http://dev.rubyonrails.org/ticket/11264
The basics:
- Simplifies a number of the Enumerable methods.
- Avoids using Function#bind where the functionality of
Function#call is sufficient.
- Introduces a convenient new feature: any object that supports a
call method can be used as an iterator.
The changes made in the patch are pretty conservative, but I think
similar changes might be appropriate elsewhere in the library, if
there's consensus on these suggestions.
Cheers,
Ben
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: String.prototype.exec()
What about something like this: http://pastie.caboo.se/169666 Best, Tobie --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: String.prototype.exec()
Wrote about this a while ago: http://tobielangel.com/2007/2/23/to-eval-or-not-to-eval Which makes me think that a try-catch block might be useful as in: http://pastie.caboo.se/169679 Best, Tobie On Mar 24, 3:20 pm, kangax [EMAIL PROTECTED] wrote: It's great, Tobie (as always) :) The only thing I'm not sure about is additional script insertion test. Do you mind explaining in which cases setting text property on a script works and appending a text node doesn't? - kangax On Mar 24, 9:45 am, Tobie Langel [EMAIL PROTECTED] wrote: What about something like this:http://pastie.caboo.se/169666 Best, Tobie --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: String.prototype.exec()
You should be able to avoid the sniffing by using a try catch block like so: http://pastie.caboo.se/169809 On Mar 24, 7:00 pm, John-David Dalton [EMAIL PROTECTED] wrote: Missing the point a bit... The reason for the script insert in the first place is Safari has synchronous issues with eval even window.eval. In your attempt to avoid browser sniffing you have avoided the reason why the implimentation is needed and inflated the code size.http://webreflection.blogspot.com/2007/08/global-scope-evaluation-and... @Tobie - I dig your blog post, I referenced in in my research for the exec solution when I was deving ProtoSafe. http://pastie.caboo.se/169801 less code. addresses the issue. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: invoke with getAttribute doesn't work in IE
Hi nik,
That's one of the reasons why we created Element#readAttribute ( see:
http://prototypejs.org/api/element/readattribute ).
Note that these questions are usually better answered in the spinoffs
mailing list ( http://groups.google.com/group/rubyonrails-spinoffs ).
Best,
Tobie
On Mar 26, 1:07 am, nik [EMAIL PROTECTED] wrote:
Hello,
I tried to use
var foo = $$('div.myClass').invoke('getAttribute','id').uniq();
to get a unique list of all ids.
That worked well in FF 2 and Opera 9 but not in IE 6 (I don't tried in
IE7) So i did it using a workaround with a for-loop. It's a bug? Or am
I dumb ;)
greetz
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Timeline for supporting native array methods?
Hi Jeff, Sorry for the late response, we're in the middle of a triple move here: Changing versioning system (svn to git), bug report system (Trac to Lighthouse), and documentation system (external to inline)... Both these issues would be better adressed with relevant bug reports. Best place to do so is in our bug tracking system system: http://prototype.lighthouseapp.com/ Thanks for your help, Tobie On Apr 16, 6:41 am, Jeff Watkins [EMAIL PROTECTED] wrote: Is there any timeline for when Prototype will cease replacing the native implementations of map, filter, etc? I had thought this change was part of 1.6, but unless I'm misreading the source, 1.6.0.2 still overwrites the native implementations. Additionally, has anyone looked at why prototype's Array#map method doesn't work on NodeLists returned from Safari's querySelectorAll method? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
