Bugzilla – Full Text Bug Listing
| Summary: | Workspace URI in a DD-based service binding requires the user to set up deployment | ||||||
|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Ben Margolis <margolis> | ||||
| Component: | EDT | Assignee: | Project Inbox <edt.ide.ui-inbox> | ||||
| Status: | NEW --- | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | jspadea, jvincens, svihovec | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Created attachment 209886 [details] client-and-server project If you create a Service type, establish a service binding in an .egldd file, and call the service from a Rich UI handler -- without also setting up a service deployment entry in the DD -- the service access fails with a confusing error message. **** Options **** 1. Let the access occur, but add a warning message to remind the user that a deployment might be necessary in the future; or 2. Ask for permission to add the required deployment entry and let the access occur, perhaps independent of whether permission is granted; or 3. Keep the current behavior, but make the error message clear. *** Why do more than fix the message? *** EGL will get traction only if it has general constructs and processes that are applied consistently. o The development process is twofold: iteratively code and debug (with hidden generations) and then, as a last step, deploy. The developer should not need to worry about deployment while thinking about application logic. The general mechanism for resource binding should be one of the selling points of EGL. Make it easy and as consistent as possible, and completely separate the idea of binding from the idea of deployment. The 2009-era doc was desperately confusing because it merged the two ideas. o As much as possible, the developer is free to do "b" before "a". We do not force the order of events. For example, the developer can define a service binding before or after coding a call statement. The developer might intend to deploy the service being written, but initially wants to use the binding mechanism and to test the flow of logic. We do not force a process. o EGL should allow for prototyping. The developer might not intend to deploy code at all and is only simulating access of an external service. **** Current message **** In the example code, the workspace URI correctly stated the location of the Service type: workspace://ThirdProject/mypkg.server/MyThirdService Here's the error message, which refers to a different location: No REST-RPC service was found. URL:/ThirdProject/restservices/mypkg.server/MyThirdService