You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Jochen Kemnade (JIRA)" <ji...@apache.org> on 2014/12/20 17:37:13 UTC

[jira] [Comment Edited] (TAP5-2123) Compiled CoffeeScript and Less files should be cached in development mode

    [ https://issues.apache.org/jira/browse/TAP5-2123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13979533#comment-13979533 ] 

Jochen Kemnade edited comment on TAP5-2123 at 12/20/14 4:36 PM:
----------------------------------------------------------------

If I am not mistaken, this is already fixed.


was (Author: jkemnade):
I am not mistaken, this is already fixed.

> Compiled CoffeeScript and Less files should be cached in development mode
> -------------------------------------------------------------------------
>
>                 Key: TAP5-2123
>                 URL: https://issues.apache.org/jira/browse/TAP5-2123
>             Project: Tapestry 5
>          Issue Type: Improvement
>          Components: tapestry-webresources
>    Affects Versions: 5.4
>            Reporter: Howard M. Lewis Ship
>              Labels: caching, coffee-script, development-mode
>
> When any asset changes, all caches are (normally) discarded.
> This isn't normally a major issue; Tapestry can re-read files, and repopulate its caches quickly.
> However, CoffeeScript to JavaScript compilation can be quite slow ... reasonable sized files may take 10 or 15 seconds to compile (when using the sluggish Rhino JavaScript VM). 
> It makes sense, then, to cache those files differently; a cache that tracks the source resource path and the checksum for the source resource and matches that to the compiled content stream. After changing a single file, only that one file would actually have to be recompiled; all the others would be served from the development-mode cache. The cost would be a quick scan of the file contents to build a checksum, to determine if the file content has changed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)