Skip to content
This repository

Loading extensions before Padrino::Rendering #541

Closed
nesquena opened this Issue May 21, 2011 · 45 comments

4 participants

Nathan Esquenazi Davide D'Agostino James C Russell Bernerd Schaefer
Nathan Esquenazi
Owner

Overflow from #534 . What should we do about this? I.E

@botanicus:

Thanks a lot, I'm trying to take a look, unfortunately on Padrino HEAD I have a different problem, not really a bug, but an implementation thing which makes it impossible to register first TemplateInheritance::Rendering and then Padrino::Rendering ... I'm just on IRC asking for help, once this will be addressed, I'll check if this work. Thanks for a very quick response!

@nesquena:

yes, exactly. May I suggest to make registering Padrino::Rendering (currently in padrino-core/application.rb) user responsibility? So when a user would generate a new app, he would get http://pastie.org/1928277 Apart of that that I believe is better solution (not everyone needs rendering really), it'd easily solve my problem with registering modules in the right order. Or to have some base class, sth like Padrino::BaseApplication.

Basically he wants to hook into render before the Padrino rendering module is loaded. How do we address this?

Nathan Esquenazi
Owner

@daddye Should we deal with this in this release or push to next?

Davide D'Agostino
Owner
DAddYE commented May 22, 2011

Next

Nathan Esquenazi
Owner

Ok figured...

James C Russell

If I may, the adapter for Padrino in template-inheritance works in 0.9.28 and regardless of implementation details, I'd really appreciate if it could work in 0.9.29 as well. Otherwise it'd be me who'll get bug reports about not compatible plugin and I'd have to "if" for Padrino versions and do something else for 0.9.29 (not that I'd know how to fix it on current Padrino HEAD, but I'd have to do something about it ... ), so please guys, if you can, fix it now. Cheers.

Davide D'Agostino
Owner
DAddYE commented May 22, 2011

Ok, @nesquena, can u do that?

Nathan Esquenazi
Owner

@daddye, what do you recommend we do about this? I'm not sure the best way to approach solving this or why it worked in 0.9.28? Will move it back for now

Davide D'Agostino
Owner
DAddYE commented May 22, 2011

A momentan patch:

  class Application < Sinatra::Base
    register Padrino::Routing
    register Padrino::Rendering unless defined?(SKIP_PADRINO_RENDERING)
Nathan Esquenazi
Owner

You want us to add in that hack patch and then botanicus would set the constant in his extension? I guess that could work, seems a bit of a hack though, don't you think? Maybe we should move the register's down later and then check an option? Anyway we can achieve:

class Demo < Padrino::Application
  disable :padrino_rendering
  register TemplateInheritance::Rendering
  register Padrino::Rendering
end

What do you think, is that easily possible? A good idea?

Davide D'Agostino
Owner
DAddYE commented May 22, 2011

my patch is super secure.

This need to be a bit tested because we need to move Padrino::Rendering in register_initializers

Nathan Esquenazi
Owner

Fair enough, I tried my way and there were still some failing tests. This way seems a bit hacky but it is OK for now: a9dc6f3

Now to get it to work just have to do:

SKIP_PADRINO_RENDERING = true

before the creation of the Padrino application and then we would need to put:

class Demo < Padrino::Application
  register TemplateInheritance::Rendering
  register Padrino::Rendering
end

Despite being a bit hacky, does this work for now @daddye @botanicus?

Davide D'Agostino
Owner
DAddYE commented May 22, 2011

We have few time right now and I agree is horrible we will try to do something better in future releases.

Davide D'Agostino
Owner
DAddYE commented May 22, 2011

Nate:

def before_render(&:block)
  (@_before_render ||= []) << block
end

def render( ... )
  @_before_render.each(&:call)
end
Davide D'Agostino
Owner
DAddYE commented May 22, 2011

@botanicus can do:

Padrino::Application.before_render do
   ... do some ...
end
James C Russell

SKIP_PADRINO_RENDERING is great, it's hacky but it works and it's what matters. BTW if we are postponing it, then maybe we can drop registering of Padrino::Rendering in the next bigger release :) ? Just a suggestion, I don't want to interfere, but you know my opinion on registering rendering by default and I believe it would make things easier.

James C Russell

@DAddYE sorry, I'm not following, how could before_render help?

Nathan Esquenazi
Owner

I think he was going for

Padrino::Application.before_render do
  register TemplateInheritance::Rendering
end

Right @daddye? I think this is actually more confusing naming and more work then the constant. Maybe in a future version we can figure out a better approach but I am OK with hacky SKIP_PADRINO_RENDERING constant for now.

@botanicus I don't have any problem with removing the auto register of Padrino::Rendering except for that it would break every single Padrino application in previous versions and it would not be obvious how to fix it unless you were careful to read a blog post. Maybe if we could get the console to print out a suggestion to include it when the error occurs...

Davide D'Agostino
Owner
DAddYE commented May 22, 2011

Ok, for the constant!

Nathan Esquenazi
Owner

