Just to let everyone know that we've just released version 2.0 of encors, with these suggested changes in place.
The middleware should now feel more Clojure-ish and Ring-ish :) Thanks James for the great feedback. On Wednesday, November 26, 2014 4:31:37 PM UTC-8, Román González wrote: > > Good points... > > So possible changes: > > * Replace the get-policy-for-req argument with a just policy-options map > > This makes it easier to validate options just once. I guess all the > validations done on a simple > Request -> CorsPolicy function can be done by composing middleware > together (e.g. Middleware that check certain header or route + cors > middleware). I like this. > > * Remove the CorsPolicy type and just do the schema validation at the > beginning of the middleware. > > I believe this actionables are feasible. I discuss this internally and > develop of all this make sense. > > Thanks for your feedback James, highly appreciated. > > Roman.- > > > On Wed, Nov 26, 2014 at 3:43 PM, James Reeves <ja...@booleanknot.com > <javascript:>> wrote: > >> On 26 November 2014 at 23:08, <ro...@unbounce.com <javascript:>> wrote: >> >>> map->CorsPolicy enforces correctness of input, this way the wrap-cors >>> functions doesn't need to validate data. Probably we can add a call to >>> map->CorsPolicy as the first thing of wrap-cors function and keep this >>> function private. >>> >> >> In Clojure, types and validation are orthogonal concepts. You don't need >> to use deftype in order to validate a map. >> >> For instance, you could write your middleware function instead as: >> >> (defn wrap-cors [handler options] >> (s/validate cors-schema options) >> (fn [request] >> ...)) >> >> Or better yet, perhaps just use s/defn instead. >> >> Given that we are returning a Policy per request call, calling a >>> map->CorsPolicy every time we call warp-cors sounds a bit overkill >>> performance wise... Instead of validating development settings once when >>> the namespaces is loaded, it is being validated every time a request comes >>> in. >>> >> >> Even though the function wrap-cors returns will be evaluated many times, >> the wrap-cors function itself will likely only be evaluated once when your >> handler is created. For instance: >> >> (def handler >> (wrap-cors my-routes cors-options)) >> >> This means that there's no performance benefit to creating a type to just >> contain the option map, particularly since you're not using type hints, so >> you're accessing the type via reflection. >> >> By convention, Ring middleware also takes the handler as the first >> argument, allowing it to be more easily threaded. >> >> - 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/d/optout.
