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, gzipping. The current approach is a bit too complicated.
On Fri, Apr 19, 2013 at 3:50 PM, Nenad Nikolic <iznenad.niko...@gmail.com>wrote: > 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 bad solution, but it was just simpler than if i > wrote it servlet style. > I think StreamableResourceSource itself should be a plpeline into which a > user could contribute and override existing instances. > > Also i could be completely wrong :) > > Regards. > > > > On Wed, Apr 17, 2013 at 7:24 PM, Nenad Nikolic <iznenad.niko...@gmail.com > >wrote: > > > 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 need to solve good enough. > > > > But still, if it would be possible to somehow override the > > SRSCachingInterceptor's implementation of isCachable i think i would > > actually have a valid solution. > > I could have a special handling for the resources with the custom > > extension and just not cache them. > > > > Is it possible to do this? Am i missing something in thinking this? > > > > Thanks again. > > > > > > > > On Wed, Apr 17, 2013 at 7:05 PM, Howard Lewis Ship <hls...@gmail.com > >wrote: > > > >> 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 might use to server content out of a database. It ends up > >> being more like a servlet at that point (Dispatcher is very similar to > >> HttpServlet) and you have control over everything that happens: you > >> control > >> the cache, the URL format, the works. With a little bit of effort, you > >> can > >> probably leverage some of the features of Tapestry's asset pipeline > >> (minimization, CSS rewriting in 5.4, etc.), by making your data > implement > >> StreamableResource. > >> > >> > >> On Wed, Apr 17, 2013 at 5:33 PM, Nenad Nikolic < > iznenad.niko...@gmail.com > >> >wrote: > >> > >> > 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 the data into > >> > hazelcast, and render a response which will contain urls to two assets > >> (one > >> > js one css) with a request parameter (the unique identifier). > >> > Here is how an example response looks like: > >> > > >> > <modifier> > >> > <javascript> > >> > <filepath> > >> > > >> > > >> > http://localhost:8080/app/assets/1.0.0-SNAPSHOT/ccdd/template.nmjs?trid=unique_identifier > >> > </filepath> > >> > </javascript> > >> > <css> > >> > <filepath> > >> > > >> > > >> > http://localhost:8080/app/assets/1.0.0-SNAPSHOT/ccdd/template.nmcss?trid=unique_identifier > >> > </filepath> > >> > </css> > >> > </modifier> > >> > > >> > This is a machine-to-machine request. The system that made the request > >> will > >> > give the asset urls to the client when rendering a webpage. > >> > > >> > 2) the second request is the one coming from the client. It is a > request > >> > for the actuall assets. It should return the asset but replace the > >> > placeholders within the asset with values from hazelcast. > >> > I currently have an AssetHandler mapped to the "ccdd" path. > >> > In the AssetHandler i get the request parameter and get the values > from > >> the > >> > hazelcast map. Then the values are stored on the environment stack for > >> my > >> > ResourceTransformer to access. This whole thing is working and i get a > >> > properly transformed asset for the first request. > >> > > >> > My problem is that when the unique identifier changes the resource is > >> not > >> > transformed again. > >> > > >> > So my questions are: > >> > > >> > Is it possible to cache resources selectively? > >> > Am i doing this in a completely shitty way? > >> > > >> > I hope that my explanation is understandable. Thx in advance for any > >> > responses! > >> > > >> > >> > >> > >> -- > >> 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 > >> > > > > > -- 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
