Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
I missed that discussion. Anyway, IMO global request scope is nearly
never a good idea. As discussed in that thread, people are into an
unplesant suprise if they use global request scope for e.g. aggregation.
Furthermore one introduce quite strange dependencies in the code if
internal requests affects global request attributes. IMO, one should in
most cases avoid letting internal requests having global side effects.
This is a difficult topic. You can use global attributes to pass
information from the global request to the sub requests and vice versa.
This can be very useful sometimes.
It is indeed a difficult topic. Using global attributes does not scale
well and make applications far to monolitic to be easy reusable. We of
course have to support them despite that for back compability and
because people might be used to them. But I think it would be much
better if we saw an internal request like some kind of function call
with in parameters and return values. Something like that is necessary
to make e.g. blocks independent of their execution environment. One
possiblity is to put a parameter map in the response object and make it
local to the internal request.
In the thread you seemed to agree about that it was best, due to
compability reasons, to keep the old global scope as default for request
attributes, and make local request scope available through an extra
parameter. IMO this is one of thoose cases where it is better to be
brave and introduce back incompabilities than to keep an obscure
behaviour. I think we should have request scope as default in 2.2, it
will break some code, but there is a good workaround with the scoped
attributes. And we will save most users from unpleasant suprises by
having the more sensible behaviour as default.
If we go this way, the Map getRequestAttributes(), will have local
request scope, and we could have a Map getGlobalRequestAtributes() for
giving access to the global ones. But as using global request parameters
is a rather uncommon use case, I don't think we need to have POJOfied
support for it.
I don't agree here. My number one concern is compatibility. Users might
not notice that we changed this behaviour and will spend days in finding
these problems.
I would rather consider the current behaviour as a bug and am more
concerned about the days new user might spend on understanding why the
default behaviour makes there applications stop working when they
introduce aggregation. But I have no idea about how people write their
applications, so it is maybe common to use global request attributes.
So, either we leave it compatible or we provide an
update tool, that rewrites every old use "getAttribute(name)" to
getAttribute(name, global scope)" etc. But without such a tool, I'm -1
on changing the behaviour.
Any suggestions about how to write such an update tool?
In addition, I think it's not that uncommon to pass information between
the main and the sub requests using global attributes.
Might be, but as described above I think we should provide better
mechanisms if it is considered an important use case. Using global
variables for communication between parts has rightfully been recognized
as an anti pattern for decades. It just doesn't scale as all part must
know and cooperate about some global resources.
I think we should leave it the way it is and provide three maps:
- getLocalRequestAttributes()
- getGlobalRequestAttributes()
- getAllRequestAttributes() - combines the two
(We can use different names, but I think we should have this functionality).
We could do that, but it seem like a quite heavy burden for keeping
compability with something we should have taken care of as soon as we
introduced internal requests (although I understand that it wasn't easy
to predict the consequences back then). The getAllRequestAttributes()
seem like FS to me, why do you need it?
/Daniel
