Hi Aki,
2011/7/25 Sergey Beryozkin<[email protected]>:
Not necessarily, as those namespaces are first referenced in the child
element where they are declared, their declarations need not be move
up to its parent, which is the appended element.
I saw StaxUtils doing reader.getNamespaceCount() and I was not sure how
to
correctly report that in case of appended element the count is 1 :-)
Okay. I missed this one. I need to overwrite this method to report the
correct value.
By the way, there's one more limitation there which I haven't got to
addressing yet - to do with being able append simple elements -
currently
it
is possible to add wrappers but it's not possible to add a simple
element
say to the end of the given element's content
We could add this feature, but is it interesting to add an empty
content element this way? I think we will probably need to provide a
way to set its content for this option, preferably filling some
content template using some runtime context values. This will likely
to require another configuraiton object.
Agreed - I meant a simple element with a text content only...
inAppendElements/outAppendElements say which elements need to be wrapped
,
or rather, they say "append this element before this one".
So may be we can have
in/outAppendSimpleElements with the "append this element after this one"
message ? Say, "{http://books}id:1":"{http://books}book:title";, "add a
book
ns qualified<id>1</id> after<title>...</title>"
Looks a bit btittle :-) but something along those lines
In this case, we might need to rename the current append to "wrap" and
the current drop to "unwrap" ;-)
But I think the append within a sequence is difficult to configure. If
you fix the append-logic to "append-after", you can't append/insert an
element at the very begining. So, that means we will need two
variants: append-before and append-after. Then, the notation will get
even more complicated.
We'll see if there is some simpler way.
Perhaps we cam always assume the "after" approach always means after the end
of a given element.
And we can enhance/fix a bit the existing append "wrap" approach (sorry, the
property is a bit misnamed :-))), if we have {http:books}book - then it
means wrap, and if we have {http:books}book:value then it means just append
a simple element
So may be that would cover all the append cases?
That looks like a cute idea. Along this line, we could even provide
the way to insert an element at the very beginning so that there is no
need for the append-before mode.
key="{http:books}order" value="{http:books}dvd"
will wrap the<ns:dvd> element with<ns:order> element.
key="{http:books}book:cxf" value="{http:books}dvd"
will add<ns:book>cxf</ns:book> after<ns:dvd> element.
key="{http:books}book:cxf" value="{http:books}oder/"
will add<ns:book>cxf</ns:book> as the first child of<ns:order>.
How will we differentiate in the last 2 examples whether it's before or
after case ?
I'm seeing it a bit differently as I'm assuming at the moment that
existing inAppendMap and outAppendMap are still used only for the
append-before mode, where key is the element to append, but with some
enhancements:
key="{http:books}order" value="{http:books}dvd"
will wrap dvd with order, same as in your example
key="{http:books}book:cxf" value="{http:books}dvd"
will add<ns:book>cxf</ns:book> before <ns:dvd> element.
key="{http:books}book:cxf" value="{http:books}oder/"
will add <ns:book>cxf</ns:book> before <ns:order>.
and we'd need a dedicated configuration element for the append-after case.
So given
<orders><order><id/></order></orders>
we can have all <orders> or all <order> or <id> wrapped with say
"wrapper", using the append-before mode.
Next, we can have say "a:b" (<a>b</a>) before order, or id only.
Attempting to add it before orders will lead to malformed xml.
Next we can get c:d after id or after order.
That should cover all the variations, but may be I'm not seeing all the
details :-). The only thing I don't like is that saying "insert after
id" is not terribly safe because we may multiple ids in the doc with
some ids being in a diff context - but I would not worry about it for
now :-), we can assume we can have only orders containing ids and such...
Cheers, Sergey
regards, aki
