You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Howard Lewis Ship <hl...@gmail.com> on 2013/07/23 20:56:00 UTC

Re: Tapestry 5.4 Bug

This is very problematic, as cache-busting is exactly the opposite of
everything else Tapestry's asset pipeline is doing.

Is this something you see only in testing, or also in production? (or
integration testing?)

If you are using Geb, one thing that might help is:

        waitFor { $("body").getAttribute("data-page-initialized") == "true"
}

The data-page-initialized attribute is set after Tapestry has executed all
of the page inits, which can't happen until after all modules have been
loaded.

What does James Burke (RequireJS author) say about this?



On Tue, Jul 23, 2013 at 11:22 AM, Dimitris Zenios <dimitris.zenios@gmail.com
> wrote:

> Ho howard please have a look at this bug.In my opinion its a 5.4 blocker
> bug.
>
> I have been using tapestry 5.4 since alpha 3.Its quite stable.The only
> problem i have found until now is that sometimes when refreshing pages to
> frequently javascript does not work with random errors of undefined.Even
> after page loads ok.It looks like that require.js is stopped while
> downloading a module through refresh and the next time it gets the
> corrupted js  file instead of a freshly new.The only way to fix it is to
> clear the cache.Others reported this problem regarding require.js caching
> also and suggested to append a value to each of the script urls for cache
> busting.
> http://stackoverflow.com/questions/15803021/requirejs-caching
>
> http://stackoverflow.com/questions/8315088/prevent-requirejs-from-caching-required-scripts
>
> Best Regards
> Dimitris Zenios.
>



-- 
Howard M. Lewis Ship

Creator of Apache Tapestry

The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!

(971) 678-5210
http://howardlewisship.com