That would fix it 🙂 @tony.kay I also found some bugs with regard to ident loading with load, Ill try to reproduce them this week

@mitchelkuijpers interesting. Let me know. Thanks

in untangled-server, how can I add ring session or any kind of handler wrappers?

I and tony added untangled-system to the latest snapshot, but I dont think it has any/good documentation Otherwise: make-untangled-server takes :components that can depend on :handler and inject into handler stack at two locations pre-hook and fallback-hook using get-pre-hook and set-pre-hook

let me find you a cookbook or something

@adambros thanks, I just figured out, found an example using the wrap-cookie, all good 🙂

is that yours?

no, it came on the template from Tony

ah ok

I just added the wrap-session bit

in the future untangled-system is the way forwards it simply lets you have complete control over the handler stack

and you can create a webserver, or grab the pieces you need and put them in some other servlet

for now the best documentation is the specs for it

cool, thanks for letting me know

one other question, how do you set the session values? I see at the docs that I should return the ring request with the session modified from a handler, but how can we do that from a parser mutation?

iirc we have an open issue about that

https://github.com/untangled-web/untangled-server/issues/17

you should add that you might want to change the :session

yeah, I guess @tony.kay is thinking on the request in general, but I'll add a note just in case

@tony.kay on the issue you suggest using metadata to get the response modifications, why not just a key in the response map (like untangled.server/response)?

oh, I see, it all get's returned to the om parser, gotcha

@wilkerlucio At the moment you can return a response to the client and use cljs to set a cookie, but we do need a general purpose solution from a mutation

but with ring-session you can access the session store

@tony.kay I sent a PR with a possible solution to the response problem

great

I first tried using the idea of meta-data returning, but since the parser can return on multiple nodes the merging could become an issue

yep, that was partly why I hadn't done it yet 🙂

so I had another idea (a simpler one I think) that is to have a shared atom called response, that the parser can mutate, then it get's merged into the response

this way, the merging is user responsability

oooo..state, I dislike that more, to be honest

I'd rather have idempotent metadata...e.g. "add cookie", "add header"...things that compose well

it is /api; there isn't much you should ever need to do

and mutations are non-recursive, so it is a simple merge

I'm just thinking that multiple mutations can ask for example to change the session

in this case, if we implement the merging in untangled we are taking this decision upfront on how to manage it

changing the session should be done IN the mutation, with direct access to the session store

the only thing the client cares about is the cookie

which should be identical in both

again, idempotent

set it 5x, who cares?

Now, this IS server-side, so we don't have the app-state serialization concern

we could put a lamba on the metadata of type resp->resp

now it chains

(f (g (h response))) -> new response

sounds good

or rather, response

not session

let me update the PR, I'll revert to the metadata, and change from merging to lambds

yeah, response

now are we still limiting what you can do to the response?

no, but if you break it, it's your problem 😉

is this for reads and mutates?

mutate

any reason on reads?

you have to change server state, so I'd say it only makes sense abstractly on mutations

makes enough sense

@wilkerlucio you are doing this in just reads though

@tony.kay updated the PR https://github.com/untangled-web/untangled-server/pull/20/files

the current way just doens't care if it's a read or a write

should we limit to writes?

read above tony’s last message

what if a user wants to change the response status from a read?

recursive parsing...how do you find them all? Throw an exception and get a 500, or return a response that you can deal with on the client. Don't care about HTTP status codes because this isn't REST

in other words, treat it more like RMI, not HTTP

ok, so, in this case, instead of walk the response, we can scan just the first level and apply the with-response in the ones that are symbols (and so, mutations), is that correct?

That was my take, yes. On reads, what are the use-cases where you'd need it. If there are many valid ones, then maybe we support it only on top-level values?

Headers for caching might end up being interesting when we get to http caching of responses...but I'm not sure we won't have another way of dealing with that

since you have to hook into a specific alternate URL and remote def for that

I don't see any case right now in favor of giving the readings, except that I also don't see a reason to don't allow it, I prefer to leave the decision of using or not to the user on those cases

So, if we only look at the shallow case, I'm ok with it handling reads and writes

I think allowing on the top level is a good approach until we have more input on this

agreed

can always add a filter to symbols

yup 🙂

@tony.kay PR updated, scanning only root

sweet. Behavioral tests?

I added tests on the API method directly, there is any other place I should be checking on it?

also, I added a method with-response at the core, but I'm not sure if this is the best place and name for it

I'll take a look, thanks!

Hm. So, should the reduction get to see the status/body of the response? If not, then the merge order is probably wrong.

the behavioral (test) should say something like "prefers original response body and status over any appearing in the modified response"

I like the helper function. Core is a fine place for it. Naming.....suggestions anyone?

augment-response?

arg names are off, too

(defn augment-response [core-response ring-response-fn] ...)?

doc string would be extra good there

I though you wanted the ability to change the status, (because your example (response-with-status { :tempids {n m} } 202)), so, no body and status change, right?

ah. I'm easily swayed on that

🙂

just want a spec that says which way it is intended to behave

and proves it behaves that way

(augment-response {…}
   (comp
      (with-status 202)
      (with-header …)))

ok, I'm writing the spec for that, so I'll leave the status open and block the :body

it then just becomes middleware?

@adambros you think untangled should provide those helpers?

ring should have some

I'm ok being able to mess with the body, just as long as we say it is what you can do

oh right, @adambros there are already Ring response helpers like that

set-content-type etc

so yeah, just leverage the middleware helpers that are in Ring already

yeah, the lambda approach should enable the usage of those, nice 🙂

resp -> resp

it's all good

good effort team 🙂

@tony.kay added new specs and docs

thx. I'll look very soon.