Alexander Klimetschek skrev:
Daniel Fagerstrom schrieb:
...
This could be complemented by giving access to the original request
parameters. For this case we need a call stack where each block
protocol call pushes a new request object, and where all parameter
lookup is done through the stack.
For request attributes the situation is more complicated, we need a
call stack where the local attribute context is pushed. Otherwise
your block will aways risk that some other block in the call chain
happen to use the same parameter name and affect your block. But you
probably also need to be able to set the global attribute to
communicate state information between blocks. For the Cocoon protocol
this is done by having booth a global and a local scope for
parameters (see o.a.c.environment.Request). But this solution
requires an extension to the standard HttpServletRequest, and I
preferred to avoid that. But if we have a need for it we could extend
the current design.
For the rest of the request (and response) object we would need to
evaluate what should be available everywhere and what should be
specific for the current block call.
I see, it's difficult. My case is attribute-readonly after the
listener, so it is quite simple. The distinction between global and
local parameters would be important, since otherwise you'd only had
the attributes of the previous block call at hand (if there is more
than 1 call to different blocks).
It wouldn't need to be that bad. What I have in mind for local access is
a construction like this:
There is a call stack for request attributes consisting of hash tables.
Each time a block call is made an empty hash table is pushed on the
stack and each time a block call leave the stack is poped.
A setAttribute will affect the *topmost* element of the stack and thus
only have an effect during the ongoing block call.
A removeAttribute will but a special "empty element" for that attribute
into the topmost hash table.
A getAttribute will search the stack top down until it find the
attribute, if it has the "empty" value it will return null otherwise it
will return the value of the attribute. If the attribute is not
available in any of the hash tables it will return null.
This will work in most scenarios, attributes are available for blocks
further down the call chain. But blocks cannot communicate to cannot
communicate through attributes to blocks higher in the call chain or to
"siblings" in the call chain.
The global scope would always affect the original request attribute.
Which always is highest in the call stack.
There should be a simple possibility, just remove the block path
property from a managed servlet and then the dispatcher servlet will
not use it. And it will still be available as a component and thus
possible to connect to and use through the block protocol. Now this
will not be usable for the block servlet as it has a getBlockPath
method and therefore always will be connected. If we strengthen the
condition in the dispatcher servlet to only connect to servlet that
has a *non null* block path property, it would be enough to not
configure the block path property to make the block servlet internal..
I currently only have the BlockServlet in place. Apart from that,
there are blocks that contain both external matchers (open to the
script kiddies) and internal ones, so deciding at the block level
would no help as everything in that sitemap would be internal. What
about extending the pipeline parameter internal-only="true" to accept
the values (true|false|block), where block means visible for blocks
but not for external requests?
OK, I see. It seem like a useful feature. Any idea about how to
implement it ?
/Daniel
