[
https://issues.apache.org/jira/browse/TAPESTRY-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12591463#action_12591463
]
Lars Kühne commented on TAPESTRY-2374:
--------------------------------------
Instead of developers having to manually upgrade a version number (which is
easy to forget), it would often be preferable to build a checksum that covers
all files in the web context, so the checksum changes whenever the context
changes in any way. The URLs would then look like
"/app-assets/d5f3459367ef/images/logo.gif". In our T4 app I did this by
overriding the relevant Hivemind services. The context checksum is calculated
once during application startup. This was quite simple to implement, and it
works really well even from within the IDE because it does not require any
build magic.
For very large contexts with thousands of files your manual approach might be
preferable to avoid the startup overhead, but for small contexts that overhead
is well below one second and the approach is less error prone. It would be
great if you could allow overriding the way the "version number" / checksum is
defined.
> Context assets should be versioned and provided with a far future expires
> header, just like classpath assets
> ------------------------------------------------------------------------------------------------------------
>
> Key: TAPESTRY-2374
> URL: https://issues.apache.org/jira/browse/TAPESTRY-2374
> Project: Tapestry
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.0.11
> Reporter: Howard M. Lewis Ship
> Priority: Minor
> Fix For: 5.1
>
>
> This is as-per YSlow recommendations, assets in the context (i.e., the
> context: asset prefix) should be treated like classpath: assets; the URL sent
> to the browser should reflect a version number (defined by the application)
> and the files should be given a far future expiration date.
> So the URL might be "/app-assets/1.2.3/images/logo.gif" for a file referenced
> as "context:images/logo.gif". The application would define the version
> number. It would be the developer's responsibility to advance the version
> number whenever the context files change (i.e., on each new deployment of the
> application).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
