You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Jochen Berger <fo...@googlemail.com> on 2010/09/10 08:32:42 UTC
Re: How to serve "nearly static" resources
Hi again,
so at least this use case does not seem to be trivial. ;-)
But as the answers stay away, maybe it didn't become clear from my
explanations. If you'd tell me, which parts were not understandable, I
could try to rephrase them.
Regards,
Jochen
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: How to serve "nearly static" resources
Posted by Jochen Berger <fo...@googlemail.com>.
Howard,
Am Freitag, den 10.09.2010, 09:08 -0700 schrieb Howard Lewis Ship:
> In 5.2 there's an AssetDispatcher service that can be contributed to;
> the built in contributions are for context assets, classpath assets,
> and stack assets (i.e., aggregated JavaScript libraries). You can add
> your own AssetRequestHandler.
Ok, I'll have another go at this approach then. I already tried it but
unfortunately I can't remember why I gave it up.
> You can look at some of the existing AssetRequestHandlers for an idea
> of how to handle an infrequently changing asset ... perhaps have a
> version id as part of the URL and increment it when the content of the
> asset changes.
Yeah, that's what I had in mind. Remember the last timestamp when the
data changed and hex-encoding it into the URL, like what is done with
zone updates.
Thanks a lot,
Jochen
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: How to serve "nearly static" resources
Posted by Howard Lewis Ship <hl...@gmail.com>.
Seems to me that your are on the right track.
In 5.2 there's an AssetDispatcher service that can be contributed to;
the built in contributions are for context assets, classpath assets,
and stack assets (i.e., aggregated JavaScript libraries). You can add
your own AssetRequestHandler.
You can look at some of the existing AssetRequestHandlers for an idea
of how to handle an infrequently changing asset ... perhaps have a
version id as part of the URL and increment it when the content of the
asset changes.
On Thu, Sep 9, 2010 at 11:32 PM, Jochen Berger <fo...@googlemail.com> wrote:
> Hi again,
>
> so at least this use case does not seem to be trivial. ;-)
> But as the answers stay away, maybe it didn't become clear from my
> explanations. If you'd tell me, which parts were not understandable, I
> could try to rephrase them.
>
> Regards,
> Jochen
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org