You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Howard Lewis Ship <hl...@gmail.com> on 2013/06/03 20:04:46 UTC
Tapestry 5.4-alpha-7
The latest Tapestry preview release, 5.4-alpha-7, adds a little bit of
development-time caching to compilation of CoffeeScript and Less assets.
The new version is available at the following Maven repository:
https://repository.apache.org/content/repositories/orgapachetapestry-057/
In development mode, Tapestry monitors all assets that have been exposed to
the client: CSS files, JavaScript libraries, and so forth. When any file
changes, all sorts of caches are cleared.
In normal Tapestry, this is not very noticeable; Tapestry quickly reloads
all the necessary files (changed or not).
Unfortunately, the CoffeeScript compiler is currently limited by the use of
Rhino, the slow JavaScript VM built into the JVM. It can take many seconds
to compile a CoffeeScript file.
alpha-7 introduces a special cache for CoffeeScript and Less; this cache is
based on file content, not date-time-modified (though, as I write this, I'm
wondering if a date-time-modified check would work just as well as the
content check). In any case, this cache is not cleared with the other
caches. When a file has been previously compiled, and its source has not
changed, the compiled version is vended out of the cache.
For Less files, it is smart enough to track the main source file, but also
any files that are read via the @import mechanism built into Less.
As a test, I copied the Bootstrap Less source files into my test
application, and reconfigured Tapestry to use this bootstrap.less in place
of the normal bootstrap.css bundled with the framework. Results were quite
reasonable:
qtp1995297012-16 [INFO] StreamableResourceSource Compiled
context:bootstrap/css/bootstrap.less to Less in 5229.39 ms
qtp1995297012-16 [INFO] ResourceMinimizer Minimized
context:bootstrap/css/bootstrap.less (124,827 input bytes of text/css to
100,793 output bytes in 3056.71 ms, 19.25% reduction)
I consider being able to dynamically build Bootstrap from its Less source,
and minimize its content, at runtime, to be a bellwether that the
Less/JavaScript/CSS/Minimization support is going to work well for
production applications.
--
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
Re: Tapestry 5.4-alpha-7
Posted by Howard Lewis Ship <hl...@gmail.com>.
On Wed, Jun 5, 2013 at 2:51 AM, Muhammad Gelbana <m....@gmail.com>wrote:
> 1. I hope this comment would be considered to solve that issue.
>
>
> https://issues.apache.org/jira/browse/TAP5-1948?focusedCommentId=13675755&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13675755
>
> *2. In development mode, Tapestry monitors all assets that have been
> exposed to
> the client: CSS files, JavaScript libraries, and so forth. When any file
> changes, all sorts of caches are cleared.*
> *
> *
> You must be talking about a cache on the server's side. But how would that
> work if the client caches tapestry assets aggressively ? Or would that
> aggressive client caching be forced only while in production mode ?
>
> Thanks.
>
Assets now have a content hash embedded into the URL; if a server-side
asset changes, then the URL Tapestry generates for that asset will change
as well, and the browser will pull the new content.
In production mode, Tapestry assumes the assets are static, and wastes no
resources on checking to see if they have changed. It assumes that change
will come in the form of a complete redeployment and relaunch of the WAR.
In development mode, extra filters and logic come into play to check for
changes to assets.
URLs for modules can't include a version number, so those don't get a far
future expires header, but they (as of alpha-9) get a Cache-Control that
forces the browser to revalidate them on each new page render.
>
>
> On Mon, Jun 3, 2013 at 8:04 PM, Howard Lewis Ship <hl...@gmail.com>
> wrote:
>
> > The latest Tapestry preview release, 5.4-alpha-7, adds a little bit of
> > development-time caching to compilation of CoffeeScript and Less assets.
> >
> > The new version is available at the following Maven repository:
> >
> >
> https://repository.apache.org/content/repositories/orgapachetapestry-057/
> >
> > In development mode, Tapestry monitors all assets that have been exposed
> to
> > the client: CSS files, JavaScript libraries, and so forth. When any file
> > changes, all sorts of caches are cleared.
> >
> > In normal Tapestry, this is not very noticeable; Tapestry quickly reloads
> > all the necessary files (changed or not).
> >
> > Unfortunately, the CoffeeScript compiler is currently limited by the use
> of
> > Rhino, the slow JavaScript VM built into the JVM. It can take many
> seconds
> > to compile a CoffeeScript file.
> >
> > alpha-7 introduces a special cache for CoffeeScript and Less; this cache
> is
> > based on file content, not date-time-modified (though, as I write this,
> I'm
> > wondering if a date-time-modified check would work just as well as the
> > content check). In any case, this cache is not cleared with the other
> > caches. When a file has been previously compiled, and its source has not
> > changed, the compiled version is vended out of the cache.
> >
> > For Less files, it is smart enough to track the main source file, but
> also
> > any files that are read via the @import mechanism built into Less.
> >
> > As a test, I copied the Bootstrap Less source files into my test
> > application, and reconfigured Tapestry to use this bootstrap.less in
> place
> > of the normal bootstrap.css bundled with the framework. Results were
> quite
> > reasonable:
> >
> > qtp1995297012-16 [INFO] StreamableResourceSource Compiled
> > context:bootstrap/css/bootstrap.less to Less in 5229.39 ms
> > qtp1995297012-16 [INFO] ResourceMinimizer Minimized
> > context:bootstrap/css/bootstrap.less (124,827 input bytes of text/css to
> > 100,793 output bytes in 3056.71 ms, 19.25% reduction)
> >
> > I consider being able to dynamically build Bootstrap from its Less
> source,
> > and minimize its content, at runtime, to be a bellwether that the
> > Less/JavaScript/CSS/Minimization support is going to work well for
> > production applications.
> >
> > --
> > 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
> >
>
--
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
Re: Tapestry 5.4-alpha-7
Posted by Muhammad Gelbana <m....@gmail.com>.
1. I hope this comment would be considered to solve that issue.
https://issues.apache.org/jira/browse/TAP5-1948?focusedCommentId=13675755&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13675755
*2. In development mode, Tapestry monitors all assets that have been
exposed to
the client: CSS files, JavaScript libraries, and so forth. When any file
changes, all sorts of caches are cleared.*
*
*
You must be talking about a cache on the server's side. But how would that
work if the client caches tapestry assets aggressively ? Or would that
aggressive client caching be forced only while in production mode ?
Thanks.
On Mon, Jun 3, 2013 at 8:04 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
> The latest Tapestry preview release, 5.4-alpha-7, adds a little bit of
> development-time caching to compilation of CoffeeScript and Less assets.
>
> The new version is available at the following Maven repository:
>
> https://repository.apache.org/content/repositories/orgapachetapestry-057/
>
> In development mode, Tapestry monitors all assets that have been exposed to
> the client: CSS files, JavaScript libraries, and so forth. When any file
> changes, all sorts of caches are cleared.
>
> In normal Tapestry, this is not very noticeable; Tapestry quickly reloads
> all the necessary files (changed or not).
>
> Unfortunately, the CoffeeScript compiler is currently limited by the use of
> Rhino, the slow JavaScript VM built into the JVM. It can take many seconds
> to compile a CoffeeScript file.
>
> alpha-7 introduces a special cache for CoffeeScript and Less; this cache is
> based on file content, not date-time-modified (though, as I write this, I'm
> wondering if a date-time-modified check would work just as well as the
> content check). In any case, this cache is not cleared with the other
> caches. When a file has been previously compiled, and its source has not
> changed, the compiled version is vended out of the cache.
>
> For Less files, it is smart enough to track the main source file, but also
> any files that are read via the @import mechanism built into Less.
>
> As a test, I copied the Bootstrap Less source files into my test
> application, and reconfigured Tapestry to use this bootstrap.less in place
> of the normal bootstrap.css bundled with the framework. Results were quite
> reasonable:
>
> qtp1995297012-16 [INFO] StreamableResourceSource Compiled
> context:bootstrap/css/bootstrap.less to Less in 5229.39 ms
> qtp1995297012-16 [INFO] ResourceMinimizer Minimized
> context:bootstrap/css/bootstrap.less (124,827 input bytes of text/css to
> 100,793 output bytes in 3056.71 ms, 19.25% reduction)
>
> I consider being able to dynamically build Bootstrap from its Less source,
> and minimize its content, at runtime, to be a bellwether that the
> Less/JavaScript/CSS/Minimization support is going to work well for
> production applications.
>
> --
> 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
>