| Re: [bpel-dev] Beautify XML for extension activities |
Hi Bob,
I'm talking of the ElementPlacer.niceInsertBefore() - which is used for adding new activity elements. This does remove _all_ text nodes in child nodes, recursivly (replacing them with whitespace nodes).
I just tested this and added
elementPipelet.appendChild(document.createTextNode("Test"));
to my InvokePipeletSerializer. The text node is stripped by the ElementPlacer and is not visible in the XML view when adding a new "InvokePipelet" element to the pipeline.
To the <extensionActivity> element subtree: from my point of view you would be able to remove half of the code thats dealing with the "special case" of extension activities if you would correct that structure. But don't mind, it was just an idea. I thought about it because I tried to find out what should happen when you remove the whole content of an <extensionActivity> element in the XML view (including the <invokePipelet> element).
By the way, by using
Element invokePipeletElement = invoke.getElement().getFirstChild();
you already dropped into such a pitfall I'm talking about, as the first child will always be a text node, at least for "beautified" XML. If the correct element would be connected, such mistakes would vanish...
I hope I'm able to submit a new version of our extensions this week to keep you uptodate with our changes.
Thanks,
Tobias
________________________________
Von: bpel-dev-bounces@xxxxxxxxxxx im Auftrag von Bob Brodt
Gesendet: Di 1.2.11 18:35
An: BPEL Designer project developer discussions.
Betreff: Re: [bpel-dev] Beautify XML for extension activities
I think you probably misunderstood the way extension activities are handled in the serializer: only the direct descendant child element of <extensionActivity> (your <proc:invokePipelet>) is "stripped" of non-Element nodes, the rest of the descendant tree is left untouched. So, this means that the <proc:pipelet>, <proc:variables> and <proc:PipeletConfiguration> elements and whatever else is attached to the <proc:invokePipelet> element stays intact.
As far as the <extensionActivity> element subtree being attached to the InvokePipeletImpl object, you are correct. But this is how the editor model was originally designed and there are a LOT of places in the code that expect this structure. I think it would be a really bad idea to change all of this now! You simply need to make your code aware of this fact and deal with accordingly: in other words, if you have an InvokePipelet object called "invoke", then:
Element invokePipeletElement = invoke.getElement().getFirstChild();
gives you the XML element subtree that corresponds to the InvokePipelet object.
HTH
_______________________________________
Robert ("Bob") Brodt
Senior Software Engineer, JBoss Riftsaw
JBoss by Red Hat
----- Original Message -----
> Hi Bob,
>
> what I'm referencing are the children of the child element of
> <extensionActivity>. As far as I understand your code you are removing
> any text nodes, recursivly?
>
> To my p.s. - I'm talking about the fact you already mentioned in your
> reply on 01/14.
> In XML you have:
>
> <sequence>
> <extensionActivity>
> <proc:invokePipelet name="...">
> <proc:pipelet class="..." />
> ...
> </proc:invokePipelet>
> </extensionActivity>
> </sequence>
>
> But the created objects are: SequenceImpl -> InvokePipeletImpl ->
> PipeletImpl
> Further more, even if I set the connected element of InvokePipeletImpl
> to <proc:invokePipelet> in my deserializer, you set it to
> <extensionActivity> later on. The resulting problem: If I have to
> add/remove child elements of invokePipelet because of structural
> changes in the object, I always need to find the correct child of the
> connected <extensionActivity>.
> Maybe we should introduce an own object for <extensionActivity> and
> change the example project accordingly? That way the extension
> activities would work like the rest of the elements.
>
> Tobias
>
> ________________________________
>
> Von: bpel-dev-bounces@xxxxxxxxxxx im Auftrag von Bob Brodt
> Gesendet: Mo 31.1.11 22:40
> An: BPEL Designer project developer discussions.
> Betreff: Re: [bpel-dev] Beautify XML for extension activities
>
>
>
> Hi Tobias,
>
> If you have a look at section 10.9 of the WS-BPEL spec, it says that
> the child of an <extensionActivity> MUST be a single element, so that
> means it can't have any Text elements. I think my fix is correct.
>
> I'm not sure I understand your P.S. - can you explain further? Where
> is the <extensionActivity> element connected, and to what? The BPEL
> editor Diagram page correctly shows an InvokePipelet activity.
>
> _______________________________________
> Robert ("Bob") Brodt
> Senior Software Engineer, JBoss Riftsaw
> JBoss by Red Hat
>
> ----- Original Message -----
> > Hi Bob,
> >
> > your solution is dangerous, as a child element may contain text
> > nodes
> > with more than whitespaces in it and you remove any text nodes, even
> > those with real text in it.
> >
> > I didn't noticed the equals and hashCode methods up to now, you are
> > right, the current implementaion is incorrect for many use cases. I
> > removed them now.
> >
> > Greetings,
> > Tobias
> >
> > p.s. I just noticed: After loading the pipeline the
> > InvokePipelet-Object has the <extensionActivity> element connected
> > and
> > not the <invokePipelet> as expected. Thats confusing, especially in
> > DOM updates and should be documented.
> >
> > ________________________________
> >
> [snip]
>
>
> _______________________________________________
> bpel-dev mailing list
> bpel-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/bpel-dev
_______________________________________________
bpel-dev mailing list
bpel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/bpel-dev
<<winmail.dat>>