Daniel Fagerstrom schrieb:
was Re: [jira] Created: (COCOON-1943) [Patch] Parameters in
blocks-protocol URIs get decoded too early
While your input module can be usable in its own right I think that we
should make the block protocol postable. Besides that it simplify
reusing form handling as you describe above. I think that it is
generally useful to make it possible to let blocks contain web services
that can be called through the block protocol and be used as some webapp
internal web services.
My solution is a quick way to at least achieve it in some way. It is not
a perfect solution.
To achieve this the o.a.c.blocks.util.BlockCallHttpServletRequest needs
to be extended with input handling and
o.a.c.blocks.components.BlockSource need to implement ModifiableSource
and o.a.c.blocks.BlockProtocol needs to take care of the input.
This sounds like a good idea. This would enable one to stream data into
the block call.
The critique was mainly about my extension of the
SourceWritingTransformer, I still think it would be a good idea to have
postable sources and especially to make the block protocol postable.
Regarding the "API" side of the blocks protocol, it would be nice, to be
able to call it from the sitemap without much overhead. One idea would
be to extend the map:call to allow to specify a block as target, eg.
<map:call resource="layouting" block="super" /> to call the layouting
resource in the super block. So one could call matchers and resources of
another block, don't know if it is a good idea (and even technically
possible) to call continuations or flowscripts in the other block. With
your proposed change to provide a modifiable BlockSource one is able to
stream stuff into it and get something out. This is true for calling
resources and matchers with request body (my form case). For the last
case it should be easily possible to pass the request parameters on to
the block call with a simple statement in the sitemap.
Alex
--
Alexander Klimetschek
http://www.mindquarry.com
