Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for functional pseudo-elements #29

Closed
wants to merge 1 commit into from
Closed

Support for functional pseudo-elements #29

wants to merge 1 commit into from

Conversation

redapple
Copy link
Contributor

Some modifications to the parser to explicitly handle pseudo-elements and functional pseudo-elements.

XPath translation happens in xpath_xxxx_functional_pseudo_element and xpath_xxxx_pseudo_element which are probably not the best method name patterns.

A new flag in GenericTranslator is used to handle these customizations or keep original behaviour.

This is somewhat related to scrapy/scrapy#176 (though I'm not sure that very PR will use pseudo-elements in the end)

@dangra
Copy link
Member

dangra commented Sep 14, 2013

this is great stuff, it will be used for scrapy/scrapy#176 for sure.

@redapple
Copy link
Contributor Author

Travis CI build failed on job 17.4 which uses Python 3.1, which isn't available (anymore) in Travis CI (http://about.travis-ci.org/docs/user/ci-environment/#Python-VM-images)

@redapple
Copy link
Contributor Author

Rebased to make things tidier.

@SimonSapin
Copy link
Contributor

Hi. Thanks a lot for starting this. It turns out I have pretty strong opinions on how to do this, so rather than having you jump through hoops I went ahead and wrote the thing. I didn’t use code (other than tests) from this PR, though, sorry :)

Rather than having a boolean flag to enable this and have pseudo-elements be part of the "normal" tree, pseudo-elements are still in the Selector.pseudo_element attribute. In addition to None or a string for a "simple" pseudo-element, this attribute can be an instance of the new FunctionalPseudoElement class.

I don’t want to encourage too much implementing pseudo-elements with XPath (as I think this is the wrong approach), but in order to still enable what Scrapy wants to do, "translator" objects now have a xpath_pseudo_element method that just raises but can be overridden to transform the XPathExpr object. On other words, the name-based method dispatching is left up to the subclasses, as show in the tests.

@SimonSapin SimonSapin closed this Sep 15, 2013
@redapple
Copy link
Contributor Author

That's ok Simon, I wasn't particularly proud of it anyway ;)
I'll have a look at your implementation.
Thanks.

@redapple redapple deleted the pseudo branch September 15, 2013 22:13
@SimonSapin
Copy link
Contributor

I just released cssselect 0.9.1, which is backward-incompatible with 0.9 if you use pseudo-elements with the selector_to_xpath method. Details in the changelog.

@redapple
Copy link
Contributor Author

Thanks for the update @SimonSapin

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants