@weavejester I don’t see how the above separates module and configuration keys? Do you mean that’s done via refsets? Or via derive from :duct/module?

Hmm… Another question… It seems that nothing in duct or integrant will load-namespaces for parents defined in duct_hierarchy.edn. Is this intended?

i.e. it looks like children get loaded automatically, but not parents.

@rickmoynihan Currently modules, special keys like :duct.core/include, and normal configuration keys are in the same map.

The plan is to change that, so there is a “module config” consisting of only modules.

The module configuration produces a map of transformation functions, which are placed in dependency order and then reduced over an empty map.

Some of the modules will be profiles, and profiles just merge their value into the map.

So instead of something like:

{:duct.core/include ["foo"]
 :duct.module/bar {}
 :duct.core/project-ns baz}

You’d instead have:

{:duct.profile/foo #duct/include "foo"
 :duct.module/bar {}
 :duct.profile/base {:duct.core/project-ns baz}}

In the former case we have a special key, a module key, and a normal key.

In the latter case, all keys are modules.

Regarding duct_hierarchy.edn, the hierarchy file just defines the keyword hierarchy. It’s useful because it’s a lot quicker to search the classpath for duct_hierarchy.edn and read that in, than it is to compile every Clojure file on the classpath.

yeah I can see that

The load-namespaces function works separately to that. It iterates through the keys in the configuration and loads them. I seem to recall that there was a patch recently to Integrant that ensured that the parents of the keys in the configuration were loaded.

ok, that patch sounds like what I’m after

https://github.com/weavejester/integrant/pull/35

That was included in Integrant 0.6.3

ahh ok my app seems to be including 0.6.2

I suspect a dependency somewhere needs bumped, as I created this app from the lein template yesterday

Probably. I’ve been working on the alpha version, so the stable version may have gotten a little behind.

cool no biggie… will try updating in my app to 0.6.3

Yeah that issue appears to be precisely what I was trying to describe. Thanks a million.

No problem! I’ll try to get around to updating the template deps today

Ok can confirm 0.6.3 fixes the issue I was having 🙂

is there any special reason why server.http.aleph doesn't support async handlers?

@beta1036 Like Ring async handlers? Or Aleph handlers? The key is just a small wrapper around Aleph, so it should support everything Aleph does

i meant ring handlers which get three arguments.

Does Aleph support those by default?

to be clearer, i would like to use ring middleware functions.

with the jetty server you would specify async? true, i think.

but the aleph server doesn't seem to support that.

As far as I know, Aleph doesn’t support the three-argument arity. You need a wrapper.

although it seems like it would be an easy thing to do.

wouldn't it make sense for server.http.aleph to call the 3 arg handler with the callbacks completing a deferred when async? is true?

or is there a better way to do something like that?

Aleph isn’t my project, and server.http.aleph is just a thin wrapper around the server.

i know

If you want to use Aleph with Ring async middleware, that requires a wrapper that changes manifold’s deferreds into callbacks.

yes.

wouldn't it make sense to do this wrapping in server.http.aleph?

Why?

i thought that would be symmetrical to how the jetty server does it.

That’s not something that’s related to Duct. All the server.http.aleph library does is provide the thinnest possible wrapper around Aleph. Adding more, creating something on top of Aleph, is best saved for another project.

i see. so if i want to switch from async ring with jetty to aleph, i just write my own wrapper instead of using server.http.aleph, right?

None of it’s complected, so ideally you just write some middleware that converts between callbacks and deferreds.

Then use server.http.aleph.

It’s essentially entirely orthogonal to Duct. You just need a middleware that converts to and from Aleph’s API.

sure. i was just wondering about the scope of server.http.aleph. thanks for the clarification!

is there a way to make different routes use different middleware?

for example to be able to use both sync and async routes while using ring middleware.

@beta1036 Yes, you can apply them to Compojure routes directly, or via Ataraxy’s metadata hints if you’re doing that. Essentially however you add middleware per route normally.

would i then set the :middleware for :duct.core/handler to an empty vector? anything specified there would be applied before the router, right?

Yes, though I don’t see why you would.

If I was doing it, I’d use the three argument form for all the middleware.

You can go from async to sync easily enough. It’s going the other way that’s problematic.

that's right. i see that it's not difficult, i'm just looking for the most elegant way of doing it.

thanks for the education. 🙂