Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Talk:BPS50"
(Simplifying the driver UI) |
|||
| Line 6: | Line 6: | ||
[[User:Gxue.actuate.com|Gxue.actuate.com]] 22:56, 31 January 2007 (EST) | [[User:Gxue.actuate.com|Gxue.actuate.com]] 22:56, 31 January 2007 (EST) | ||
| + | |||
| + | == Simplifying the driver UI == | ||
| + | |||
| + | I understand why the wizards have to be so complex, as you know nothing about the web services you would call. In my case, however, I know everything I need to know about the web service and would prefer not to require that our customers do. For example, I need to call a web service to return data from ClearQuest, and I know everything about it except the Soap endpoint. I would like to prompt the user with something like "ClearQuest Server Location", which is something they'll know and understand. I was planning on writing my own ODA driver to do this, but am wondering if it would be easier to subclass this one or replace the UI? I'm sure I'm not the only one who has to do something like this, so my point here is could you structure the driver to facilitate this kind of usage. | ||
| + | |||
| + | Also, I'm curious why you are using type=Object and reflection on the connection class and its returned object, instead of providing an interface for them to implement? An interface seems simpler and cleaner. | ||
| + | |||
| + | thanks | ||
| + | |||
| + | Mike Fox (IBM / Rational) | ||
Revision as of 15:06, 6 February 2007
Please enter your comments below. Remember to sign and date your posts by typing four tildes (~~~~).
Test
No comment
Gxue.actuate.com 22:56, 31 January 2007 (EST)
Simplifying the driver UI
I understand why the wizards have to be so complex, as you know nothing about the web services you would call. In my case, however, I know everything I need to know about the web service and would prefer not to require that our customers do. For example, I need to call a web service to return data from ClearQuest, and I know everything about it except the Soap endpoint. I would like to prompt the user with something like "ClearQuest Server Location", which is something they'll know and understand. I was planning on writing my own ODA driver to do this, but am wondering if it would be easier to subclass this one or replace the UI? I'm sure I'm not the only one who has to do something like this, so my point here is could you structure the driver to facilitate this kind of usage.
Also, I'm curious why you are using type=Object and reflection on the connection class and its returned object, instead of providing an interface for them to implement? An interface seems simpler and cleaner.
thanks
Mike Fox (IBM / Rational)