> Doesn't this approach risk unnecessary repetition? > > I am not sure if I catch your drift... What I wanted to have is a direct replacement for clojure.java.io/resource function - so if at some layer you come down to using this function, you can just replace it with cornet generated handler -> the function signature (accepted arguments and returned value) is the same. I could use ring-spec or something similar, but I think this is simpler, IMHO more elegant and (I think) a bit more flexible.
As for the dangers of repetition: Basing on most typical real-life usage, the only need for recompilation is during development, so I guess performance here is not important. The cache in Cornet is dynamic (that is: tracks when source file changes) only in development mode - so if you have some assets that change _during_ app uptime on production server, then the basic Cornet stack is not suitable for your needs (although in this case I think that development mode will be fast enough - tracking changes is based on single .lastModified queries). Otherwise, Cornet will return file urls, so you can check their timestamp and return 304, just like you would with normal files. The problem I had with caching on higher layer is that it is tricky to track the original file if you have many transformations pipelined - especially if some of them can combine multiple files. > If someone writes some caching middleware, or middleware that optimises > Javascript, or whatever else, it's not compatible with the new abstraction > you've introduced. > > Well, you can just write middleware that is compatibile with it :). Anyway, it shouldn't be difficult to create an adapter to ring-spec or whatever format the middleware would use, right? > It would be difficult for me to use Cornet in my own projects, for > instance, because I'd have to maintain two separate systems for caching > compiled resources. > > If you are already using some asset pipelining method you are comfortable with, then I guess you don't need Cornet :). - Marcin > > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
