GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Already on GitHub? Sign in to your account
I got feeling that solution for #1951 are incorrect by nature. We include path namespacing in partial so even if we define custom resolver or just modify append_view_path we can't avoid namespacing. I am not sure how to fix this, but for my needs (defining one partial template for front/backend of my application using to_partial_path) this simple fix works.
Absolute partial paths need to be preserved in namespace
@bopm Thanks for the pull request.
I must admit the partial lookup rules today are ultimately fucked up. We are trying to be too smart, which means that, for anyone to actually understand how a partial is rendered, he needs to at least answer 3 or 4 questions:
Since Rails 4 is coming, I would like to simplify how partials are rendered. In my opinion, we have two simple approaches:
Make all partials by default absolute. Therefore, when you pass render :partial => "form", it will try to render form in app/views. We could force a relative lookup by prepending "./".
Make all partials by default relative. Therefore, when you pass render :partial => "posts/post", it will try to render it relative to the current controller. You would be able to get an absolute path by prepending a "/".
The first alternative seems to be more disruptive to me and therefore I like 2) more. Regardless, the nice thing about any of these approaches is that the object being rendered will be able to specify if it wants a relative or absolute lookup and it is no longer intrinsic to the name.
I can prepare a patch myself, but I would like some feedback before. /cc @jeremy
I prefer the option 2).
👍 for making this simpler, and #2 as a solution.
So, is this ever going to get accepted, @josevalim, or not? I think if I'm reading you right, the answer is no.
Also, do we decide to implement one of the options that @josevalim mentioned? There is also a related ticket #1143, that mentions adding ./ as a way to use relative path.
While I like the idea of making things simpler, this would unfortunately break almost all of the apps and would make the update to 4.0 much harder. That's why I would vote to implement #1143 (I think it will be quite easy to add, I can implement if it's the way to go).
also, /cc @carlosantoniodasilva @rafaelfranca @jeremy @spastorino @fxn
Hmm I like @josevalim option 2). But I see that we will be breaking apps.
Could be nice if we can list which use cases would break if we apply José's solution.
@drogus if #1143 make easier to upgrade I vote to implement it.
@rafaelfranca after thinking about that I would implement it, then deprecate the old behavior and release a plugin that changes the behavior for the new one, so people can upgrade before 4.1. That way, we will deprecate in 4.0 and give people easier path to upgrade (so they can prepare everything before 4.1 comes out). Sounds good?
of course when I wrote deprecate, I meant, deprecate in 4.0.
I will try to come up with a pull request and we will see how it looks like :)
Amazing that this has never received the attention that it deserves. I created a partializer gem in order to facilitate the partials path hell, when going beyond one nested level of partials. I don't like any file to be much more than ~60 lines, then I discovered Cells which is a much nicer solution. The views/partials in Rails is still such a primitive solution and something like Cells (or apotomo) really ought to be built into Rails IMO. Most MVC frameworks suffer from a lack of proper view partitioning. I recall an even worse nightmare on the Java stack. Time to make Rails a little more mature, no?
Option 2 gets my 👍
There needs to be some way to force an absolute lookup for namespaced partials, to_partial_path is essentially being ignored in namespaces.
It seems that everyone is interested in option 2, and with the intention not to break people's apps, I'm giving this a close. An implementation of option 2 would make a great new PR though. :)
Any news on this? Has anything been implemented? I can still not get relative paths working properly when partial nesting is deeper than one level.
@ncri, you can try my "partializer" gem, which allows for a different approach to achieve this.
Thanks, I'll try that. Would be nice though if one doesn't have to rely on a gem to simply have relative partial access from the render method.