Cornet works on lower layer and does not use ring-spec or HTTP. All the
functions and middleware in Cornet take path as String and return
java.net.URL (either "file:/..." or "jar:file:/") [as a side note: at some
point I want it to be able to return data as InputStream or String instead
of urls. ] For integrating with ring, there's wrap-url-response function
that creates Compojure's (GET "/*"...) route out of Cornet function.
By caching I mean two work modes:
- in production mode I assume all the assets are truly static. They are
compiled once, unless for some reason the cache is cleared (I had that
problem once, as /tmp directory was swiped on production server in some
cron job)
- in dev mode, the files will recompile every time you change the file
(based on .lastModified value). For LESS I've been able to hack into
compiler (thanks to Rhino engine) and Cornet will also note all the
@imported files and watch them too. If the source is not a file (instead
resides in a jar) then it is assumed a non-variable file.
Anyway, I didn't want to deal with ring responses, as ring and compojure
are doing it well enough. Handling on ring response level was actually one
of the things I didn't like with dieter.
-
Marcin
W dniu sobota, 16 listopada 2013 18:30:03 UTC+1 użytkownik James Reeves
napisał:
>
> On 16 November 2013 13:02, Marcin Skotniczny <cosmi...@gmail.com<javascript:>
> > wrote:
>
>> Well, I made sure you can do it:). I created the grouped middleware
>> functions for convenience's sake and I intend to add more.
>>
>
> Ah, interesting! That's a design I'm more comfortable with.
>
>
>> Although this might not be good enough, because:
>>
>> 1. LessCSS files should be listed. You will usually want to compile
>> only one or two of them, the rest will be @imported. SASS has convention
>> to
>> mark those files with underscore _ at the beginning of filename, but
>> LESS
>> doesn't have any solution like that, so...
>> 2. If you specify files to compile, they will be precompiled and any
>> compilation errors will be found immediately as the app won't start.
>>
>> Isn't this pretty easy to do by pushing through a request at
> initialisation? It would have the added side benefit of pre-warming the
> cache as well.
>
>
>>
>> 1. I tried separate caching layer, but it doesn't work so good. It
>> gets especially complex with LessCSS - you have to watch imported files
>> for
>> changes too. Also, I want to add transformation with non-java tools.
>> Integrating with those usually is based on filesystem anyway.
>>
>>
> Why doesn't it work well? Have you tried taking advantage of the 304
> not-modified header?
>
> For instance:
>
> (-> less-route
> wrap-not-modified
> wrap-compile-less
> (wrap-cache (file-cache "tmp"))
>
>
> In this case, the "less-route" function returns a response with a
> "Last-Modified" header in the response. If the request contains a
> "If-Modified-Since" header, then the wrap-not-modified middleware can
> replace the normal response with a 304 not-modified response.
>
> Then, all we have to do is have the wrap-compile-less middleware pass up
> any 304 responses without touching them, and the cache can then replace the
> 304 response with the cached version instead.
>
> I'm working on a ring-cache library that will handle caching in a fairly
> generic fashion by taking advantage of the infrastructure HTTP already has
> for handling this. The core middleware looks like:
>
> (defn wrap-cache [handler cache]
> (fn [request]
> (if (not= (:request-method request) :get)
> (handler request)
> (let [timestamp (java.util.Date.)
> cached (retrieve cache (:uri request))
> request (-> request (if-modified-since (:timestamp cached)))
> response (handler request)]
> (if (not-modified? response)
> (:response cached)
> (do (store! cache (:uri request) {:response response :timestamp
> timestamp})
> response))))))
>
>
> - James
>
--
--
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.
