search

jnunemaker / crack

Really simple JSON and XML parsing, ripped from Merb and Rails.
MIT License
541 stars 93 forks source link

Allow Crack to be extended with different parsers #31

Closed rubiii closed 13 years ago

rubiii commented 13 years ago

Don't know if you remember this, but we talked about my need to use a different parser for speed and consistency months ago. Back then you suggested to duplicate everything you've done so far and create a separate gem for this. Nevertheless, I'd rather like to use Crack and benefit from future improvements.

I created a Nokogiri parser to work with Crack, but would love to remove the duplication (REXMLUtilityNode, etc.) and just ship the parser.

I didn't need to make any important changes. Crack still defaults to use REXML, but it can be changed very easily:

Crack::XML.parser = MyNokogiriParser

Hope you like the idea and maybe pull the changes.

jnunemaker commented 13 years ago

I guess I don't understand what you get from crack if you use a different parser. The ability to use Crack.parse with nokogiri? If that is it then it seems like having a separate gem makes more sense. I guess I'm just wondering what would be shared. Maybe tests would help me understand the end goal.

rubiii commented 13 years ago

Well, the REXMLUtilityNode for example. Crack's REXML parser is a tiny utility Class which uses the REXMLUtilityNode and it could easily be replaced by some other parser to use the existing REXMLUtilityNode.

rubiii commented 13 years ago

Don't know if adding tests would help you understand the benefit(s). For unit tests, I would just test that the default parser can be replaced, but I wouldn't add a whole different parser (even if it's simple) to test this. You could take a look at Nori which includes the XML-side of Crack and adds a Nokogiri parser.

jnunemaker commented 13 years ago

Ok, could be that tests won't help me understand. That said, they definitely will make sure I don't break it in the future.

I've always looked at crack as a simple way to parse xml, but not something I'd use for more than simple scripts. If I was going to use something like nokogiri, I probably wouldn't just turn the xml into a hash. I guess that is what I didn't understand originally with this. In my head I was thinking if you want to use another parser, there is no benefit to using crack, just use the other parsers API to pull out the info you need.

That said, with tests, I'll pull this in. Seems simple enough that maintaining it won't be a big deal if you find it helpful. Hope that makes sense.

rubiii commented 13 years ago

well, crack is really helpful in translating the complete xml into a hash and that's exactly what i need for soap responses. for complex responses, people can still parse the xml themselves, but a hash is very convenient and works for most services.

i've added some basis tests for the xml parser feature. thanks mate!

jnunemaker commented 13 years ago

0.3.1 released.