No, I agree; I'm thinking of a refactoring where SRS does just what it
says: create an SR from a Resource and cross-compile it (i.e., CoffeeScript
to JavaScript), and then add a second service to which filters can be
contributed to do all the other work: CSS rewrites, minimization, caching,
gzippin
Documentation sake :
I have solved the problem by extending StreamableResourceSourceImpl with my
local class and binding that class with a local interface with the same
methods as StreamableResourceSource, hence avoiding the decorators bound to
StreamableResourceSource.
I feel that this is a very
Thank you for the quick response! I was considering such an approach,
implementing a separate dispatcher at first but figured it would just be
too much work and tapestry already provides the features and infrastructure
i need for delivering assets. I seems that i wasn't looking at the problem
i nee
Generally speaking, assets are expected to be static (that is, unchanging)
and global, which is why there's so much caching going on.
I would say that you should implement your own Dispatcher (contributed to
the MasterDispatcher) service and just take control of this, using the same
techniques you
Hello, i'm struggling with delivering a transformed resource for each
request.
Here is exactly what i mean:
There are two requests expected to hit the app.
1) a request containing a unique identifier and some other values as
request parameters.
This request will hit a dispatcher which will store
