This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 90665 - Need to allow user to remove Variable usage in WS Activities
Summary: Need to allow user to remove Variable usage in WS Activities
Status: NEW
Alias: None
Product: soa
Classification: Unclassified
Component: BPEL (show other bugs)
Version: 5.x
Hardware: All All
: P3 blocker (vote)
Assignee: Sergey Lunegov
URL:
Keywords: UI
Depends on:
Blocks: 90087
  Show dependency tree
 
Reported: 2006-12-06 14:46 UTC by Michael Frisino
Modified: 2011-11-30 16:16 UTC (History)
1 user (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Frisino 2006-12-06 14:46:50 UTC
All WS activities that use variables need to allow user to delete the variable
usage.

This means modifying the property editor for
invoke
receive
reply
onmessage
onevent

User needs to be able to delete the usage because we are introducing support for
virtual assign construct in thees same activities. And according to BPEL spec,
BPEL is not valid if BOTH virtual assign and explicit variable are set. 
Therefore, if a user wishes to change a setting from variable to virtual assign,
they will need to delete the variable usage.

There are several possible fixes for this situation:

1) Do not let user explicity remove Variable usage. 
IDE can just automatically remove it if the user sets a virtual assign, or vice
versa. If user sets variable, IDE can clear the virtual assign.  This is eager
solution. 
Upside, saves user from having to do extra step, avoids invalid state. 
Downside - only works if user performs ALL authoring in Design view. If user
works partially in source editor, then we cannot manage this mutual exclusivity.
 Another downside, user may set one of the mutually exclusive properties by
accident. Then they will be frustrated that we have removed the other property
value.

2) Add explicit Remove action to the property editor. Problem here is space.

3) Make the Variable field editable. User can then select and delete the
variable text. Downside - user will also be able to modify the variable name
expclitly and therefore could introduce invalid variable names. 

I prefer solution 2 or 3.

Recommendation: Simplest solution is to make the text field editable. I think
this is reasonable and users are not going to get themselves into too much trouble.

Jirka, what do you think?
Comment 1 Michael Frisino 2006-12-06 14:49:37 UTC
BTW - we had similar discussion already about removing Message Exchange ID. At
the time we decided to make the text field editable for that case. I have no
objection to the "remove" button. It is just then we will have "create",
"browse" "remove" for each variable usage case.
Comment 2 Jiri Kopsa 2006-12-07 21:11:32 UTC
I have added these comments also to the end of the specification at:
http://xdesign-tools.czech.sun.com:8080/JSPWiki/Wiki.jsp?page=IZ90675

Here is a solution #4:

The specification states that the use case is "user wants to edit a virtual
assignment for a BPEL web service activity, as allowed by the BPEL 2.0
specification". I believe that's really not it. I believe that the use case is
"User wants to use a web service activity to send data stored in one or more
variables or receive data and store them in one or more variables". If we put it
in this generic way, then perhaps, the UI could be simplified and there won't be
issue [#90655|http://www.netbeans.org/issues/show_bug.cgi?id=90665].

From the system perspective it seems that there are two use cases ('variable
use' and 'virtual assignment'). However, from user perspective, there really is
just one - to send or receive data from one or more variables.

So perhaps the same UI could be used to fulfill both the use cases and the
remaining work ('variable use' vs 'virtual assignment') could be left on the
system. What I'm suggesting is to present both message type variables and
complex type/element variables in the mapper trees and allow the user to map a
message type variable to a from/to message node OR one or more complex
type/element variables to one or more message part node. Of course this solution
requires stronger validation story (on-canvas validation being a must over
here), however provides very intuitive and simple UI; the complexity is hidden
from the user, use just maps the variables to messages in an appropriate way
(guided by validation mechanisms).

Let me know what you think ...

BTW - I cannot find message exchange patterns now (to consider solution #3) -
did we get rid of that?