2011/7/25 Sergey Beryozkin <[email protected]>:
> Hi,
>>
>> Hi Sergey,
>>
>> 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>.
regards, aki
>
> Cheers, Sergey
>
>> regards, aki
>>
>>> Cheers, Sergey
>>>
>>>> regards, aki
>>>>>
>>>>> thanks, Sergey
>>>>>
>>>>>> thanks.
>>>>>> regards, aki
>
>
