Bugzilla – Full Text Bug Listing
| Summary: | Client Project defaults back to first facet friendly workspace project when switching client types. | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [WebTools] WTP Webservices | Reporter: | Shane Clarke <shane_clarke> | ||||
| Component: | jst.ws | Assignee: | Eric Peters <ericdp> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | Kathy Chan <kathy> | ||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | oisin.hurley | ||||
| Version: | 3.0 | ||||||
| Target Milestone: | 3.1 | ||||||
| Hardware: | Macintosh | ||||||
| OS: | Mac OS X - Carbon (unsup.) | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Shane Clarke
Created attachment 111507 [details]
ClientWizardWidget Update
Eric, Please take a look at this problem reported. Thanks! Hi Shane, Again sorry for the delay in reviewing this patch. The current behavior is working by design, let me explain. The fields on the first page of the web service client wizard (WS runtime, client project, Server) are strongly tied to the Client type field- only some combinations will work with the chosen client type. Therefore after you change the client type the fields below (WS runtime, Server) may change to ensure the resultant web service can function (i.e. there are no validation errors on the page). The proposed change might get the user into an error situation by leaving the project and other fields the same after changing the client type (e.g. the current client project is not a valid client project type for the new client type). The default values of fields all need to be re-calculated when the client type changes to ensure the best combination that will not result in errors on the page. If the user is not happy with the defaults we have chosen they can then explicitly change them and put themselves into a possible error condition, but they should be clear on how the error occurred (e.g. they chose an unsupported client project or ws runtime). Also, we've tried as much as possible to ensure that throughout the ws & ws client wizard the dependency of fields is from left to right & top to bottom (i.e. fields at the bottom are dependant on fields up top). Changing the fields below the client type such as project and ws runtime when the client type itself has changed is consistent with this design and user should not be confused when making a change in the top of the page results in changes below. Hope this design and rationale make sense to you, please let us know if there is a compelling reason to change existing behavior we are not aware of and we can discuss further. Thanks, Thanks for the detail explaination, Eric! Shane, like what Eric said, if this explaination and our current approach does not make sense to your scenario, please let us know so that we could understand your use case better. Another point to note is the user can use the Web services scenario preference to change the Client type so that they minimize having to change the client type after changing the project. I guess the thing that I find uncomfortable about the current behaviour is that it does not respect an existing context that I have selected. If am selecting a wsdl file in project B, I have an assumption that because I am 'in the context' of project B, that the artifacts I am about to generate will also end up in project B. With this assumption firmly in place, I am then surprised when the generated artifacts not only end up in the 'wrong' place, but they also overwrite some existing, similarly named, artifacts that may already be in that other project! I understand that wsdls may be consumed from the web, file system, etc, and that in some cases there needs to be a project assigned after the wsdl has been chosen. In this case it would strike me as consistent with other approaches in Eclipse to ask the user where to produce the artifacts. Even if the behaviour stays as it is, I think it's really necessary that the user's attention be brought to the fact that they wizard may not be doing what they expect. To this end, representing the target project as a link in the wizard will not garner this kind of notice--perhaps if the link were to change color, or it be decorated in some way, then the user could mouse over it and get some information on why the project choice has changed without them influencing it. Summary--my opinion is that the current behaviour represents a compromise that will be confusing to the customer. In the (well-adjusted) attempt to avoid an error state, the user can be lead into another error state, which is all the more sinister as it may not produce error markers and yet may destroy code that has already been constructed by the user. Suggestions for change, in no particular order--1) respect the project selection when generating a client; 2) if there is no project selection, query for a project; 3) add an undo method so that the user can recover from code generated in the wrong place This bug has been in resolved state for a while (with resolution set to Invalid, Duplicate, wontfix or workforme). Please verify that you're OK with this resolution and close the defect. Please re-open if you don't agree with this assessment. If this is not verified within 2 weeks, we'll be verifying the bug on your behalf. Thanks! closing this as we haven't introduced an additional client type. |