A few things have already changed.
* TemplateHandler#cache_fragment has been remove. Ensure your template
handler sets a @output_buffer if you want the cache helper to work.
aca246a
* I had to change the method signature for TemplateHandler#render to
take a local_assigns argument since template.locals is no longer
available. 6ebdd0e
* TemplateHandler is initialized with view set to nil when it is
compiling. "ERBHandler.new(nil).compile(template)"
I'd really like deprecate the TemplateHandler#render all together. If
you think your handler can not be compiled, you always just compile in
a delegate call to your "noncompilable" handler. This leaves us with
only one method, compile.
The current state is pretty hacky to attempt to preserve some kind of
"compatibility". It be nice to scrap the current setup and try
something fresh that would fit in better.
A proposed API
Template.register_extension :erb, lambda { |template|
ERB.new(template.source).src }
Any other ideas? Also, what problems have you had to deal with the
previous implementation?
on 16.07.2008 18:13
on 17.07.2008 04:54
Checking in from the Haml camp :-). In general, I'm most happy when nothing changes. Haml has to support each version of Rails, so the more changes are made the more nasty the code gets. From a development perspective, the API as of 2.1.0 was fine; anything divergent from that is just annoying. On Jul 16, 12:13 pm, Joshua Peek <j...@joshpeek.com> wrote: > A few things have already changed. > > * TemplateHandler#cache_fragment has been remove. Ensure your template > handler sets a @output_buffer if you want the cache helper to work. > aca246a Haml doesn't set @output_buffer, but it does override the output_buffer and set_output_buffer helpers (specifically because we don't want to have to figure out when to set @output_buffer). If cache_fragment uses those, it should work fine. It won't be a problem if Haml's TemplateHandler subclass still defines #cache_fragment, will it? > * I had to change the method signature for TemplateHandler#render to > take a local_assigns argument since template.locals is no longer > available. 6ebdd0e Sure, Haml doesn't override #render anyway. > * TemplateHandler is initialized with view set to nil when it is > compiling. "ERBHandler.new(nil).compile(template)" Nor does it override the constructor. > I'd really like deprecate the TemplateHandler#render all together. If > you think your handler can not be compiled, you always just compile in > a delegate call to your "noncompilable" handler. This leaves us with > only one method, compile. Sounds good to me. > The current state is pretty hacky to attempt to preserve some kind of > "compatibility". It be nice to scrap the current setup and try > something fresh that would fit in better. > > A proposed API > > Template.register_extension :erb, lambda { |template| > ERB.new(template.source).src } As I mentioned above, I really like compatibility. The proposed API isn't so bad, since I can just call compile on the TemplateHandler subclass I've got lying around, but I'd prefer to have register_template_handler keep working. > Any other ideas? Also, what problems have you had to deal with the > previous implementation? Again, the main problem is incompatibility. Every time compatibility breaks, we need to roll out a new version, so if someone updates their Rails version they need to update Haml as well. We end up with support requests and users end up with broken apps... it's just no fun all around.
on 17.07.2008 18:52
On Jul 16, 9:32 pm, Nex3 <Nex...@gmail.com> wrote: > Haml doesn't set @output_buffer, but it does override the > output_buffer and set_output_buffer helpers (specifically because we > don't want to have to figure out when to set @output_buffer). If > cache_fragment uses those, it should work fine. If you overriding output_buffer, that will have the same effect. > As I mentioned above, I really like compatibility. The proposed API > isn't so bad, since I can just call compile on the TemplateHandler > subclass I've got lying around, but I'd prefer to have > register_template_handler keep working. I totally understand. I may make some of those other minor adjustments, but I'll be sure to leave the TemplateHandler#compile intact so you don't have to change anything ;)
on 17.07.2008 21:58
On Jul 17, 12:52 pm, Joshua Peek <j...@joshpeek.com> wrote: > > isn't so bad, since I can just call compile on the TemplateHandler > > subclass I've got lying around, but I'd prefer to have > > register_template_handler keep working. > > I totally understand. I may make some of those other minor > adjustments, but I'll be sure to leave the TemplateHandler#compile > intact so you don't have to change anything ;) Okay, cool, that sounds good.