Consider removal of Rails support about liquid HOT 8 CLOSED

My 2 cents, tobi

Generally I agree with your argument. Furthermore, I assume that most people would use Liquid by hand in their controllers, not exactly as an ActionView Template Handler (eg erb or haml)

If that's your line of thought then I think you are right. However, since changing that would effectively be a breaking change I believe it should be part of a larger liquid 3.0.0 roadmap.

Finally, assuming I got your point right, I think that removing init itself might not be the necessary. Just the handler part, leaving it to require liquid lib only.

Best regards,
DBA

from liquid.

yes this is what I have in mind. Great to have your +1.

from liquid.

You guys at shopify have something in mind for liquid 3.0? :)

from liquid.

Got liquid 3 party started at: http://groups.google.com/group/liquid-templates/browse_thread/thread/d6c13a75a3768b18

Hope people participate with their inputs ;)

from liquid.

That seems like a heavy handed approach for what sounds like essentially an education issue. I've found liquid to be a great addition to a few different rails projects, precisely because of it's intended purpose. No, it's not a general purpose replacement for erb, nor does it seem to be presented as one. But just because I have some developer/designer crafted pages in a project doesn't automatically mean I want to prevent end users from creating content. Conversely, having end user created content doesn't necessarily mean I have no use for developer designed templates.

There are plenty of template languages available that work with rails, but none of the others that I've run across are designed to be exposed to a wider audience (and survive). Whether or not it plugs into ActionView in precisely the same way as the general purpose templates is just an implementation detail. But losing (or at least significantly complicating) liquid template use in a rails site would be a very sad direction for liquid to go.

from liquid.

I'm in the same situation as being described in this thread -- using liquid in a "hostile" environment (multi-tenant rails app, where the tenants can change views). The Liquid templates themselves are stored in the DB, and I was investigating whether writing a custom template resolver (to fetch the template from the DB) and a custom template handler (to actually render the liquid template) makes sense.

@tobi -- in your post above, you feel having a template liquid handler does not make sense. Would it be possible for you to explain why? It might not be obvious to someone (me, in this case!) who is tackling this problem for the first time.

from liquid.

Spend the last hour looking at ActionView::Template Is the reason why Liquid templates and Rails templates handlers don't mix well because Rails compiles the template into actual Ruby code which is then evaled in the same process/memory-space as the app. This is precisely what Liquid is trying to avoid -- any sort of code injection into the host app.

from liquid.

is there more in terms of dependencies to rails despite the init.rb and the usage of ActionView::Helpers::TagHelper ?

i think that nowadays it's more common to install gems instead of using rails plugins. so i think that removing the rails stuff would be fine. if anyone want's to have it, you could go for a liquid-rails.gem like it's done with many other template languages.

from liquid.