You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Vadim Gritsenko <va...@verizon.net> on 2003/11/17 17:30:43 UTC
DOM Protocol, Was: Revised ResourceLoadAction posted...
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: 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
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