Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 122661

Summary:	Odd UI in Client Environment Configuration page
Product:	[WebTools] WTP Webservices	Reporter:	Tim deBoer <deboer>
Component:	jst.ws	Assignee:	Rupam Kuehner <rsinha>
Status:	CLOSED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	cbrealey, kathy
Version:	1.0	Keywords:	Documentation
Target Milestone:	1.5 M5
Hardware:	PC
OS:	Windows XP
Whiteboard:

Description Tim deBoer

2006-01-04 14:38:33 EST

When I bring up the third page of the New Web Service Client wizard (Client Environment Configuration) for bug 117924, the first combo box (Client Project type) is disabled and the project name is in the second combo box (Client project). When you change the name in the second combo, the first one suddenly enables and multiple entries are added to it.

Having a field farther up in a dialog change due to a change lower down is non-standard UI. I'm not sure what else this UI is used for, but either these two fields should be switched or another solution should be found.

Comment 1 Chris Brealey

2006-01-04 16:42:34 EST

I agree the current behaviour is odd. The catch is each control is capable of influencing the other, so reordering the controls isn't necessarily the answer. We'll rethink the UI here.

Comment 2 Rupam Kuehner

2006-02-20 12:45:37 EST

Chris,

The reason the project type field is on top is that, historically, the project type field influenced the project field. The project type field was always enabled and we filtered the list of projects in the project combo by the value in the project type field. This was when we were limited to displaying four project types (Web, EJB, AppClient, and Java) and figuring out the type of an existing project was a fairly trivial task.

With the introduction of facets, the project field combo list contains all valid existing projects (regardless of project type). The project field is not influenced by the project type field. The project type field is only enabled when a non-existing project name is entered into the project field. I went with this appraoch early in 1.0 M9 because trying to figure out which template best matches an existing project reqires some non-trivial "facet math". I think the simplest approach to fixing this bug is to reverse the order of the two fields. 

Let me know your thoughts.
Rupam

Comment 3 Chris Brealey

2006-02-20 13:07:20 EST

Rupam,
thanks for the explanation. Reordering the controls sounds fine to me. If we ever do implement the math to classify projects by template then we can consider a different control altogether, such as a tree dropdown with projects grouped into template branches.

Comment 4 Rupam Kuehner

2006-02-21 19:29:03 EST

Patch has been attached to bug 119111.

Comment 5 Kathy Chan

2006-02-22 13:17:28 EST

Patch committed to HEAD.  It will be released to this week's integration driver.  Retargetting to M5.

Comment 6 Kathy Chan

2006-02-22 14:48:57 EST

Released to HEAD as v200602221946.

Comment 7 Tim deBoer

2006-06-13 11:52:41 EDT

Closing.