cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dani...@nada.kth.se
Subject Re: DOM Protocol, Was: Revised ResourceLoadAction posted...
Date Mon, 17 Nov 2003 22:41:39 GMT
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





Mime
View raw message