Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Considerations for future Tilt releases #425

Closed
judofyr opened this Issue · 5 comments

2 participants

@judofyr

Hey folks,

I'm the current maintainer of Tilt and Sprockets is an important user of Tilt. I wanted to write this issue to get some feedback on how you think Tilt could improve.

First of all, the current roadmap looks like this:

  • 1.3: We're going to continue fixing regressions that occurred after the 1.3.4 release (see CHANGELOG.md.
  • 1.4: Tilt sorely needs better encoding support. We're working on a minimal encoding support in rtomayko/tilt#175 that's going to be included in 1.4.
  • 2.0: It's becoming difficult to maintain all the template classes inside of Tilt so for 2.0 we want to define a proper public API and push towards moving template classes into to separate gems (hopefully together with the template engines).

I see that you're depending on tilt ~> 1.1. This is good (since your users would get the improved encodings support), but it would be even better if you could try out the minimal-encodings-branch (see rtomayko/tilt#175) and report any issues/thoughts.

I'm also wondering what features of Tilt you're using, and how you think they could be improved in Tilt 2.0:

  • Are you defining your own template classes? How is this working out? Are you satisfied with the API? If you're using Ruby precompiling: Have you ever used custom preamble/postambles?
  • Are you using the default_mime_type-feature? Is it important that his is per template class, or could this be a method on the template-object?
  • Are you using #allows_script?

Thanks for your time!

(Linking this up with rtomayko/tilt#172 for reference)

@judofyr

Hello? Is this thing on?

@josh

Sorry, @judofyr, I'm not sure how I missed this.

2.0: It's becoming difficult to maintain all the template classes inside of Tilt so for 2.0 we want to define a proper public API and push towards moving template classes into to separate gems (hopefully together with the template engines).

We're split on relying on tilt for template classes. I'll probably just vendor all the ones I need in sprockets itself.

https://github.com/sstephenson/sprockets/blob/master/lib/sprockets.rb#L92-L107

Are you defining your own template classes? How is this working out? Are you satisfied with the API?

If you're using Ruby precompiling: Have you ever used custom preamble/postambles?

Precompiling doesn't matter for sprockets usage since the input data is dynamic, so we can't cache the template reference afterwords.

Are you using the default_mime_type-feature? Is it important that his is per template class, or could this be a method on the template-object?

I think I actually added that to tilt because of a sprockets use case. I think it makes sense most on the template klass since its not dependent on any template data.

https://github.com/sstephenson/sprockets/blob/37e80b651935ed5388abeacc35bf4c6ffc10bd8f/lib/sprockets/asset_attributes.rb#L112-L123

Looking at that example, given a filename foo.coffee.erb, we can imply the content type is application/javascript. .erb carries no default miem type.

This is good (since your users would get the improved encodings support), but it would be even better if you could try out the minimal-encodings-branch (see rtomayko/tilt#175) and report any issues/thoughts.

I'm curious about the encodings stuff. Right now, we basically implement our own file reader and pass data directly to tilt's reader.

https://github.com/sstephenson/sprockets/blob/master/lib/sprockets/utils.rb#L4-L50

Also, the way we do multiple tilt extensions is interesting. foo.coffee.erb applies erb, then passes the result to the coffee compiler. You can chain any arbitrary tilt handlers together.

https://github.com/sstephenson/sprockets/blob/master/lib/sprockets/context.rb#L194-L202

@judofyr

The reason I asked about default_mime_type: I'm thinking about moving the information to a general Hash. Right now we have both .default_mime_type and #allows_script? and I was hoping there was a way to unify them. If we put it at class-level it can only be used for querying class-specific details; if it's at instance-level the template engine could poke into the template.

I'm not quite sure what the Hash should be called either (template_class.metadata?)

I'm curious about the encodings stuff. Right now, we basically implement our own file reader and pass data directly to tilt's reader.

See here for documentation for Tilt users: https://github.com/rtomayko/tilt#encodings

The other part of encoding support is ensuring that we use the correct encoding when we precompile into a method: https://github.com/rtomayko/tilt/blob/a80ce035be67c1439f4d1d7b4ac64c4f557a9e71/lib/tilt/template.rb#L190

@josh

If we put it at class-level it can only be used for querying class-specific details; if it's at instance-level the template engine could poke into the template.

Sure. Having Klass.metadata and Klass#metadata would be great. By default the instance can just inherit the class options.

@josh

As of #516, the Tilt dependency has been removed.

@josh josh closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.