The whole module idea is really great but (please correct me if I'm wrong):
map:generate type=file src=module:request:inputStream/
The o.a.c.components.modules.input.RequestModule provides this:
return ObjectModelHelper.getRequest(objectModel);
getRequest returns o.a.c.environment.Request
Leszek Gawron wrote:
The whole module idea is really great but (please correct me if I'm wrong):
map:generate type=file src=module:request:inputStream/
The o.a.c.components.modules.input.RequestModule provides this:
return ObjectModelHelper.getRequest(objectModel);
getRequest returns
Leszek Gawron wrote:
The whole module idea is really great but (please correct me if I'm wrong):
map:generate type=file src=module:request:inputStream/
The o.a.c.components.modules.input.RequestModule provides this:
return ObjectModelHelper.getRequest(objectModel);
getRequest returns
Upayavira wrote:
Leszek Gawron wrote:
The whole module idea is really great but (please correct me if I'm
wrong):
map:generate type=file src=module:request:inputStream/
The o.a.c.components.modules.input.RequestModule provides this:
return ObjectModelHelper.getRequest(objectModel);
curl -T test.xml
http://localhost:/samples/scratchpad/module-source/test3
this is a tool I was looking for :) up till now I was using pure telnet.
I don't use XSP. Using flowscript I would write a pipeline consisting of
a file generator with module:request:inputStream as source and an
Daniel Fagerstrom wrote:
...
I completely agree with that getInputStream should be added to the
request interface.
Pretty please :-)
I gave some arguments for doing it in
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=104213670731308w=2,
there where also a discussion in
Leszek Gawron wrote:
curl -T test.xml
http://localhost:/samples/scratchpad/module-source/test3
this is a tool I was looking for :) up till now I was using pure telnet.
Yes, it is very usefull, we use it a lot :)
I don't use XSP. Using flowscript I would write a pipeline consisting of
a
Upayavira wrote:
My answer is lets add getInputStream to o.a.c.environment.request.
Before doing so, please go through email archive. There were several
discussions about this topic, some of them are:
Re: StreamGenerator depends on Servlets!!! (input pipelines
discussion in concrete)
Nicola Ken Barozzi wrote:
Daniel Fagerstrom wrote:
...
I completely agree with that getInputStream should be added to the
request interface.
Pretty please :-)
I gave some arguments for doing it in
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=104213670731308w=2,
there where also a
Daniel Fagerstrom wrote:
Upayavira wrote:
Leszek Gawron wrote:
The whole module idea is really great but (please correct me if I'm
wrong):
map:generate type=file src=module:request:inputStream/
The o.a.c.components.modules.input.RequestModule provides this:
return
Daniel Fagerstrom wrote:
Christian Haul wrote:
Ok, quoting the docs for request attributes for example:
Attribute names should follow the same conventions as package names.
Names beginning with java.*, javax.*, and com.sun.*, are reserved for
use by Sun Microsystems.
I had
Christian Haul wrote:
Daniel Fagerstrom wrote:
snip what=cool stuff/
Open Issue
--
A peculiarity in the RequestAttributeOutputModule and
SessionAttributeOutputModule is that they as default prefix all
attribute names with
org.apache.cocoon.components.modules.output.OutputModule, why?
Vadim Gritsenko wrote:
Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
AFAIK the new sources can cover all use cases for the mentioned
components (as well as doing plenty of new things):
Please add to your list FragmentExtractorGenerator and
FragmentExtractorTransformer
Hm. Correction: this
Daniel Fagerstrom wrote:
snip what=cool stuff/
Open Issue
--
A peculiarity in the RequestAttributeOutputModule and
SessionAttributeOutputModule is that they as default prefix all
attribute names with
org.apache.cocoon.components.modules.output.OutputModule, why?
Sorry for the late
Joerg Heinicke wrote:
On 08.01.2004 18:00, Daniel Fagerstrom wrote:
I just committed two new sources to the scratchpad:
* ModuleSource - That reads from streams and strings found by using an
input module. It can among other things replace the StreamGenerator
and the PartSource.
* XModuleSource
Joerg Heinicke wrote:
On 08.01.2004 18:00, Daniel Fagerstrom wrote:
I just committed two new sources to the scratchpad:
* ModuleSource - That reads from streams and strings found by using an
input module. It can among other things replace the StreamGenerator
and the PartSource.
* XModuleSource
Daniel Fagerstrom wrote:
...
AFAIK the new sources can cover all use cases for the mentioned
components (as well as doing plenty of new things):
...
[Read|Write]SessionTransformers
---
...
I forgot to mention the problem with output modules that I described in
the
Daniel Fagerstrom wrote:
...
AFAIK the new sources can cover all use cases for the mentioned
components (as well as doing plenty of new things):
Please add to your list FragmentExtractorGenerator and
FragmentExtractorTransformer which currently reside in the batik block,
... and wikify
Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
...
AFAIK the new sources can cover all use cases for the mentioned
components (as well as doing plenty of new things):
Please add to your list FragmentExtractorGenerator and
FragmentExtractorTransformer
Hm. Correction: this pair actually can
From: Daniel Fagerstrom
I just committed two new sources to the scratchpad:
* ModuleSource - That reads from streams and strings found by
using an
input module. It can among other things replace the
StreamGenerator and
the PartSource.
* XModuleSource - Read and write XML data (DOM
From: Reinhard Poetz [mailto:[EMAIL PROTECTED]
If you have time some examples would be great!
Especially the mentioned flowscript scenario.
uuups, Eclipse doesn't update the examples ;-)
Sorry for the noise!
--
Reinhard
Reinhard Poetz wrote:
From: Daniel Fagerstrom
I just committed two new sources to the scratchpad:
* ModuleSource - That reads from streams and strings found by
...
* XModuleSource - Read and write XML data (DOM and XMLizable)
...
If you have time some examples would be great!
Especially the
22 matches
Mail list logo
