[Prototype-core] Re: Proposed rewrite of $$/Selector
Ken Snyder a écrit : Yes, it was very slow for me too with any of the nth- predicates. That nth routine relies on counting the number of previous siblings FOR EVERY NODE. I'm not sure if that is avoidable, but I've added the Yeah, you're O(n²) on this, and I think I found a way to be O(n) quite simply. I'll let you guys know... first and last element separately is great, but not such a great practice when trying to separate presentation from logic with JS. Plus, you can use :first-of-type and :last-of-type or :first-child and :last-child to achieve identical selection. And :empty seems tricky in XPath too. So Christophe, keep us posted with any XPath magic you have up your sleeve This is it from me for now with $$. As for XPath, I do need to see whether we can achieve something efficient with XPath (building a global AND-based expression, much like the raw-OR version of include, would do nicely I guess). I am concerned with :not requiring a each/include, which is O(n²) as well, thus is very slow. I am thinking of another way to build the resulting set. If worse comes to worst, relying on the raw-OR variant of include *might* help in this case. -- Christophe Porteneuve a.k.a. TDD [They] did not know it was impossible, so they did it. --Mark Twain Email: [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: Proposed rewrite of $$/Selector
Andrew Dupont a écrit :
On Feb 18, 9:45 pm, Ken Snyder [EMAIL PROTECTED] wrote:
Yes, it was very slow for me too with any of the nth- predicates.
That nth routine relies on counting the number of previous siblings FOR
EVERY NODE. I'm not sure if that is avoidable, but I've added the
corresponding xpath... see below. The xpath syntax may need to be
reworked with previous-sibling or self, I'm not sure. Or this may just
be a wrong path :)
DomQuery sidesteps this by setting an expando nodeIndex property the
first time it iterates through a group of child nodes.
I don't know how well you'll be able to implement a CSS not()
equivalent in XPath. From what I could see, filtering out nodes in
XPath depends on the content of not(). Consider:
CSS3: div:not(#speech1)
XPath: .//[EMAIL PROTECTED]speech1]
CSS3: div.character:not([EMAIL PROTECTED])
XPath: .//div[contains(concat(' ', @class, ' '), ' character ') and
@id!='speech2']
Luckily, not is a function in XPath. It returns the opposite
boolean of whatever it contains:
.//div[not(@id=speech1)]
.//div[not(contains(concat(' ', @class, ' '), ' character ') and
@id='speech2')]
Still a little tricky because of the placement of the brackets. We
might have to remove the brackets from Selector.xpath.* so that we can
insert them properly based on the context of the predicate. Also, I'm
not even sure the second example qualifies as a simple selector the
way the CSS3 spec defines it.
It doesn't. As soon as you find yourself putting an 'and' in there,
you're doomed :-) A simple selector is a SINGLE selector that is NOT a
:not...
--
Christophe Porteneuve a.k.a. TDD
[They] did not know it was impossible, so they did it. --Mark Twain
Email: [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: Proposed rewrite of $$/Selector
Andrew, this is just incredible. Keep it going. :) Best, Thomas Am 13.02.2007 um 14:17 schrieb Andrew Dupont: Thanks for the compliments, guys. Alex Russell's post on the subject (http://blog.dojotoolkit.org/ 2007/02/04/dojoquery-a-css-query-engine-for-dojo) has stirred some diplomatic talks. It looks like Alex, John Resig, Jack Slocum, Dean Edwards, and I are going to pitch in toward some sort of site where all the different CSS-querying implementations can be benchmarked against uniform, real-world examples. I think this is a great idea and can only make all our engines better. I don't think this project has any sort of timetable, though, so when I have a moment I'll clean up what I've got so far and submit a patch so we can start discussing this. And once Sam opens up branches I think it'll be much easier to collaborate on this code. ATTENTION TO ANYONE WHO READS THIS LIST: If you're an XPath rockstar, I need to talk to you. Cheers, Andrew On Feb 5, 12:35 am, Christophe Porteneuve [EMAIL PROTECTED] wrote: I certainly concur with Mislav. I've been looking at your code twice, and it looks pretty good to me. I especially like the feature modularity thing. Yes, it weights twice as much as the current selector implementation, but then, its way faster, much more modular, and compressed JS is there for us anyhow. Submit the patch, and tickle Sam until he works with it :-) -- Christophe Porteneuve a.k.a. TDD [They] did not know it was impossible, so they did it. --Mark Twain Email: [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: Proposed rewrite of $$/Selector
Thanks for the compliments, guys. Alex Russell's post on the subject (http://blog.dojotoolkit.org/ 2007/02/04/dojoquery-a-css-query-engine-for-dojo) has stirred some diplomatic talks. It looks like Alex, John Resig, Jack Slocum, Dean Edwards, and I are going to pitch in toward some sort of site where all the different CSS-querying implementations can be benchmarked against uniform, real-world examples. I think this is a great idea and can only make all our engines better. I don't think this project has any sort of timetable, though, so when I have a moment I'll clean up what I've got so far and submit a patch so we can start discussing this. And once Sam opens up branches I think it'll be much easier to collaborate on this code. ATTENTION TO ANYONE WHO READS THIS LIST: If you're an XPath rockstar, I need to talk to you. Cheers, Andrew On Feb 5, 12:35 am, Christophe Porteneuve [EMAIL PROTECTED] wrote: I certainly concur with Mislav. I've been looking at your code twice, and it looks pretty good to me. I especially like the feature modularity thing. Yes, it weights twice as much as the current selector implementation, but then, its way faster, much more modular, and compressed JS is there for us anyhow. Submit the patch, and tickle Sam until he works with it :-) -- Christophe Porteneuve a.k.a. TDD [They] did not know it was impossible, so they did it. --Mark Twain Email: [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: Proposed rewrite of $$/Selector
On 1/20/07, Andrew Dupont [EMAIL PROTECTED] wrote: I'd love to hear some feedback. I've been looking at this code for way too long now, so a fresh pair of eyes may point out something obvious that I've missed. Also, I'd love it if someone were to modify this code to add new stuff so that $$ can accommodate a wider range of selectors. Andrew- I'm reviewing your code for the second time now and still I cannot find anything bad about it. It is faster, it is better... So what are we waiting for? Let's get this into core first and then ponder about extending it even further. Changes and collaboration are easier when you have it versioned! -m --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
