| Re: [bpel-dev] Beautify XML for extension activities |
Hi Bob,
as we now continue working on the SMILA extensions for the BPEL designer (as the next step of our simplification process), I would like to return to my last proposal of introducing an own EMF object for the ExtensionActivity XML element:
Current implementation of mapping between XML nodes and EMF objects:
<sequence name="..."> - SequenceImpl
<extensionActivity> - MyActivityImpl (extends ExtensionActivityImpl)
<myActivity> - Must be handled by MyActivityImpl, but is not directly connected
...
</myActivity>
</extensionActivity>
</sequence>
My proposal is to introduce a new (abstract) base class "ExensionActivityBaseImpl" for the direct connection of the XML elements:
<sequence name="..."> - SequenceImpl
<extensionActivity> - ExtensionActivityImpl
<myActivity> - MyActivityImpl (extends ExensionActivityBaseImpl)
...
</myActivity>
</extensionActivity>
</sequence>
This would ease the synchronization between the XML elements and the EMF objects.
Additionally we would avoid the following problem: Suppose someone is using the source tab to delete everything inside <extensionsActivity> and add some different activity in there. As the connected XML element remains, so is the MyActivityImpl child in the SequenceImpl.
Should I create a patch and CR for my proposal?
Tobias
Btw. Even your code in ExtensionSampleActivityDeserializer shows the problems with the current implementation: The lines with "sa.setElement(saElement);" have no effect, as the parent element is set in the calling method.
________________________________
Von: bpel-dev-bounces@xxxxxxxxxxx im Auftrag von Bob Brodt
Gesendet: Do 3.2.11 16:49
An: BPEL Designer project developer discussions.
Betreff: Re: [bpel-dev] Beautify XML for extension activities
Yes, as far as I know nobody else has implemented any kind of BPEL extensions either runtime, nor in this editor. I believe that the ODE API does not even support extensions until 1.3.5 which is due to be released soon (I hope).
The final changes I will make to address the pruning of the extension activity tree will be in ElementPlacer#niceInsertBefore() so that it does not remove any descendants, but still does the correct indentation of child elements. I'll let you know when this is completed. At that time I will copy that nightly build to the update-site.
Let me know when/if you need any more help with this.
_______________________________________
Robert ("Bob") Brodt
Senior Software Engineer, JBoss Riftsaw
JBoss by Red Hat
----- Original Message -----
> Hi Bob,
>
> as we are apparently the only team that is using the extension
> activities with the BPEL Designer, I thought we could make the
> appropriate adjustments, test it with our extensions and offer you the
> patch.
> But right now our focus has changed a little bit (unfortunately), so I
> commited our current state to SMILA and will deal with that problem
> (and the resulting problems on our side) later.
>
> Thanks for your help so far,
> Tobias
>
> ________________________________
>
> Von: bpel-dev-bounces@xxxxxxxxxxx im Auftrag von Bob Brodt
> Gesendet: Mi 2.2.11 01:35
> An: BPEL Designer project developer discussions.
> Betreff: Re: [bpel-dev] Beautify XML for extension activities
>
>
>
> Hi Tobias,
>
> I guess "niceInsertBefore" is not so "nice" ;) I did not pay attention
> to that piece of code and just assumed it didn't do anything harmful
> to change the descendant subtree - my bad...
>
> The code is what it is...I inherited this about a year ago and I'm
> still learning new things every day. That's why I'm a little cautious
> about making the kinds of broad changes that you suggest, even though
> it would probably make it a bit cleaner.
>
> _______________________________________
> Robert ("Bob") Brodt
> Senior Software Engineer, JBoss Riftsaw
> JBoss by Red Hat
>
> ----- Original Message -----
> > 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
> >
> >
> >
> > _______________________________________________
> > 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
>
>
>
> _______________________________________________
> 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>>