Michael Illiger2 wrote:
Hi,
We just commited some code for BPEL
2.0 part-mapping stuff for our PartnerActivities.
I had to change our model classes
for
FromPart, ToPart, FromParts, ToParts and all PartnerActivities. I also
tried to implement the EMF-DOM reconciliation stuff. for these classes.
> Oleg: could you please review
the
changes I did in our model plugin and tell me if I missed anything?
In the property pages I tried to
reuse
the "combo-box widgets" Michal introduce for Partner, Operation
and Variable in InvokeImplSection. This works quite well with some
minor
issues. E.g. there are not always all variables with matching types
listed
in the proposal box. And the "fault-name" combo box doesn't provide
any proposals.
So fault names apply to reply activities only ... I looked at the code
and I think the WSDL Operation must define faults in order for them to
be present in the reply activity customizer.
Regarding the variables being shown and proposed ... there is a
provider of variables from the context element (which just grabs what
variables are visible) and a filter which dims that set to what is
appropriate (on MessageType, XSDType, or XSDElement) ...
org.eclipse.bpel.ui.details.providers.VariableFilter
The filter just checks "hard" type equivalence and checks the "Message
Type Variable" with 1 type matching part strategy defined in the BPEL
2.0 spec.
In particular it just exactly this:
/**
* @see org.eclipse.jface.viewers.IFilter#select(java.lang.Object)
*/
public boolean select (Object toTest) {
if (toTest == null) {
return false;
}
if ( Variable.class.isInstance(toTest) ) {
Variable v = (Variable) toTest;
if (fMessage == null && fElementDeclaration == null
&& fTypeDefinition == null) {
return true;
}
if (fMessage != null) {
if (fMessage.equals ( v.getMessageType() )) {
return true;
}
if (fMessage.getEParts().size() == 1) {
Part part = (Part) fMessage.getEParts().get(0);
XSDElementDeclaration decl =
part.getElementDeclaration();
if (decl != null && decl.equals(
v.getXSDElement() )) {
return true;
}
}
}
if (fElementDeclaration != null) {
if (fElementDeclaration.equals( v.getXSDElement() )) {
return true;
}
}
if (fTypeDefinition != null) {
if (fTypeDefinition.equals( v.getType() )) {
return true;
}
}
return false;
}
return true;
}
Now I actually think this is a pretty good so far ....
The only question is whether sub-types can be considered "compatible"
....
> Michal: if you find
some time could
you please take a look at #updatePartMappingWidgets in
InvokeVariablesSection
and review if I used your widgets as they are intended to use? And
could
you also please take a look at the faultname stuff for Reply. If I look
at the CVS history I wonder if this has ever worked...
Oh, and not to forget: We also
commited
Oleg's latest source-tab patch (sourcetab-20071116.patch)
Cheers Michael
Software Developer
- BPEL Editor / WID
|
WSS
Business Process Solutions
Development 1
|
Dept.
4722, Bldg. 71032-01,
Room 086
|
IBM
Böblingen Laboratory
|
Schönaicherstr.
220, D-71032
Böblingen |
|
Notes:
|
Michael
Illiger2/Germany/IBM
|
Internet:
|
milliger@xxxxxxxxxx
|
Phone:
|
++49-(0)7031-16-1273
|
Fax:
|
++49-(0)7031-16-4890 |
|
IBM
Deutschland Entwicklung
GmbH
|
Chairman
of the Supervisory
Board: Martin Jetter
|
Board
of Management: Herbert
Kircher (Chairman)
|
Corporate
Seat: Böblingen
|
Commercial
Register: Amtsgericht
Stuttgart, HRB 243294 |
|
_______________________________________________
bpel-dev mailing list
bpel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/bpel-dev
--
Michal Chmielewski, CMTS, Oracle Corp,
W:650-506-5952 / M:408-209-9321
"Manuals ?! What manuals ? Son, it's Unix, you just gotta know."
|