[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[bpel-dev] [Fwd: BPEL Annotations/Extensions]
|
Interesting request in the newsgroup ...
I don't think we can do what he is asking right now just "magically".
What Jan is asking is valid in the sense that every activity extends
from this complex type:
<xsd:complexType name="tExtensibleElements">
<xsd:annotation>
<xsd:documentation>
This type is extended by other component types to allow elements and
attributes from other namespaces to be added at the modeled places.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element ref="documentation" minOccurs="0" maxOccurs="unbounded"/>
<xsd:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax"/>
</xsd:complexType>
While the construct he proposes is not technically valid
<wait name="Wait_1">
<annotation>
<it5:expectation name="waitrate">
<ms>4</ms>
</it5:expectation>
</annotation>
</wait>
it should rather be
<wait name="Wait_1">
<it5:expectation name="waitrate">
<it5:ms>4</it5:ms>
</it5:expectation>
</wait>
Having said that, our ExtensibleElement does not provide any "entity"
information other then the BPEL specific items. There is nothing in the
marshal or unmarshal code that comes even close to hooking this up.
Anyone wants to comment on this .... ?
--- Begin Message ---
Hi!
We would like to extend the given BPEL Elements with annotations (as new
childs for the elements) e.g.:
<wait name="Wait_1">
<annotation>
<it5:expectation name="waitrate">
<ms>4</ms>
</it5:expectation>
</annotation>
</wait>
Where "it5" is our own namespace.
These annotations should be editable in the Properties view of each
element (the annotations may vary from activity to activity, e.g. a
switch has other annotations then a wait).
Can someone here explain how we can achieve this? What's the best way to
get this functionality, without changing your plugin? For compatibility
purposes, we would prefer a solution where we mustn't change your
plugin, but unfortunatly we weren't able to identify how to use the
extension mechanism of your plugin.
How do we model our extensions? With our own ecore model, where we use
your model as base (MyTWait extends TWait). Or do we only model our
extensions as ecore objects? In case one: How is ensured, that if the
user chooses an activity from the palette, that our extended class is
used? In case two: How are the two models integrated, so that our
extensions are properly (de-/)serialized?
I hope you can help us :-)
Bye
Jan-Patrick Osterloh
--- End Message ---
