-
Notifications
You must be signed in to change notification settings - Fork 226
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Slim Capture Html #68
Comments
Yeah, I agree: Tilt should contain information for capturing blocks and concatting to the buffer. That would make it possible to create framework-agnostic helpers. Any suggestions for how the API should be? |
I would absolutely agree that Tilt should support the idea of capturing and concatting to the buffer of all templates. As it stands, Rails basically has its own custom functionality for that and outside of Rails it is very hard to get this stuff working in a framework agnostic way. In Padrino, I have been having to work with the authors of Slim and Erubis to get this working. Once the next version of tilt comes out, we should have full Slim and Erubis helper support. I would like nothing more though then to strip out all of that logic from Padrino and be able to rely on tilt to give me concat and capture helpers for all the frameworks it supports. Take a look at the Padrino implementation to see how we are currently tackling this issue:
|
Thanks, those links will be very helpful! |
Yeah I am happy to work through getting this added to tilt if we all agree its worth the effort. Unfortunately I am aware that my current implementation of the handlers are a bit flimsy (hardcoded expectations of the output buffer). However, once we incorporate something similar into tilt, then we can rely on the output buffer specified when the engine is initialized which should address that issue. This gist should also shed some light on the bare minimum Padrino (and probably any rack based framework) would need to create all the usual helpers: |
Well, we can't depend on the output buffer only. It's technically an implementation detail, but more importantly: different engines might use different types of buffers. For instance, Slim uses an array buffer while ERB uses a string buffer. The default behavior of Tilt might assume one kind of buffer, but we'll have to make it a per-template-class-decision. I'm still wondering how big this change might be (and if it belongs to Tilt at all)… |
That's a good point. I think something that provides an agnostic way to uniformly capture/concat to template engines would be an awesome supporting library. I agree it is not clear whether it could live within tilt or as a separate gem. Would be curious to hear people's thoughts. |
We use dummy templates in sinatra-contrib to make capturing implementation independent: content_for.rb#L84-88 |
Yep, I agree with u @rkh, your way is dead simple and more stable. Should be a feature of next version of tilt. |
I have to say, I don't get the use case for concatenation, if you support (and use) capturing. |
@rkh to display this how do you do?
I know we can use |
I think Rails 3 uses |
Yep, sure that have more sense, but a lot of coders uses the old way especially with haml. |
@rkh, Rails uses |
oh, right, |
@rkh, we can drop it on sinatra/padrino :D ? |
Not is Sinatra, no. I see two solutions: Support concatenation, but just for But you'd probably have to modify erubis, too: http://timelessrepo.com/block-helpers-in-rails3 @judofyr what's your take on concatination? |
@rkh, I see yesterday the Rails hack and is horrible ... IMHO. I prefer the ...old way..., but, it's a lot of years that I don't use erb like things. |
An option would be something like this: def output(content)
return content unless @current_engine == :erb
concat content
"" # so it still works with <%= %>
end
def form_for(&block)
output "<form>#{capture(&block)}</form>"
end And implement concatenation for erb only. |
Any idea when something like this will be integrated with Tilt? I'd really like to get content_for working for Slim on Serve (http://github.com/jlong/serve). |
My guess is probably not soon, it is difficult problem to solve in a uniform way. We ended up solving it ourselves good enough in Padrino although I still would love for concat/capture to be something any framework could use |
Isn't there someway to add limited support for this? Get it working, then make it right? The main thing I want is to get content_for working. |
@jlong: I took a look at serve and I think you only have to add a trivial capture_slim helper.
Slim has an automatic capturing mechanism. The block returns the captured content.
As an alternative you can also configure slim so that it behaves like erb (buffer variable name - option :buffer, disable automatic capturing - option :disable_capture). Please tell me if it works. |
any news on this? |
I don't see an easy way to accomplish this with the current abstraction. Tilt only defines a I'm closing this. Please open a new issue if you have a specific proposal for how we can solve this in Tilt (hint: I don't it's possible, but please prove me wrong). |
Is there any suggested strategy for getting the ball rolling on this. Could we not implement support for the template engines that DO support this. If the provisions are made, template engine maintainers would receive more pressure to implement support. |
Can I also ask how you would imagine ERB making this easier? You can't really change the behaviour of blocks within ERB templates as they're used extensively for #each loops and so on. Capturing the output buffer is really the only means I can think of. ERB can't exactly provide a |
As for erb and erubis can you give us the ability to capture html? Take a look here: https://github.com/stonean/slim/commit/74f1125846aed72dbdbd5cba51b762f69e1c6a5c
The text was updated successfully, but these errors were encountered: