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

Reusing Selectors #24

Open
FrankC01 opened this issue Mar 19, 2015 · 3 comments
Open

Reusing Selectors #24

FrankC01 opened this issue Mar 19, 2015 · 3 comments
Labels
category: governance Sustainable development status: dubious Where do I even begin? type: feature request Feature requests

Comments

@FrankC01
Copy link

David,

Been a user for a while. Moving into something else that produces hiccup vector tree format (instaparse) and am reviewing your selector library thinking I could re-use most of it.

My question is: It seems that the non-usable aspect would be limited to the 'tag' and 'attr' selectors, but am I blinded by desire and missing some subtle aspect which would render the whole idea moot?

Thanks in advance,
Frank

@davidsantiago
Copy link
Collaborator

I'm not sure what exactly your goals are, so I can't say if this would be an easy change for you. I can tell you that Hickory is a bit of a second pass, for me. I originally wrote Tinsel, which works on the hiccup vector tree format, and has selectors similar to Hickory's. I wrote Hickory largely because I wasn't satisfied with what I could do with Tinsel. So it is certainly possible.

Some issues, off the top of my head, that led me in this direction. Hiccup's vector tree format doesn't fully cover an HTML document, so sometimes you have to stick certain things in a string with the HTML in it. It's also a more write-optimized format, so while it's nicer to write Hiccup, it takes more work to parse it and work with it, since various pieces of information can appear in multiple ways and forms may have elements in varying places. Also, the aforementioned "Need to put doctype and other things in a string" issue can bring this to the point of "maybe not even really possible."

This is not to say don't do it, you can get pretty far in that direction, and maybe far enough to meet your needs completely. Just letting you know what I ran into when I was trying to make that work.

@FrankC01
Copy link
Author

I will venture forward to see how things shake out. Basically I'm trying to avoid rolling my own vector-zip predicate library but have the flexibility to extend....

@FrankC01
Copy link
Author

Update: So, I opted to start with data.zip as the foundation and have been writing predicate/selector functions 'tuned in' to the domain semantics of the vector tree (FYI: Manchester Owl parsed using instaparse)

So at this point, with the fundamental path selectors and subquery type things in place, I'm re-reviewing your selector library for inspiration for the next level. Thanks for paving the way !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
category: governance Sustainable development status: dubious Where do I even begin? type: feature request Feature requests
Projects
None yet
Development

No branches or pull requests

3 participants