By luck.. :) No really, what basically happens is on an action we
assume we always have a new request. When the action ends, we save a
flag to a session scoped object we have which carries our configurator
state. It is then picked up in the subsequent render and removed at the
end of the render phase altogether.
So it "technically" knows about the action and the first render after
the action. Following renders are treated as new physical requests.
The new configurator system I'm working on for commons allows you access
to a MAP which is also stored on this session object that has the same
lifespan, but right now Trinidad Configurators have to use session scope
(or another means they divise) for their objects. Most of the time it's
environment setup stuff which, when combined with JSR-301's managed
request scope, covers most all our usecases. But there are exceptions
and in the commons configurators I figured it would be much easier to
let the configurator framework handle all the complexity. I mean since
we're storing and maintaining the state object anyway, we may as well
let others put custom configuration stuff on it.
Scott
Felix Roethenbacher wrote:
Hi Scott
Makes sense! One question remains though: obviously the
GlobalConfigurator makes sure that general Configurator's
beginRequest()/endRequest() are only called once per physical
request. How do you detect the end of a physical request in
a portal environment? According to the spec the portlet-bridge
might - after an initial action request - send one or more
render requests. How does the GlobalConfigurator knows when
the last render request has been processed?
Thanks for your explanations.
- Felix
Scott O'Bryan wrote:
Felix,
The global configurator is not a typical configurator. In a normal
Portlet 1.0 environment, there is no guarentee that request scope is
preserved between action and render. So yes, the GlobalConfigurator
gets called for each request (action and then render). Under the
covers, it makes sure that YOUR configurators, the ones implementing
the configurator interface, are run once per physical request.
The new configurator framework (which was delayed because of some
additional usecases) that will be added to the commons project have
the concept of "Detailed Execution" vs. "Normal Execution".
Configurators which require "Detailed Execution" are run once per
"virtual" request. For now, however, the Trinidad Configurators
(with the exception of the GlobalConfigurator) are all "Normal
Execution". BTW- I think it you look at the javadoc for the global
configurator, it says it violates the normal configurator contract.
The global configurator is the base *framework* piece and is in the
impl package. It's designed to be transparent to the other
configurators and it's sole job is to make sure the contract to the
normal configurators is followed.
Another example of how this violates the contract is that if you call
GlobalConfiguratorImpl.beginRequest before you do a
GlobalConfiguratorImpl.init, the thing just initializes the
Configurator framework for you. By contract, your configurators are
guarenteed to have their init's called first, but the
GlobalConfiguratorImpl kinda holds you hand a bit.
Make sense?
Scott
Felix Roethenbacher wrote:
Hi
I currently have issues with Trinidad running in a portal environment
(Pluto RI). The documentation for Configurator states that
beginRequest() / endRequest() should be called exactly once for every
physical request. Whereas the javadoc for beginRequest() in
GlobalConfiguratorImpl states that beginRequest() should be called
for the action request AND render request if running in a portal
environment. This seems conflicting to me.
Can anyone explain the idea behind the Configurators a wee bit more?
I'm trying to get Trinidad running in a portal enviroment but it's
not at the moment for various reasons. I guess there is no test
environment to test for portal compatibility?
Any help is appreciated.
- Felix
