well, it does when you change
"before:AssetDispatcher"
to
"before:Asset"
sorry.
On 24/02/2012 3:19 PM, Steve Eynon wrote:
This is an awesome idea, and works perfectly too.
Thanks.
---
"If at first you don't succeed,
so much for skydiving!"
On 22 February
Most of the time, you should avoid using the regex methods on the String
class (split, matches, replace etc) as these will compile the
java.util.regex.Pattern for every invocation.
Instead, you should Pattern.compile(regex) once and save the result then
use Pattern.matches(value).
On Wednesday, 2
This is an awesome idea, and works perfectly too.
Thanks.
---
"If at first you don't succeed,
so much for skydiving!"
On 22 February 2012 08:47, Paul Stanton wrote:
> By the way all,
>
> Here is a solution which does not require any changes to tapestry code. All
By the way all,
Here is a solution which does not require any changes to tapestry code.
All code is free to use.
1. contribute a dispatcher to MasterDispatcher, just before the regular
AssetDispatcher:
public static void bind(ServiceBinder binder)
{
binder.bind(Dispatcher.cl
Didn't think there was a Jira yet, I'll try to get around to logging it
later this week.
On 22/02/2012 8:38 AM, Howard Lewis Ship wrote:
Patches are best provided on JIRA; there's a checkbox that shows you
have granted the rights to the patch& code to the Apache Software
Foundation. Thanks!
Patches are best provided on JIRA; there's a checkbox that shows you
have granted the rights to the patch & code to the Apache Software
Foundation. Thanks!
On Tue, Feb 21, 2012 at 12:28 PM, Paul Stanton wrote:
> Here's my implementation:
>
> // Copyright 2006, 2008, 2009, 2010, 2011 The Apache S
Here's my implementation:
// Copyright 2006, 2008, 2009, 2010, 2011 The Apache Software Foundation
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// http://www.
Sounds good to me.
I, for example, use the Mercurial revision hash as the version number,
so in a sense 'earlier/later' version does not make sense in my context,
so if Tapestry would just redirect to the current version it would work great!
On Feb 21, 2012, at 2:05 PM, Howard Lewis Ship wrote:
I suspect the 302 redirect may be the correct solution, and Tapestry
could support this pretty reasonably.
The perfect solution would involve the following:
- The version number if replaced with the SHA1 hash of the resource's
(uncompressed) content
- All CSS is dynamically rewritten to convert re
Hi Cezary,
I think I have the same need as you.
We use load balanced servers, and when upgrading we upgrade one at a
time so that there is always a server running.
But the side effect is that the upgraded server can receive requests for
the old assets, and we don't want to fail in this case.
On Thu, 24 Mar 2011 00:45:56 +0100, Thiago H. de Paula Figueiredo
wrote:
On Wed, 23 Mar 2011 20:26:35 -0300, raulmt wrote:
Cezary Biernacki wrote:
On Thu, Mar 24, 2011 at 12:04 AM, Thiago H. de Paula Figueiredo <
thiag...@gmail.com> wrote:
> Why don't you set the application version symb
On Wed, 23 Mar 2011 20:26:35 -0300, raulmt wrote:
Cezary Biernacki wrote:
On Thu, Mar 24, 2011 at 12:04 AM, Thiago H. de Paula Figueiredo <
thiag...@gmail.com> wrote:
> Why don't you set the application version symbol of your
application
to a
> given value and never change it?
Really?
On Wed, 23 Mar 2011 20:18:16 -0300, Martin Strand
wrote:
Because that would defeat the purpose of automatic version management
for /assets/ and we would have to rename every asset that changed
between versions
I'm not following you: if you use some Tapestry way to refer to assets,
you
Cezary Biernacki wrote:
>
> On Thu, Mar 24, 2011 at 12:04 AM, Thiago H. de Paula Figueiredo <
> thiag...@gmail.com> wrote:
>
> > Why don't you set the application version symbol of your application
> to a
> > given value and never change it?
>
>
> Really? It will cause all caching problems tha
Because that would defeat the purpose of automatic version management for
/assets/ and we would have to rename every asset that changed between
versions
On Thu, 24 Mar 2011 00:04:29 +0100, Thiago H. de Paula Figueiredo
wrote:
Why don't you set the application version symbol of your appli
On Thu, Mar 24, 2011 at 12:04 AM, Thiago H. de Paula Figueiredo <
thiag...@gmail.com> wrote:
> Why don't you set the application version symbol of your application to a
> given value and never change it?
Really? It will cause all caching problems that version numbers are supposed
to solve, will
>
>
> Perhaps the AssetDispatcher could check the requested version number and if
> it doesn't match the app version, send a 302 redirect to the "correct" URL?
> /assets/1.3/ctx/script.js --> /assets/1.2/ctx/script.js
>
> Or perhaps it should only deliver the asset if the requested version os
> old
Why don't you set the application version symbol of your application to a
given value and never change it?
On Wed, 23 Mar 2011 19:50:59 -0300, Martin Strand
wrote:
On Wed, 23 Mar 2011 22:43:55 +0100, raulmt wrote:
I wanted to know if there is a reason why Tapestry couldn't just answer
On Wed, 23 Mar 2011 22:43:55 +0100, raulmt wrote:
I wanted to know if there is a reason why Tapestry couldn't just answer
the
requests for assets independently of the requested version. I believe
that
it is better to answer with a newer version than to just not answering at
all… In AssetDis
Hi Howard,
I wanted to know if there is a reason why Tapestry couldn't just answer the
requests for assets independently of the requested version. I believe that
it is better to answer with a newer version than to just not answering at
all… In AssetDispatcher, this could be done by just processin
So you start with two files:
style.css:
BODY { background: url(dizzydots.gif); }
These start in the same folder (perhaps src/main/webapp).
Now, these two files, under the scheme you propose, end up looking
with the following URLs:
/assets/25ea1900f125e2e136d4/style.css
/assets/0aa5f29fc5f8
Does putting it in the filename instead of the "directory" also have caveats?
--
View this message in context:
http://tapestry-users.832.n2.nabble.com/Versioned-assets-tp5421811p5512040.html
Sent from the Tapestry Users mailing list archive at Nabble.com.
---
This has been considered, but it would mess up relative URLs inside stylesheets.
On Tue, Sep 7, 2010 at 4:14 AM, LLTYK wrote:
>
> What it should do is instead insert some sort of hash of the file's contents
> in the url. Then whenever your file changes the browser won't pick up the
> previous cac
On Tue, 07 Sep 2010 13:14:02 +0200, LLTYK wrote:
What it should do is instead insert some sort of hash of the file's
contents
in the url. Then whenever your file changes the browser won't pick up the
previous cached version, but if your app version changes and the file
doesn't, the url rema
What it should do is instead insert some sort of hash of the file's contents
in the url. Then whenever your file changes the browser won't pick up the
previous cached version, but if your app version changes and the file
doesn't, the url remains the same.
--
View this message in context:
http://
Thank you, based2, but I think you didn't understand my problem. If you save
a link to a current asset in your application (which will have the current
version of your app at the beginning), later, if you update your app
changing the version number, then the link you saved will not work, because
t
http://stackoverflow.com/questions/288041/tapestry-4-asset-cache-control
http://tapestry.1045711.n5.nabble.com/Expires-Header-not-set-for-assets-td2400940.html#a2400940
== http://wiki.apache.org/tapestry/Tapestry5HowTos
== http://wiki.apache.org/tapestry/Tapestry5OpensourceApps
== http://wiki.apa
27 matches
Mail list logo