@daddye @botanicus I am thinking about it, maybe for 0.10.0 we could remove the auto registration of Render. I mean it is a point release finally, if we were ever going to do it, then it would be here. We did the same thing for Padrino::Helpers and I think it is a good thing to allow people to strip away functionality they don't need. Demonstrates how modular our system is...

Nathan Esquenazi
Owner

Moving this ticket to 0.10 since SKIP_PADRINO_RENDERING works for now.

Davide D'Agostino
Owner
DAddYE commented May 22, 2011

My employes need to edit thousand sites, but 100% agree.

Nathan Esquenazi
Owner

Great then for 0.10.0 then barring any serious issues not to, we can remove the Padrino::Render and move into the generator. I think this is a good idea going forward and again demonstrates the powerful (take what you need) modularity of our system.

James C Russell

Great, cheers a lot guys! BTW there's a clever functionality of RubyGems, Gem::Specification#post_install_message=(msg) (i. e. https://github.com/botanicus/ace/blob/master/ace.gemspec#L48), which allows us to set a message which is displayed once someone installs the gem. I'm using it for printing CHANGELOG using the changelog gem (i. e. https://skitch.com/botanicus/fy246/rubygems-post-install-message), so we can use it to tell users to register rendering themselves. Easy-peasy and with using the right colours no one can miss it ;)

Nathan Esquenazi
Owner

Good suggestion, maybe we should print a post-install message for 0.10 explaining the issue and pointing to the blog post... Thanks botanicus for helping us identify and simplify the register process even more.

Nathan Esquenazi
Owner

@daddye Created a branch here: df833ca with Padrino::Render becoming explicit. Look ok?

Davide D'Agostino
Owner
DAddYE commented May 23, 2011

Yesse!

Nathan Esquenazi nesquena referenced this issue from a commit May 23, 2011
Commit has since been removed from the repository and is no longer available.
Nathan Esquenazi
Owner

@botanicus Thanks for the post install message tip, added one of those as well. I think the patches in that rendering-remove would close this issue, right?

Nathan Esquenazi nesquena referenced this issue from a commit May 23, 2011
Commit has since been removed from the repository and is no longer available.
James C Russell

@nesquena amazing, that's all I need :) ! Cheers!

Nathan Esquenazi
Owner

Great, will close this once we can merge the branch into master

Davide D'Agostino
Owner
DAddYE commented June 05, 2011

@nesquena I think we are ready to add this. Can u do that?

Nathan Esquenazi
Owner

Yeah I will soon.

Davide D'Agostino
Owner
DAddYE commented June 06, 2011

@nesquena can u do that before the release?

Nathan Esquenazi
Owner

I'd like to do this in the subsequent release along with locking to Sinatra 1.3 once that is released (soon). Unless that's released in next few days and then we can incorporate that to this release.

Nathan Esquenazi
Owner

Merged into master now. Can you guys confirm it works and post install message is OK @daddye @botanicus

Nathan Esquenazi
Owner

Does this work for you guys? Can we close?

James C Russell

It does work. Cheers guys!

Nathan Esquenazi
Owner

Ok thanks! closing...

Nathan Esquenazi nesquena closed this June 09, 2011
Bernerd Schaefer

I wonder if there's another way this can / should be communicated, since bundler does not show post install messages. It took a lot of digging to figure out what had changed between 0.9.29 and master before I found this issue!

Nathan Esquenazi
Owner

Excellent point, that does strike me as a problem. We need to figure out a way to communicate this more effectively. @daddye What do you think?

Davide D'Agostino
Owner
DAddYE commented July 01, 2011

We can add a the same warning into padrino-core.rb class? Some like:

puts colored_warning unless App.respond_to?(Rendering) && !App.respond_to?(:skip_rendering) # last for those that don't wanna see it
Nathan Esquenazi nesquena reopened this July 01, 2011
Nathan Esquenazi
Owner

Yeah I think a warning that prints in the app itself would be more helpful, good idea

James C Russell

What does App.respond_to?(Rendering) mean? I'd check for instance method render, so it's agnostic to any rendering mechanism.

Nathan Esquenazi
Owner

Ok I took a relatively safe approach here: bb73d92 and basically lazy load this rendering module (with a deprecation notice) when I detect the rendering exception is about to occur. If the user a) never uses the render method with one argument and b) the rendering module has not been included then the message will print and the module is loaded. Can you guys take a look and basically tell me if that seems OK. I am going to hold the release until I get an OK @daddye @botanicus . I figure most cases the error will occur like this:

class Demo < Padrino::Application
  # no inclusion of rendering module

  get "/" do
    render "foo" # uses padrino style rendering
  end
end
James C Russell

So if he includes my rendering module, he'll get render from there, otherwise he'll get this. Yes, that does make perfect sense.

Nathan Esquenazi
Owner

That was the intention, yes. Do you guys think this will work alright for the release?

Nathan Esquenazi
Owner

Alright tested and closing

Nathan Esquenazi nesquena closed this July 07, 2011
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.