I figured I would create another post pointing to Alex Arnells
Inheritance thread (per Mislav's request). I am interested in his
additions and approach. I dig the private vars and the ref to the
class as well as the instance and parent.
Alex Arnell wrote:
Here is a Pastie link to a concrete
Thanx xinze,
In the readme_first.txt file I point out that I had implemented some
patches from various tickets.
I goofed the patch on that one.
http://dev.rubyonrails.org/ticket/8843
should have been:
results.push($(query.snapshotItem(i)));
I will fix this bug and release a new package when
Thanks for clearing that up. I knew what the first one did but not the
second.
I was actually stating that the API docs dont have these in it. Could
one of the core team add these methods to their documentation.
--~--~-~--~~~---~--~~
You received this message
Hi guys,
This is really not a bug but I thought I would bring it to your
attention.
$$('[type=radio]').map(function(el){return el.next()}); // = [label,
label]
$$('[type=radio]').map(Element.next); // = [label, undefined]
The map method is passing 2 params to the iterator.
This makes the
Thanks Sam ! :)
--~--~-~--~~~---~--~~
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
Additional note:
Protoculous also allows the loading of additonal js files like
Scriptaculous via:
protoculous.js?load=addons
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to
You can gzip the var-shrunk versions (which isnt decompressed so its
faster loading)
and the filesize goes from 27.5kb to 20.4kb or so.
As I said above it was enough to add the Effects.js from Scirpty
and still be lower than normal Prototype gzipped. :)
- John-David
Hi all,
The following methods are missing documentation:
Element.setOpacity();
Function.argumentNames();
Function.methodize();
Thanx,
- John-David
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core
Hello,
Please direct future questions to the email sipplied in the
readme_first.txt.
If you are referring to the base 62 encoded x_packed.js versions,
that appears to be part
of Dean Edwards' Packers code and I would not remove it.
- JD
--~--~-~--~~~---~--~~
I really suggest usig the varshrink versions and gzipping them.
You get the smallest file size most of the time that way and no
clientside delay for js decoding.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
I modified Prototype to allow for the use of native CSS selector
support.
http://webkit.org/blog/156/queryselector-and-queryselectorall/
I have attached a screen shot of the performance boost running on the
nightly build:
http://nightly.webkit.org/files/trunk/win/WebKit-SVN-r30154.zip (built
on
i will ass ^ $
no need to go looping
--~--~-~--~~~---~--~~
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
this patch doesn't solve the issue entirely
if you have a child element with the id=parentNode
and the parent element tries element.parentNode it will return the
child with the id parentNode.
bummer.
--~--~-~--~~~---~--~~
You received this message because you are
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:
woopsie *add, and ticket updated thanks Ken!
--~--~-~--~~~---~--~~
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,
ticket + patch for the bug:
http://dev.rubyonrails.org/ticket/11092
--~--~-~--~~~---~--~~
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
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
I suspect the unit tests are tailered for the current revision in
svn..
time for me to dload rails... or manually compile me some js.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to
Rock!
Updated the ticket, passes the dom.html unit test with flying colors.
Also added a modified unit test that contains tests for this ticket.
The files of importance are
ie_attrib_patch.diff
dom.html
http://dev.rubyonrails.org/ticket/11092
With all the buzz last week and this about frameworks being Adobe AIR
compatible.
I am wondering if the Prototype Team has tested Prototype with AIR's
new security model.
I know prototype uses eval(), 3 times:
String.toJSON(); // should be ok in AIR
Ajax.Request.evalResponse(); //could choke if
You are right, it errors because of appending the text node.
appendChild must be used to trigger the error :)
Here is the modified code.
http://pastie.caboo.se/169837
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
I have updated it with a version that reduces some overhead by using
closures, thanx kangax.
Yes Prototype would use Prototype.exec() instead of eval inside the
ajax methods.
http://dev.rubyonrails.org/ticket/11284
http://dev.rubyonrails.org/ticket/8112
I don't think this form of code
You can lead a horse to water but you can't make em' drink :).
--~--~-~--~~~---~--~~
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
Here is a patch for it (I modified 2 lines of code):
Please test and report back on the ticket if it works:
http://dev.rubyonrails.org/ticket/11530
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core
I tested the patch and it turns out that the eval() in the Selector
class isn't a problem becuase Adobe Air uses the compileXPathMatcher()
and bypasses the eval. The only issue must be the evals used for
scripting and the patch takes care of those as well. Other than that I
can't see an issue
Prototype does seem to work out of the box with ADOBE AIR.
The script insertion that the patch for Prototype.exec()
provides does not work under ADOBE AIR, but it does not error out
either.
If you want to eval code you can do somethign like this though, AIR
allows:
function exec(code){
new
Prototype has been using the compileXPathMatcher() for xpath support
since 3/09/07 http://dev.rubyonrails.org/changeset/6366
There shouldn't have been any issues with it since then, unless ADOBE
AIR didn't support XPath until recently. Reguardless Prototype seems
to work just fine.
Also a different patch for solving the same problem.
I check the window.location.href and the url of the ajax call to
determin if its file or ftp protocol then allow zero or not.
http://dev.rubyonrails.org/ticket/10030
--~--~-~--~~~---~--~~
You received this
This ticket here: http://dev.rubyonrails.org/ticket/11434 mentions
asolution for dropped connections in Firefox. It might work on other
browsers as well. Basically they attach a callback to the onError
native event handler of the transport.
--~--~-~--~~~---~--~~
I have started a pdoc-scriptaculous google code page.
Visit the user list post for more details:
http://groups.google.com/group/rubyonrails-spinoffs/t/32b29609203e209e
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
This was originally used to allow this method to not have to pull down
a real file and to avoid https issues in IE.
This ticket: http://dev.rubyonrails.org/ticket/9394
Patches it to use a different method (maybe one that is more stable
with IE7 as well)
I have started moving over some of the patched from trac to my github
fork:
http://github.com/jdalton/prototype/commits/master
Please let me know if something should be dropped, altered or modified
in anyway.
I am currently sending pull requests to Tobie only, should I be
sending them to others
Hi Richard,
I was a little bummed by the switch at first as well.
Now though I am beginning to see the cool side of it.
For example before when you wanted to contribute you had to make a
patch that would only work for the current version of Prototype and
probably not the version that was in SVN
Hello Steffen ,
For future reference, this post should have gone to the users mailing
list:
http://groups.google.com/group/rubyonrails-spinoffs
Here is a patch to make Prototype more iframe friendly:
http://dev.rubyonrails.org/ticket/11475
Your usage of the dom:loaded observer is incorrect.
Hello Rauan,
Which version of protoculous are you using, (1.6.0.2 + 1.8.1)
protoculous-shrinkvars.js?
Have you tried using the regular prototype and scriptaculous.
Can you try to create a reproducable test for me.
Also for future reference please send questions to my gmail account.
- JDD
Please submit a bug ticket:
http://www.prototypejs.org/contribute
- JDD
--~--~-~--~~~---~--~~
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
Turns out it was a firebug bug and not related to the compressed or
minified files.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to
Patch addresses the memory leak:
http://github.com/jdalton/prototype/commit/0353246ac2ad439260905799798f0069d9a7d0ca
Patch addresses other issues with escapeHTML and unescapeHTML:
http://github.com/jdalton/prototype/commit/6010a300c39b0c66394706e9edb8b110b5932d9e
Unit tests for the patch:
Thanks for the tests Geoff,
I have uploaded them here: http://protolific.net/memory_leak_testcase.zip
I patched the Prototyep 1.5.1 file.
There is a second file named _prototype_1_5_1.js which is my latest
git version compiles (so it is really 1.6.0.2+ with the patch in it
is as well.
I still
I think kangax used to have something similar in his:
http://github.com/kangax/protolicious/tree/master/helpers.js
Though I cannot seem to find it now :)
- JDD
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Patches here:
http://github.com/jdalton/prototype/commit/723c26518392d838cf9ec368eddfba0c1874bac1
and
http://github.com/jdalton/prototype/commit/8eaae75066531993eba13df5eb1469016435843b
they need unit tests though :)
--~--~-~--~~~---~--~~
You received this message
Patched to work with getValue, setValue.
http://github.com/jdalton/prototype/commit/3b03b76660bc29ba5d8a6ef4e06c99c8faded107
Unit tests:
http://github.com/jdalton/prototype/commit/101d23d64aba2c0c459c97fa684a9079a7beb140
--~--~-~--~~~---~--~~
You received this
The getValue and setValue, use the Form.Element.Serializers anyway.
So when I added serialization it adds the getValue and setValue.
The browser sees the innerHTML of the button element as its value so
this is consistent.
- JDD
--~--~-~--~~~---~--~~
You received
I don't think GIT supports the keywords in files like revision and
others.
I remember wondering that myself. After a quick google I saw a post on
the git mailing list
that shot down the idea of using the key words.
- JDD
--~--~-~--~~~---~--~~
You received this
Hi All,
I haven't read all the posts, but I have applied Samleb's patch which
uses the doScroll jQuery method and fixes the first-in-first-out
order.
I have also fixed the window onload triggering before dom:content
loaded and fixed the multiple window resize calls for IE.
I have tested the
[#9394] window onload executing before all of the contentloaded
observers are executed:
http://dev.rubyonrails.org/ticket/9394
Patch 1
http://github.com/jdalton/prototype/commit/4d4ca98fa6f8994b873984f1485c5b496fadecb8
Patch 2
IE has issues extending XML Nodes.
See http://dev.rubyonrails.org/ticket/9709
You must use Element#methodName instead or make a wrapper for it:
Something like:
(function( ) {
var methods = Object.keys(Element.Methods).inject({ }, function(m,
name) {
m[name] = function() {
return
Diego Perini,
in IE dom:loaded is a custom event, custom event use the
ondataaviable event as a vessel to ride the event bubble and other
things.
that is why you see that. use event.eventName instead of
event.eventType.
- JDD
--~--~-~--~~~---~--~~
You received
Added the following updates to the event system in my fork:
Fix issue with how IE wrappers.dispatcheriterates over list of
wrappers:
http://github.com/jdalton/prototype/commit/bfa0ea8da441d53983dd4223248991b3329ab93f
Add unit tests for the wrapers.dispatcher fix :
I just looked through the code and realized we were handling the
IFrame issue :), thanks Diego for pointing that out :).
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group,
Diego,
Is line 394 ok with a specific check for Opera?
http://github.com/jdalton/prototype/tree/master/src/event.js#L394
I heard Opera 9.5b doesn't have that issue (but I think that may be
getting to granular).
My main goal with the browser sniff is to avoid unnecessary iterations
of the dom on
I think Prototype should support something like this, though I am not
sure if your patch is the best way to do it. I will have to look at it
closer.
I flagged the ticket for 1.6.1.
Also Juriy has his version of simulating events -
Thanks Diego,
Good catch on the timeout, clearing the timer variable is probably the
right way to go :)
So maybe we I should remove the Opera check considering other browsers
may support the HTML 5 spec as well.
- JDD
--~--~-~--~~~---~--~~
You received this
I think that the css:loaded would probably be the best way to go so it
doesnt delay the dom:loaded event
Opera uses the disabled approach (what if a style sheet it set to
disabled in the html though?)
and Safar used the length approach.
The length approach may cause issues with import as this
Also some other performance tips:
http://www.sitepen.com/blog/2008/05/09/string-performance-an-analysis/
disccomp, feel free to submit a ticket and a patch for the current
String#strip
http://www.prototypejs.org/contribute
- JDD
--~--~-~--~~~---~--~~
You received
Can you provide a test snippet?
You can compare the differences between the two versions here:
http://www.protolific.net/step-by-step/24.png
As you can see in the comparison the new version does not allow
document.documentElement to be returned as the offsetParent
and the old one did. I suspect
Hello Ryan,
Thanks for the example.
I used this favlet to run the site using the git version of Prototype
and I do see the issue under IE.
javascript:var
s=document.createElement('script');s.setAttribute('src', 'http://
www.protolific.net/prototype-git.js');document.body.appendChild(s);void(s);
All right :),
http://github.com/sstephenson/prototype/tree/master/src/dom.js#L578
As you can see there is a bit of code in the git core that I think
should really be examined and cleaned up or commented.
//Why do we do this?
var offsets = element.positionedOffset(),
top =
Here is a Lighthouse ticket:
http://prototype.lighthouseapp.com/projects/8886-prototype/tickets/197-code-review-of-element-relativize-git-core
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To
I haven't seen the official roadmap for 1.6.1.
So here is my take on it.
1.6.0.3 was a bug fix release.
I see 1.6.1 as an optimization and new feature/API release.
I see things like:
* Use of documentFragment (Huge IE boost in spots),
* Use of _each instead of each in places were we can
Also utilizing element.ownerDocument more (this will help in
compatibility with iframes).
Maybe a Element#getDocument(), getBodyElement, getRootElement.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core
If a cache is to be used it can be uniquely marked via the same
approach as elements in the event system
element._prototypeWrapperId = [arguments.callee.id++];
the id is unique and doesn't transfer if you clone the node.
var instance = Prototype.Element.cache[ element._prototypeWrapperId ];
if
@kangax
Whatever the name is I think it should be used in all wrappers.
This makes it consistent.
If you want to check if a wrapper is of a certain instance.
if( wrapper instanceof Prototype.Node ) {
//wrapper.raw
}
else if (wrapper instanceof Prototype.NodeList) {
//wrapper.raw
}
...
I
Johan, when we say wrapper we don't mean a div in HTML.
We mean instead of extending the native DOM elements
$(element) - returns an extended dom element
$(element) - returns an instance of a ElementWrapper class
the class interacts with the element but does not extend it directly.
see kangax's
Kangax looks good.
I think that it should be $() instead of $W(), but for the purpose of
clarity during the
discussion the use of $W is fine.
I think that any method that returned element, will instead return
NodeWrapper.
Any method that returned an array of elements will return a
@Key Snyder - correct I was assuming Array.prototype was not extended
and that we were using wrappers.
@kangax
I don't think there would be confusion with things like $$
(..).getValue() here.
Keep in mind users do use the equiv of $$('#myId') and that in those
cases you are expecting 1 result
@T. J. Crowder take some time to look at the jQuery source, it might
help with the wrapper discussion.
I was not suggesting that $$() return a list in some cases and a
single item in others. I was saying that
getter/setter methods would execute on the first matched item.
In jQuery (jQuery
// if source is a method
$$(css).source() - equiv
$$(css)[0].source() - equiv
$$(css).first().source() - equiv
you could always cache it
var source = $$(css).source();
// an array of sources
$$(css).invoke('source'); // OR
$$(css).each($$.source); //notice static $$.source method
I am not sure I see a right hand side menu effect.
You should really post this kind of question in the user list:
http://groups-beta.google.com/group/prototype-scriptaculous
Try searching scripteka:
http://scripteka.com/
If its just a hover effect a lot of the time you can just use CSS and
no
The core devs are in the process of cleaning up the 1.6.0.3 release:
You may check Tobies 1.6.0.3 branch:
http://github.com/tobie/prototype/tree/1.6.0.3
- JDD
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Awesome use of nextSibling and parentNode!
I have added my version which checks for the existence of the
element.swapNode method (in IE).
You can find it posted in the ticket.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
@Kangax
I am not aware of any issues with insertBefore and table elements. I
know that IE has issues with innerHTML and table/select elements.
@EMoreth
if nextSibling is null insertBefore will act as appendChild so it
should still work out.
Prototype 1.6.0.3 unmodified + gzipped from Google's servers:
http://ajax.googleapis.com/ajax/libs/prototype/1.6.0.3/prototype.js
Firebug reports it's 31kb. On my filesystem it's 29,998 bytes.
Prototype 1.6.0.3 minified + gzipped:
Firebug reports it's 22kb. On my filesystem it's 21,564 bytes.
73 matches
Mail list logo
