# TemplateHandler API revision **URL:** \ **Category:** rubyonrails-core\ **Created:** [July 16, 2008, 4:13pm UTC](https://discuss.rubyonrails.org/t/templatehandler-api-revision/31930 "2008-07-16T16:13:03Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Josh\_Peek](https://avatars.discourse-cdn.com/v4/letter/j/d9b06d/32.png) [@Josh\_Peek](https://discuss.rubyonrails.org/u/Josh_Peek)\ **Post date:** [July 16, 2008, 4:13pm UTC](https://discuss.rubyonrails.org/t/templatehandler-api-revision/31930/1 "2008-07-16T16:13:03Z")
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? ---
**Author:** ![Nathan\_Weizenbaum](https://avatars.discourse-cdn.com/v4/letter/n/e47c2d/32.png) [@Nathan\_Weizenbaum](https://discuss.rubyonrails.org/u/Nathan_Weizenbaum)\ **Post date:** [July 17, 2008, 2:32am UTC](https://discuss.rubyonrails.org/t/templatehandler-api-revision/31930/2 "2008-07-17T02:32:35Z")
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. > 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. ---
**Author:** ![Josh\_Peek](https://avatars.discourse-cdn.com/v4/letter/j/d9b06d/32.png) [@Josh\_Peek](https://discuss.rubyonrails.org/u/Josh_Peek)\ **Post date:** [July 17, 2008, 4:52pm UTC](https://discuss.rubyonrails.org/t/templatehandler-api-revision/31930/3 "2008-07-17T16:52:00Z")
> 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 😉 ---
**Author:** ![Nathan\_Weizenbaum](https://avatars.discourse-cdn.com/v4/letter/n/e47c2d/32.png) [@Nathan\_Weizenbaum](https://discuss.rubyonrails.org/u/Nathan_Weizenbaum)\ **Post date:** [July 17, 2008, 7:55pm UTC](https://discuss.rubyonrails.org/t/templatehandler-api-revision/31930/4 "2008-07-17T19:55:23Z")
Okay, cool, that sounds good.