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.
Summary: | Need to allow user to remove Variable usage in WS Activities | ||
---|---|---|---|
Product: | soa | Reporter: | Michael Frisino <frisino> |
Component: | BPEL | Assignee: | Sergey Lunegov <slunegov> |
Status: | NEW --- | ||
Severity: | blocker | CC: | jkopsa |
Priority: | P3 | Keywords: | UI |
Version: | 5.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 90087 |
Description
Michael Frisino
2006-12-06 14:46:50 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. 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? |