Closed JSteunou closed 10 years ago
@JSteunou woah, thanks for the PR! This is looking great.
Sorry for the lack of activity in jspot, as usual, we're pretty busy. I was thinking that we weren't yet ready to support more extractors, but looking at the PR, it looks like you've been able to support a new extractor type quite nicely :)
I'm a little concerned about jspot becoming bloated with too many extractor types, ideally I'd like to keep only the most commonly used ones bundled in the actual project, and allow alternative ones to be supported as plugins. That said, handlebars is probably a very common case, so I think it would make sense to have this one be bundled in.
Once tests have been added, I'd be happy to give this PR a review so we can get it merged :)
@justinvdm dont blame yourself, I was quite busy too, and came back to you only now, months after planing to add handlebars support.
About extractors, I completely agree. I hesitate to add handlebars like I did. It adds handlebars to the project dependencies, and each extractor could make it grows. A plugin system could be nice, but I did not have the time to write one :p
About tests, I dont know yet how they could cover all cases. I might write some pretty simple and add others to prevent regression if some bugs are found later. I did a big template with some tortuous cases to generate a pretty big handlebars AST to work on when I started to write this extractor. It could be a start.
After that I plan to write a grunt jspot plugin, but I will wait for this to be reviewed merged & published ;)
@JSteunou Sounds like a plan.
If we could test similar things (where relevant) to what we test in js.test.js, I think that'd be great, unless there are reasons that I'm missing that will make this hard to do.
The hard part is covering all possible tags and tags inclusion configuration. What if a #unless
tag inside a #each
inside a else
made a non covered case?
It's quite odd and should not happen, but I had a surprise with the else
tag, handled with a inverse
property in the AST, that I nearly missed.
@JSteunou Ah, I see what you mean. Short of testing all the possible possible tag combinations, I can't think of a way we'd be able to do that. Maybe we could just have a test for checking that the extractor works for nested cases (maybe the test can have some heavy nested case, with the gettext call inside an #if
, which is inside a #unless
, which is inside an else
, which is inside an #each
). I'd be happy with that if you are?
@justinvdm tests added and commits rebased to clean up the logs ;)
\o/ awesome! will take a look as soon as I get a chance
This looks great :)
I'm not familiar with parsing the handlebars AST, but the extractor is really well tested and its implementation is clean and reads well. I'm going to go ahead and merge.
Thanks again for adding support for this!
@JSteunou just published v0.3.0 with this feature included :)
You're welcome, glad I could help on this project.
First step to issue #11
Missing tests and doc but working nice.
The gettext should be registered in Handlebars as an helper, and all derivate. Suppose you are using
i18n
In your template