This project is archived and is in readonly mode.

#2012 ✓resolved
Andrew White

Templates are not reloaded in development when using custom view path

Reported by Andrew White | February 19th, 2009 @ 12:45 AM

If you are using a custom view path, e.g:


class ShopController < ApplicationController

  prepend_view_path "custom/view/path"

  def index
    ... do something
  end

end

then template changes are not reloaded in development mode because the view paths are reprocessed on every request due to the controller being reloaded. In production mode the template changes are reloaded because the controller is cached.

Comments and changes to this ticket

  • thedarkone

    thedarkone February 19th, 2009 @ 01:16 AM

    Andrew, thanks for investigating the issue and posting a detailed description in #1909 . I would have sworn that prepending_view_paths should not have been causing any problems whatsoever.

    0001-Fix-an-edge-case-where-we-might-encounter-some-rando.patch gives up on manually tracking compiled methods and just greps CompiledMethods.public_instance_methods for any suspects to undef.

  • josh

    josh February 19th, 2009 @ 02:10 AM

    • State changed from “new” to “open”
    • Milestone cleared.
  • thedarkone
  • josh

    josh February 19th, 2009 @ 02:46 AM

    Do you guys have any wild ideas how we can test the development reloading better? It seems like these issues continue to regress.

  • thedarkone

    thedarkone February 19th, 2009 @ 03:59 AM

    Well there are a few issues with reloadable templates.

    1. It is a tricky thing to implement correctly, the are a lot of little nuances that you need to cover (what happens if a I delete a template, what if I rename it, what if I just change an extension, what if I pass different locals, etc.)

    2. ActionView is not written to be reloadable-template friendly. I took a peek at Rails 3 code base and things will get better there.

    3. You can't really unit test it very well as it would require an exponential amount of tests (think about it as every unit test you already have in ActionView multiplied by all the edge cases mentioned in the first point).

    Not all is as gloom and hopeless though.

    1. This is really the first regression since it got commited (I don't think anything serious is going to come out of #2005).

    2. The code has been extracted out of a plugin, that has seen some testing. I did test just this case and there were no issues because that was in a context of rails-dev-boost, where classes are not reloaded unless they've changed, so it behaved like a production environment. That's why I missed this.

    3. The whole reloadable_template.rb is 120 LoC with something like 40 LoC of a real code. So it's not like we're talking about some dark impenetrable voodoo stuff like routes or constant loading.

  • Manfred Stienstra

    Manfred Stienstra February 19th, 2009 @ 08:35 AM

    It is a tricky thing to implement correctly […]

    That's exactly why you want to write tests for this. The original authors are the only ones who know how it currently works, and they will forget. In a year or even a few months no-one will know how this is supposed to work, with tests anyone can stay contributing.

    You can't really unit test it very well as it would require an exponential amount of tests (think about it as every unit test you already have in ActionView multiplied by all the edge cases mentioned in the first point).

    Sure you can, shared test are easy, just define them on a module and include then in a number of TestCases with different setups.

    The whole reloadable_template.rb is 120 LoC with something like 40 LoC of a real code. So it's not like we're talking about some dark impenetrable voodoo stuff like routes or constant loading.

    Short pieces of code require less testing code, yet constant reloading and routing are tested, so that's actually an argument for testing.

  • thedarkone

    thedarkone February 19th, 2009 @ 07:48 PM

    Manfred, thank you for your suggestions, I know you are trying to be helpful.

    0001-Fix-regressions-that-have-popped-up.patch - dropped expand_path, this should fix #2005, also added a few more tests.

  • Repository

    Repository February 20th, 2009 @ 02:56 AM

    • State changed from “open” to “resolved”

    (from [f8ea9f85d4f1e3e6f3b5d895bef6b013aa4b0690]) Fix templates reloading in development when using custom view path [#2012 state:resolved] http://github.com/rails/rails/co...

  • josh

    josh February 20th, 2009 @ 04:46 PM

    • State changed from “resolved” to “open”

    Failing ActionMailer test: http://ci.rubyonrails.org/builds...

  • thedarkone

    thedarkone February 20th, 2009 @ 05:17 PM

    I hate mailer and railties test suites.

  • josh

    josh February 20th, 2009 @ 06:06 PM

    As do I :)

    But is that correct? It seems like that test is explicitly removing the "./", maybe for a good reason? I really have no idea.

  • thedarkone

    thedarkone February 20th, 2009 @ 06:46 PM

    No worries, this exact explicit removal was introduced by me in a an early patch :). It is related to how I was normalizing/expanding view paths (that didn't go all to well on windows, so it is no longer being done).

    Besides if we are talking about directory structure "test/fixtures/path.with.dots" and "./test/fixtures/path.with.dots" are AFAIK equivalent.

  • josh

    josh February 20th, 2009 @ 08:20 PM

    • State changed from “open” to “resolved”
  • csnk

    csnk May 18th, 2011 @ 08:30 AM

    We are the professional clothing manufacturer and clothing supplier, so we manufacture kinds of custom clothing manufacturer. welcome you to come to our china clothing manufacturer and clothing factory.

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

<h2 style="font-size: 14px">Tickets have moved to Github</h2>

The new ticket tracker is available at <a href="https://github.com/rails/rails/issues">https://github.com/rails/rails/issues</a>

Referenced by

Pages