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 <[EMAIL PROTECTED]> 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.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---
