My previous problems with yada are fixed I have a question though : is there an easy way to make a ring request from a yada ctx ? I am looking at integrating sente (https://github.com/ptaoussanis/sente) , which needs functions like ring-ajax-post ring-ajax-get-or-ws-handshake. I know Zach Tellman is working on an aleph adapter https://github.com/ztellman/sente . But I am wondering : what kind of support in yada will it require ?

So I'm having a bidi question, I hope this place is ok to ask

I was using a routing setup like the above to do i18n routing but now I just noticed that this approach fails to match properly if the structures of routes are not unique. I.e. in the example above the bikes routes will never be matched when using (bidi/match-route routes path)

If anyone has some suggestions for some internationalized routing setup with bidi that account for this problem I'd be very happy

I think an approach would be to generate the routing table. will try that now

hm. but with a generated routing table it becomes much harder to have something like path-for that respects language constraints

@martinklepsch: hi! - yes, your routes won't work because bidi sees [ :i18n-cars ] as [ :i18n-bikes ] as the same thing - however, generating your routes seems likek a great idea - the reason bidi uses data for routes is to allow this approach

I'm thinking through your remaining path-for issue -

Could you create something like bidi.bidi/RoutesContext to add a language 'tag' to the match-context

You could then restrict the unresolve-handler part of the Matched protocol it would satisfy to restrict on both handler and language

For example

the current path-for implementation looks like this:

(defn path-for
  "Given a route definition data structure, a handler and an option map, return a
  path that would route to the handler. The map must contain the values to any
  parameters required to create the path, and extra values are silently ignored."
  [route handler & {:as params}]
  (when (nil? handler)
    (throw (ex-info "Cannot form URI from a nil handler" {})))
  (unmatch-pair route {:handler handler :params params}))

You could create an alternative that would

(unmatch-pair route {:handler handler :params params :lang lang})

you would then wrap your language specific routes in a Matched record (you would have to implement)

that Matched record would have an unresolve-handler implementation that would do sometihng similar to TaggedMatch:

(defrecord TaggedMatch [matched tag]
  Matched
  (resolve-handler [this m]
    (resolve-handler matched (assoc m :tag tag)))
  (unresolve-handler [this m]
    (if (keyword? (:handler m))
      (when (= tag (:handler m)) "")
      (unresolve-handler matched m))))

maybe called LanguageMatch

So in summary, I think you need to build a couple of things: a) a defrecord language route wrapper and b) an alternative implementation of path-for, e.g. path-for-lang

but it's definitely possible - just one of those things bidi doesn't support out of the box but clojure's record feature lets you recover from

if any of this is unclear let me know and I'll try to explain better

@malcolmsparks: I ended up with another approach that prunes parts of the routing table:

(defn available-routes
  "Generate a routing table scoped to a given language"
  [lang]
  (->> {(name lang) {"" :root "/" (lang i18n-mapping)}}
       (assoc-in routes [1 [[keyword :country] "/"]])))

and then using that for path-for and having hard coded i18n path segments next to each other in the table I pass to match-route