You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Andrzej Jan Taramina <an...@chaeron.com> on 2003/11/12 21:08:59 UTC
Revised ResourceLoadAction posted...
I've updated my ResourceLoadAction so that it optionally will save the
resource stream data (as a string) in your session/request with a given
attribute name.
The optional write-to and attribute-name parameters, if specified, will cause
the ResourceLoadAction do the save. write-to can be either session or
request (session is default). Your choice of attribute name.
So an invocation in your pipeline would look something like this:
<map:act type="resource-load" src="cocoon:/my.pipeline>
<map:parameter name="write-to" value="request"/>
<map:parameter name="attribute-name" value="my.output"/>
...
<map:act>
This becomes very useful if you have a pipeline that produces a document that
you then want to save into a database column using a Modular Database Action.
By allowing you to store the resource stream as a string in your
session/request, you can get access to it from a Database Action (using Input
Modules). I use this to save XML documents, created by a pipeline, into a
database.
Source can be found in bugzilla, at:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24389
Enjoy!
....Andrzej
PS. Sylvain....don't say I don't contribute back to Cocoon! <grins>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: DOM Protocol, Was: Revised ResourceLoadAction posted...
Posted by Vadim Gritsenko <va...@verizon.net>.
Daniel Fagerstrom wrote:
> Vadim Gritsenko wrote:
>
>> Sylvain Wallez wrote:
>>
>>> Vadim Gritsenko wrote:
>>>
>>>> My initial though was to have following syntax:
>>>>
>>>> dom:[request|session|context]:<attribute-name>#<jxpath>
>>>>
>>>> Xpath, and '#' symbol is obviously optional, and '#' was chosen for
>>>> consistency with existing xmldb: protocol.
>>>
>>>
>>> Just some thoughts:
>>> - why "dom" only? We should also allow XMLizable objects.
>>
>>
>> "dom" is good and short protocol name. XMLizable can be (and should
>> be) easily supported, too. I thought of JXPath, actually, which would
>> support Java Beans and collections too.
>
>
> Ok, JXPath is used on the object in the attribute and returns the
> object pointed to, if this object is XMLizable or DOM it is serialized
> to XML otherwize the source throws an exception.
Ok
> One could of course use Castor or Betwixt or something similar to
> XMLize any bean structure, but I think that can wait to later.
Of course, it can wait.
>>> - what about using input modules?
>>
> Seem like a good idea, as long as we keep the focus on XMLizable objects.
>
>> Good idea! Do we have upload module already? This will quickly
>> deprecate part: protocol :)
>
>
> In that case I think we should have two protocols: "xmodule:" that is
> XMLizable, and "module:", that takes care of things that are natural
> to read and write as general octet streams.
I think one is enough. If obtained Object can be streamed, it can be
then parsed using XMLParser. But this, of course, also can wait, no need
to implement all these right away.
> But I don't know, AFAIK there are no modules that returns streams
> currently, does it realy make sense to move stream handling
> functionality to modules.
RawRequestParameterModule can return uploaded Part which will have
File...... Hmm... :)
>>> We already have some modules that give access to all the
>>> above-mentioned attributes and more. This avoids code duplication,
>>> improves consistency and allows further extension by simply adding
>>> new input-modules.
>>>
>>> Considering this, we should find another name for the protocol:
>>> "input-module" (too long), "module" (not significant enough),
>>> "xml-module" (better)?
>>
>>
>> Still long ;-) How about "xmodule"? :)
>
>
>> And then the protocol syntax becomes:
>>
>>> xml-module:<module-name>:<attribute-name>#<jxpath>
>>>
>>> E.g. "xml-module:session-attr:purchase-order#item[1]"
>>
>>
>> xmodule:session:purchase-order#item[1] is even better ;-)
>
>
> Ok, seem good except for that session-attr is the name of the module
> in the standard cocoon.xconf, so I think we should stick to that.
Ok
> Remaining question is what to do about the the output aspect of the
> source. One of the reasons for me to wanting an dom: source is that I
> want a convinient way to store XML output from the processPipelineTo
> function in flowscripts (actually I think we should have a version of
> it that takes a ModifiableSource name as input instead of an
> java.io.OutputStream). I'm not that keen in leting strive for
> generality kill one of my main use cases.
>
> My current implementation use just replace the attribute value with a
> dom object created from the XML written into the output stream, when
> used without xpath. With xpath it uses JXPath in lenient mode together
> with o.a.c.util.jxpath.DOMFactory. This would be quite hard to
> generalize to more general objects like JavaBean graphs, at least it
> would require a quite heavy machinery with configurations for deciding
> what factories that shoud be used for the various objects.
But it should work if you want to stick DOM as an attribute of some
JavaBean, right?
> For the time beeing I prefer to concentrate on writing to dom trees.
> If I limit the scope of the xmodules, I will be able to put it in
> bugzilla faster, so that people with other scratches to itch will be
> able to do something about them :)
Sure! Don't take every wild thought too close, don't let them slow you
down to a halt :)
Sylvain Wallez wrote:
> But the way to do this assignation isn't clear to me yet: should we
> use output-modules, but in that case what about the xpath expression,
> or should we use input-modules when there's an xpath and
> output-modules when there isn't any?
It's getting messier with modules... Ideally same module type should be
used everytime... Any chance of output modules providing xpath API?
Vadim
Re: DOM Protocol, Was: Revised ResourceLoadAction posted...
Posted by Sylvain Wallez <sy...@apache.org>.
Daniel Fagerstrom wrote:
> Vadim Gritsenko wrote:
>
>> Sylvain Wallez wrote:
>>
>>> Vadim Gritsenko wrote:
>>>
>>>> My initial though was to have following syntax:
>>>>
>>>> dom:[request|session|context]:<attribute-name>#<jxpath>
>>>>
>>>> Xpath, and '#' symbol is obviously optional, and '#' was chosen for
>>>> consistency with existing xmldb: protocol.
>>>
>>>
>>> Just some thoughts:
>>> - why "dom" only? We should also allow XMLizable objects.
>>
>>
>> "dom" is good and short protocol name. XMLizable can be (and should
>> be) easily supported, too. I thought of JXPath, actually, which would
>> support Java Beans and collections too.
>
>
> Ok, JXPath is used on the object in the attribute and returns the
> object pointed to, if this object is XMLizable or DOM it is serialized
> to XML otherwize the source throws an exception. One could of course
> use Castor or Betwixt or something similar to XMLize any bean
> structure, but I think that can wait to later. It would probably
> require using some configuration files as well and would probably
> complicate the use of the protocol.
>
>>> - what about using input modules?
>>
>
> Seem like a good idea, as long as we keep the focus on XMLizable objects.
>
>> Good idea! Do we have upload module already? This will quickly
>> deprecate part: protocol :)
>
>
> In that case I think we should have two protocols: "xmodule:" that is
> XMLizable, and "module:", that takes care of things that are natural
> to read and write as general octet streams. But I don't know, AFAIK
> there are no modules that returns streams currently, does it realy
> make sense to move stream handling functionality to modules. We have a
> quite fine grained family of source protocol, that gives lot of
> information about in what ways a source can be accesed, while modules
> returns objects, and thus don't say anything all about how you can
> access the object
I agree here: modules can handle objects (including DOM and XMLizable
which are of interest here), but not streams.
>>> We already have some modules that give access to all the
>>> above-mentioned attributes and more. This avoids code duplication,
>>> improves consistency and allows further extension by simply adding
>>> new input-modules.
>>>
>>> Considering this, we should find another name for the protocol:
>>> "input-module" (too long), "module" (not significant enough),
>>> "xml-module" (better)?
>>
>>
>> Still long ;-) How about "xmodule"? :)
>
"xmodule" sounds good.
>> And then the protocol syntax becomes:
>>
>>> xml-module:<module-name>:<attribute-name>#<jxpath>
>>>
>>> E.g. "xml-module:session-attr:purchase-order#item[1]"
>>
>>
>> xmodule:session:purchase-order#item[1] is even better ;-)
>
>
> Ok, seem good except for that session-attr is the name of the module
> in the standard cocoon.xconf, so I think we should stick to that.
Yep.
> Remaining question is what to do about the the output aspect of the
> source. One of the reasons for me to wanting an dom: source is that I
> want a convinient way to store XML output from the processPipelineTo
> function in flowscripts (actually I think we should have a version of
> it that takes a ModifiableSource name as input instead of an
> java.io.OutputStream). I'm not that keen in leting strive for
> generality kill one of my main use cases.
>
> My current implementation use just replace the attribute value with a
> dom object created from the XML written into the output stream, when
> used without xpath. With xpath it uses JXPath in lenient mode together
> with o.a.c.util.jxpath.DOMFactory. This would be quite hard to
> generalize to more general objects like JavaBean graphs, at least it
> would require a quite heavy machinery with configurations for deciding
> what factories that shoud be used for the various objects.
>
> For the time beeing I prefer to concentrate on writing to dom trees.
> If I limit the scope of the xmodules, I will be able to put it in
> bugzilla faster, so that people with other scratches to itch will be
> able to do something about them :)
Let's stick to DOM for now: build a DOM from the data on the stream and
assign it to the module and xpath.
But the way to do this assignation isn't clear to me yet: should we use
output-modules, but in that case what about the xpath expression, or
should we use input-modules when there's an xpath and output-modules
when there isn't any?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: DOM Protocol, Was: Revised ResourceLoadAction posted...
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Vadim Gritsenko wrote:
> Sylvain Wallez wrote:
>
>> Vadim Gritsenko wrote:
>>
>>> My initial though was to have following syntax:
>>>
>>> dom:[request|session|context]:<attribute-name>#<jxpath>
>>>
>>> Xpath, and '#' symbol is obviously optional, and '#' was chosen for
>>> consistency with existing xmldb: protocol.
>>
>> Just some thoughts:
>> - why "dom" only? We should also allow XMLizable objects.
>
> "dom" is good and short protocol name. XMLizable can be (and should
> be) easily supported, too. I thought of JXPath, actually, which would
> support Java Beans and collections too.
Ok, JXPath is used on the object in the attribute and returns the object
pointed to, if this object is XMLizable or DOM it is serialized to XML
otherwize the source throws an exception. One could of course use Castor
or Betwixt or something similar to XMLize any bean structure, but I
think that can wait to later. It would probably require using some
configuration files as well and would probably complicate the use of the
protocol.
>
>> - what about using input modules?
>
Seem like a good idea, as long as we keep the focus on XMLizable objects.
> Good idea! Do we have upload module already? This will quickly
> deprecate part: protocol :)
In that case I think we should have two protocols: "xmodule:" that is
XMLizable, and "module:", that takes care of things that are natural to
read and write as general octet streams. But I don't know, AFAIK there
are no modules that returns streams currently, does it realy make sense
to move stream handling functionality to modules. We have a quite fine
grained family of source protocol, that gives lot of information about
in what ways a source can be accesed, while modules returns objects, and
thus don't say anything all about how you can access the object
>
>> We already have some modules that give access to all the
>> above-mentioned attributes and more. This avoids code duplication,
>> improves consistency and allows further extension by simply adding
>> new input-modules.
>>
>> Considering this, we should find another name for the protocol:
>> "input-module" (too long), "module" (not significant enough),
>> "xml-module" (better)?
>
> Still long ;-) How about "xmodule"? :)
> And then the protocol syntax becomes:
>
>> xml-module:<module-name>:<attribute-name>#<jxpath>
>>
>> E.g. "xml-module:session-attr:purchase-order#item[1]"
>
> xmodule:session:purchase-order#item[1] is even better ;-)
Ok, seem good except for that session-attr is the name of the module in
the standard cocoon.xconf, so I think we should stick to that.
Remaining question is what to do about the the output aspect of the
source. One of the reasons for me to wanting an dom: source is that I
want a convinient way to store XML output from the processPipelineTo
function in flowscripts (actually I think we should have a version of it
that takes a ModifiableSource name as input instead of an
java.io.OutputStream). I'm not that keen in leting strive for generality
kill one of my main use cases.
My current implementation use just replace the attribute value with a
dom object created from the XML written into the output stream, when
used without xpath. With xpath it uses JXPath in lenient mode together
with o.a.c.util.jxpath.DOMFactory. This would be quite hard to
generalize to more general objects like JavaBean graphs, at least it
would require a quite heavy machinery with configurations for deciding
what factories that shoud be used for the various objects.
For the time beeing I prefer to concentrate on writing to dom trees. If
I limit the scope of the xmodules, I will be able to put it in bugzilla
faster, so that people with other scratches to itch will be able to do
something about them :)
/Daniel
Re: DOM Protocol, Was: Revised ResourceLoadAction posted...
Posted by Vadim Gritsenko <va...@verizon.net>.
Sylvain Wallez wrote:
> Vadim Gritsenko wrote:
>
>> My initial though was to have following syntax:
>>
>> dom:[request|session|context]:<attribute-name>#<jxpath>
>>
>> Xpath, and '#' symbol is obviously optional, and '#' was chosen for
>> consistency with existing xmldb: protocol.
>
>
>
> Just some thoughts:
> - why "dom" only? We should also allow XMLizable objects.
"dom" is good and short protocol name. XMLizable can be (and should be)
easily supported, too. I thought of JXPath, actually, which would
support Java Beans and collections too.
> - what about using input modules?
Good idea! Do we have upload module already? This will quickly deprecate
part: protocol :)
> We already have some modules that give access to all the
> above-mentioned attributes and more. This avoids code duplication,
> improves consistency and allows further extension by simply adding new
> input-modules.
>
> Considering this, we should find another name for the protocol:
> "input-module" (too long), "module" (not significant enough),
> "xml-module" (better)?
Still long ;-) How about "xmodule"? :)
> And then the protocol syntax becomes:
> xml-module:<module-name>:<attribute-name>#<jxpath>
>
> E.g. "xml-module:session-attr:purchase-order#item[1]"
xmodule:session:purchase-order#item[1] is even better ;-)
Vadim
Re: DOM Protocol, Was: Revised ResourceLoadAction posted...
Posted by Sylvain Wallez <sy...@apache.org>.
Vadim Gritsenko wrote:
> danielf@nada.kth.se wrote:
>
>> If I extend it to handle request / session / application context,
>> which seem like a good idea, what syntax would be reasonable?
>>
>> dom:/[request,session,context]/attribute-name/xpath
>>
>> or maybe one should be a little bit more specific:
>>
>> dom:/[request-attribute,session-attribute,context-attribute]/attribute-name/xpath
>>
>>
>>
>
> request-attribute is too verbose for my taste...
>
>
>> One could also have some kind of sub-protocols for choosing how the
>> write
>> operation should be performed:
>>
>> dom:write:/...
>>
>>
>
> Write sub protocol is not needed, AFAIU.
>
>
>> dom:insert:/...
>>
>>
>
> If node specified by the xpath does not exist, it will be created on
> write; otherwise -- replaced. If you want to insert after specific
> node... Yes, this will require some kind of indication... What other
> options exist except using sub-protocol?
>
>
>> WDYT?
>>
>>
>
> My initial though was to have following syntax:
>
> dom:[request|session|context]:<attribute-name>#<jxpath>
>
> Xpath, and '#' symbol is obviously optional, and '#' was chosen for
> consistency with existing xmldb: protocol.
Just some thoughts:
- why "dom" only? We should also allow XMLizable objects.
- what about using input modules? We already have some modules that give
access to all the above-mentioned attributes and more. This avoids code
duplication, improves consistency and allows further extension by simply
adding new input-modules.
Considering this, we should find another name for the protocol:
"input-module" (too long), "module" (not significant enough),
"xml-module" (better)?
And then the protocol syntax becomes:
xml-module:<module-name>:<attribute-name>#<jxpath>
E.g. "xml-module:session-attr:purchase-order#item[1]"
WDYT?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: DOM Protocol, Was: Revised ResourceLoadAction posted...
Posted by Vadim Gritsenko <va...@verizon.net>.
danielf@nada.kth.se wrote:
>Vadim Gritsenko wrote:
>
>
>>My initial though was to have following syntax:
>>
>> dom:[request|session|context]:<attribute-name>#<jxpath>
>>
>>Xpath, and '#' symbol is obviously optional, and '#' was chosen for
>>
>>
>consistency with existing xmldb: protocol.
>
>I like the "#" part, but all the ":" looks strange to me. I prefer
>thinking of the attribute type and the attribute name as a hierarchy:
>
> dom:/[request|session|context]/<attribute-name>#<jxpath>
>
>or are there other examples of protocols that use ":" in the way that you
>propose?
>
>
Sure! :)
jdbc:oracle:thin: ...
xmldb:xindice: ....
>I make the DOMSource XMLizable so that one can read XML in an efficient
>way from it, (like in e.g. the XMLDBSource and QdocsSource).
>
Cool.
>Do you know
>if there is some prefered mechanism for makeing modifyable sources SAX
>writable. In Cocoon 2.0 there existed an interface
>o.a.c.components.source.WritableSAXSource, that had a method for
>returning a content handler, for such purposes. I have not found
>anything similar in Cocoon 2.1. Should I make the DOMSource an
>XMLConsumer or just don't care about it and only use an otput stream?
>
>
Hmmm... Just don't care about it now -- if anything, it will be fixed later.
Vadim
Re: DOM Protocol, Was: Revised ResourceLoadAction posted...
Posted by da...@nada.kth.se.
Vadim Gritsenko wrote:
> danielf@nada.kth.se wrote:
>> If I extend it to handle request / session / application context,
which seem like a good idea, what syntax would be reasonable?
>> dom:/[request,session,context]/attribute-name/xpath
>> or maybe one should be a little bit more specific:
>> dom:/[request-attribute,session-attribute,context-attribute]/attribute-name/xpath
> request-attribute is too verbose for my taste...
Ok, I guess that there is no risk of confusing with request parameters or
the request object in a dom source so we can use the shorter form.
>> One could also have some kind of sub-protocols for choosing how the
write
>> operation should be performed:
>> dom:write:/...
>>
> Write sub protocol is not needed, AFAIU.
Yes, after having thought a litle bit more about it I came to the same
conclusion.
>> dom:insert:/...
>>
> If node specified by the xpath does not exist, it will be created on
write; otherwise -- replaced. If you want to insert after specific
node... Yes, this will require some kind of indication... What other
options exist except using sub-protocol?
In the SourceWritingTransformer this is solved in the way that if you
write a path /foo/bar, the bar element will be inserted after all other
child elements of foo. if a more specific path /foo/bar[1], is given and
there is a bar element as child to foo, it will be replaced. I think that
is a good and intuitive solution, the SWT also has some (IMHO quite non
intuitiv) mechanism for inserting an element before the other ones, but I
doubt that it is worthwhile to complicate the dom stream with that.
> My initial though was to have following syntax:
>
> dom:[request|session|context]:<attribute-name>#<jxpath>
>
> Xpath, and '#' symbol is obviously optional, and '#' was chosen for
consistency with existing xmldb: protocol.
I like the "#" part, but all the ":" looks strange to me. I prefer
thinking of the attribute type and the attribute name as a hierarchy:
dom:/[request|session|context]/<attribute-name>#<jxpath>
or are there other examples of protocols that use ":" in the way that you
propose?
I work on the code right now. Most of the involved interfaces has changed
since I worked on it one and a half year ago, so it is a litle bit more
work than I though, (but what isn't ;) ).
I make the DOMSource XMLizable so that one can read XML in an efficient
way from it, (like in e.g. the XMLDBSource and QdocsSource). Do you know
if there is some prefered mechanism for makeing modifyable sources SAX
writable. In Cocoon 2.0 there existed an interface
o.a.c.components.source.WritableSAXSource, that had a method for
returning a content handler, for such purposes. I have not found
anything similar in Cocoon 2.1. Should I make the DOMSource an
XMLConsumer or just don't care about it and only use an otput stream?
/Daniel
DOM Protocol, Was: Revised ResourceLoadAction posted...
Posted by Vadim Gritsenko <va...@verizon.net>.
danielf@nada.kth.se wrote:
>If I extend it to handle request / session / application context, which
>seem like a good idea, what syntax would be reasonable?
>
>dom:/[request,session,context]/attribute-name/xpath
>
>or maybe one should be a little bit more specific:
>
>dom:/[request-attribute,session-attribute,context-attribute]/attribute-name/xpath
>
>
request-attribute is too verbose for my taste...
>One could also have some kind of sub-protocols for choosing how the write
>operation should be performed:
>
>dom:write:/...
>
>
Write sub protocol is not needed, AFAIU.
>dom:insert:/...
>
>
If node specified by the xpath does not exist, it will be created on
write; otherwise -- replaced. If you want to insert after specific
node... Yes, this will require some kind of indication... What other
options exist except using sub-protocol?
>WDYT?
>
>
My initial though was to have following syntax:
dom:[request|session|context]:<attribute-name>#<jxpath>
Xpath, and '#' symbol is obviously optional, and '#' was chosen for
consistency with existing xmldb: protocol.
Vadim
Re: Revised ResourceLoadAction posted...
Posted by da...@nada.kth.se.
Vadim Gritsenko wrote:
> Joerg Heinicke wrote:
>> On 12.11.2003 23:26, Vadim Gritsenko wrote:
<snip/>
>>> Had anybody considered writing some dom:/ pseudo protocol to
>>> save/retrieve DOM fragments to/from request / session / application
context?
>> We have a Read/WriteDomSessionTransformer (for which Andrzej provided
also a patch) doing this stuff. You mean replacing them with a dom
pseudo protocol for simplicity and transparency?
>
> Yep. And use CInclude to read and SourceWritingT to write (CExclude ;-)
I have a nearly finished such source at my hard disk since ages, that I
almost had forgotten. As you made it sound really useful, I think that I
maybe should finish it ;)
In its current incarnation it can be used for reading a fragment from a
dom tree in a session parameter, described by an xpath. It an be also be
used for writing or inserting xml in a dom tree in a session parameter at
an xpath.
The current syntax is something like:
session:/attribute-name/xpath
If I extend it to handle request / session / application context, which
seem like a good idea, what syntax would be reasonable?
dom:/[request,session,context]/attribute-name/xpath
or maybe one should be a little bit more specific:
dom:/[request-attribute,session-attribute,context-attribute]/attribute-name/xpath
One could also have some kind of sub-protocols for choosing how the write
operation should be performed:
dom:write:/...
dom:insert:/...
WDYT?
/Daniel
Re: Revised ResourceLoadAction posted...
Posted by Vadim Gritsenko <va...@verizon.net>.
Joerg Heinicke wrote:
> On 12.11.2003 23:26, Vadim Gritsenko wrote:
>
>>>> I've updated my ResourceLoadAction so that it optionally will save
>>>> the resource stream data (as a string) in your session/request with
>>>> a given attribute name.
>>>
>>>
>>>
>>>
>>> Technically speaking now, have you considered using output modules
>>> to indicate where the resource should be loaded? This should be more
>>> versatile than a fixed choice between session and request.
>>
>>
>>
>>
>> Had anybody considered writing some dom:/ pseudo protocol to
>> save/retrieve DOM fragments to/from request / session / application
>> context?
>
>
> We have a Read/WriteDomSessionTransformer (for which Andrzej provided
> also a patch) doing this stuff. You mean replacing them with a dom
> pseudo protocol for simplicity and transparency?
Yep. And use CInclude to read and SourceWritingT to write (CExclude ;-)
Vadim
Re: Revised ResourceLoadAction posted...
Posted by Joerg Heinicke <jh...@virbus.de>.
On 12.11.2003 23:26, Vadim Gritsenko wrote:
>>> I've updated my ResourceLoadAction so that it optionally will save
>>> the resource stream data (as a string) in your session/request with a
>>> given attribute name.
>>
>>
>>
>> Technically speaking now, have you considered using output modules to
>> indicate where the resource should be loaded? This should be more
>> versatile than a fixed choice between session and request.
>
>
>
> Had anybody considered writing some dom:/ pseudo protocol to
> save/retrieve DOM fragments to/from request / session / application
> context?
We have a Read/WriteDomSessionTransformer (for which Andrzej provided
also a patch) doing this stuff. You mean replacing them with a dom
pseudo protocol for simplicity and transparency? Sound good.
Joerg
Re: Revised ResourceLoadAction posted...
Posted by Vadim Gritsenko <va...@verizon.net>.
Sylvain Wallez wrote:
> Andrzej Jan Taramina wrote:
>
>> I've updated my ResourceLoadAction so that it optionally will save
>> the resource stream data (as a string) in your session/request with a
>> given attribute name.
>
>
> Technically speaking now, have you considered using output modules to
> indicate where the resource should be loaded? This should be more
> versatile than a fixed choice between session and request.
Had anybody considered writing some dom:/ pseudo protocol to
save/retrieve DOM fragments to/from request / session / application context?
Vadim
Re: Revised ResourceLoadAction posted...
Posted by Sylvain Wallez <sy...@apache.org>.
Andrzej Jan Taramina wrote:
>I've updated my ResourceLoadAction so that it optionally will save the resource stream data (as a string) in your session/request with a given attribute name.
>
>The optional write-to and attribute-name parameters, if specified, will cause the ResourceLoadAction do the save. write-to can be either session or request (session is default). Your choice of attribute name.
>
>
<snip/>
>PS. Sylvain....don't say I don't contribute back to Cocoon! <grins>
>
>
Please Andrzej, stop yelling at me. I was just the voice of the
community on this. I know saying this looks like an easy way to protect
myself, but the results of the vote show how much true this actually is.
And I'm also very pleased to see that you keep participating despite
what happened lately.
Technically speaking now, have you considered using output modules to
indicate where the resource should be loaded? This should be more
versatile than a fixed choice between session and request.
Ah, and one last thing: it's not useful to crosspost dev@ and users@
(and sometimes myself) for every message.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com