Hi Sergey,
2011/7/25 Sergey Beryozkin <[email protected]>:
> Hi Aki,
>> 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 ?
For the last two (the simple content mode), Using the position
identifier "{http:books}dvd" to indicate the insertion of the book
element after the dvd element in the same level (as there is no
trailing "/"). In contrast, using "{http:books}order/" to indicate the
insertion of the book element in the next level below the order
element (as the trailing "/" is present here). In this way, we can
distinguish the two variants: inserting after the specified element in
the same level or inserting after the element in the next level.
In any case, we need this "append-afer-in-the-next-level" rather than
"append-before" in order to be able to append an element within an
empty element.
eg. suppose we have
<orders></orders>
and we want to add <order>orange</order> in the order's empty content,
which means to produce
<orders><order>orange</order></orders>
we can use
key="order:orange" value="orders/"
if we provide only append-after and append-before in the same level,
we cannot achieve this operation (as there is no element after or
before to mark the postion of the insertion). The benefit of assuming
the append-after intead of append-before is that this intuitive
trailing slash notation can be used to denote this particular
insertion operation.
Technically, we might also want to have two wrapping operations: the
normal wrap and the wrap-the-next-level, where the normal wrap being
the current append's wrapping operation.
eg suppose we have
<orders>
<book>cxf</book>
<dvd>camel</dvd>
</orders>
and we want to produce
<orders>
<order>
<book>cxf</book>
<dvd>camel</dvd>
</order>
</orders>
It would be easier to have this wrap-the-next-level notation. This can
be probably written as
key="order" value="orders/"
with having the trailing "/" to indicate the wrapping to take place
for the children on the orders element instead of the element itself.
How do you think?
regards, aki
>
> 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
>>>
>
