Tapestry
  1. Tapestry
  2. TAPESTRY-1918

Tapestry's reload logic should be able to see additions, not just deletions and changes

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 5.0.6
    • Fix Version/s: 5.0.7
    • Component/s: tapestry-core
    • Labels:
      None

      Description

      Tapestry has change monitoring logic for templates, classes and properties files. However, that change logic is only aware of changes to loaded files, and of deletion of loaded files. It would be nice if Tapestry was aware of the folders containing tracked files, and was capable of identifying when files were added as well. This shows up in development, when creating a new page class in a running application still gives a "page not found" exception, because Tapestry is not aware of the new class.

        Activity

        Hide
        Howard M. Lewis Ship added a comment -

        A partial fix for this is to add the directory containing each file checked via URLChangeTracker. This isn't perfect: a file needs to be loaded from the directory before the directory is "checked" for changes, but this covers the majority of cases pretty well, I think. A perfect solution will require some significant juggling of the framework.

        Show
        Howard M. Lewis Ship added a comment - A partial fix for this is to add the directory containing each file checked via URLChangeTracker. This isn't perfect: a file needs to be loaded from the directory before the directory is "checked" for changes, but this covers the majority of cases pretty well, I think. A perfect solution will require some significant juggling of the framework.
        Hide
        Howard M. Lewis Ship added a comment -

        Again, this is a quick but not perfect fix but I'm satisfied that it will work for most people. The worst will be for message catalog files, as it is more common to go from 0 to 1 of those files (which may not be picked up) than to go from n to m of them (which is more generally what the fix detects).

        Show
        Howard M. Lewis Ship added a comment - Again, this is a quick but not perfect fix but I'm satisfied that it will work for most people. The worst will be for message catalog files, as it is more common to go from 0 to 1 of those files (which may not be picked up) than to go from n to m of them (which is more generally what the fix detects).

          People

          • Assignee:
            Howard M. Lewis Ship
            Reporter:
            Howard M. Lewis Ship
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development