-
-
Notifications
You must be signed in to change notification settings - Fork 185
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
Gon's Jbuilder partial! pathing differs from standard #54
Comments
Thank you for response! All clear here, I'll fix it right when have some time to do opensource) Hope will do it soon. |
Thanks! Sorry I couldn't submit a patch for it, wasn't quite sure what else Gon was doing, and how to ensure the context was setup correctly. |
Fixed. Soon will be release of 4.0.0 |
This is still not fully fixed. Partials only works with jbuilder syntax that specify directory and passed variable:
But will not work with alternative short hand syntax for jbuilder that uses default folder structure and file naming (assuming same files and folders as specified above):
|
@gazay thanks heaps for the partial (hurr) fix, in any case! |
I'm looking at 7c05c6e and I don't want to be nit-picky, but should Gon be parsing the partials at all? Seems to me like Gon should set up the environment and then delegate directly to jbuilder and let it do all the partial resolving. Otherwise you are basically going to be stuck re-implementing jbuilder's code, with bugs turning up every time Gon's approach differs from jbuilder's approach. I reckon @mroseboom's issue might be solved in this approach. I recognise that "set up the environment" is pretty hand-wavey, and ultimately there might be a good reason not to do it this way, but I'd be interested to know your thoughts. |
An example: I'd like to do this in a controller:
Where
and
But when I try it, I get: I'm pretty sure this is a parsing bug, but I'd rather see Gon lean on jbuilder for parsing than have it patched in Gon, if you take my meaning. Not sure if this helps! |
I'm sorry, but I'll be on vacation soon. So if you'll do some research and do pull request - it will be super great!)) I want to comeback to maintain this gem after vacation - 2-3 weeks, but I glad that you use this gem and try to find some capabilities to use it :) If you'll share to me your experience of usage this gem I'll can do my work better Thank you) |
Having the same issue over here, so this was never fixed? @gazay is there any particular reason that gon does its own parsing of the partials? It seems to me that that should be left to the jbuilder (or rabl, etc.) gem itself... |
Because of architecture of jbuilder. It is replaces flow of usual rendering, so it allow you to render only once through controller action. That's why I have to partially replace jbuilder functionality (in Rabl I can simply call Rabl::Engine#render method). But it was a year ago - maybe now there is a different situation and if you can help with research - it will be super awesome. Anyway thank you that you somehow interested in gon and find time to write me some response! |
It looks like Gon's Jbuilder module attempts to do its own partial evalutation before passing the result to Jbuilder. This means that only root-level paths are allowed for partials used via a
gon.jbuilder
call, which is non-standard.For example,
gon.jbuilder
requires something like:partial! "app/views/widgets/_widget.json.jbuilder"
Jbuilder itself accepts one of the following:
partial! "widgets/widget"
partial! "widget"
Because these two methods differ, they are incompatible. Gon jbuilder partials cannot be used independently of Gon.
The best solution would be to remove any custom Gon partial evalutation and find a way to call
JbuilderTemplate.encode
with enough context for Jbuilder to resolve its own partials.A workaround that we are using looks like this:
As you can see, it's pretty horrible and I'm sure there is a smoother workaround, but ideally we could just use the
gon.jbuilder
method directly.I hope this is enough detail to explain the problem; let me know if anything is unclear!
The text was updated successfully, but these errors were encountered: