Why does ArgumentScope not have RequestScope as parent resolver

[Mike Hogan]

Subject says it all really. The fact that RequestScope connects to ApplicationScope seems natural (and essential), so finding that ArgumentScope does not connect to RequestScope surprised me. It also makes it difficult for me to do something: i have a query param that can specify one of many views of a list of data. however if the user is admin, i want to add things to that view. the query param is in argumentscope, but the session data is in requestscope. and looking up the session data is expensive ,so i do not want to also add it to argument scope.

can anybody help removing this mindknot for me?

Ta,
Mike.

[Daniel Worthington-Bodart]

I did it to force state to be in the request (REST and all the jazz), the idea being that all method parameters are always created from request and nowhere else. This helps with reasoning and portability. Resources always take dependencies in their constructors while resource methods can only be populated by the request itself.

Every single time I've wanted argument scope to get something from request scope (or app scope), I've later been pleased with the separation of data and behaviour forced upon me! This is very similar to the common pattern of separating application state and moving the behaviour to request scope so it can partake in transactions etc.

If you REALLY want to get around this then you can create a HttpHandler to inject the data from request scope into the original request. Make sure you think about security if you do this mind.

--
You received this message because you are subscribed to the Google Groups "utterlyidle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to utterlyidle...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Daniel Worthington-Bodart]

Oh and I think for your particular needs I'd probably go the other way. Make the list of views request scope and make the activator take into account the request and their role

[Daniel Worthington-Bodart]

Generally speaking UtterlyIdle is always trying to make you use request scope. Any time I see ApplicationScope or ArgumentScope in a project I question if it couldn't be done at request scope.

[Mike Hogan]

Great reply Dan, thanks.  As I was writing the question, the cleanliness of ArgumentScope became clear to me, but I decided to ask anyway, because this has come up for me several times before, and I wanted something documented to come back to when I forget it again six months from now :)

Be well,

Mike.

On 23 Feb 2015, at 12:47, Daniel Worthington-Bodart <d...@bodar.com> wrote:

I did it to force state to be in the request (REST and all the jazz), the idea being that all method parameters are always created from request and nowhere else. This helps with reasoning and portability. Resources always take dependencies in their constructors while resource methods can only be populated by the request itself.

Every single time I've wanted argument scope to get something from request scope (or app scope), I've later been pleased with the separation of data and behaviour forced upon me! This is very similar to the common pattern of separating application state and moving the behaviour to request scope so it can partake in transactions etc.

If you REALLY want to get around this then you can create a HttpHandler to inject the data from request scope into the original request. Make sure you think about security if you do this mind.

On 23 February 2015 at 12:09, Mike Hogan <m...@mikehogan.net> wrote:

--
You received this message because you are subscribed to the Google Groups "utterlyidle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to utterlyidle...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.