[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [bpel-dev] Beautify XML for extension activities
|
Hi Tobias,
I ran across the same kinds of issues you are talking about when I was working my way through the updated extension activity sample plugin, but I ran out of time to investigate this further. If you have a patch that will fix some of these issues, please go ahead and add it to bugzilla and let me know so I can review/apply it. I'll probably have to revisit the extension activity sample again and fix it :(
BTW, please be sure to update the ecore and regenerate the model for the affected classes. You'll probably have to start there anyway to add the ExtensionActivityBase object...but be careful - I think the ecore and implementation files are already out of sync (i.e. SOMEbody bypassed the ecore model and made changes directly to some of the java impl files.) I have no idea how or when this happened, but I didn't do it ;) Resynchronizing these is also on my [already too long] list of things to do.
Thanks for your help!
_______________________________________
Robert ("Bob") Brodt
Senior Software Engineer, JBoss Riftsaw
JBoss by Red Hat
----- Original Message -----
> 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
>
>
>
> _______________________________________________
> bpel-dev mailing list
> bpel-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/bpel-dev
