Community
Participate
Working Groups
If you go to Resource Bindings Configuration, click Add, and click SQL Database Bindings, you get a page that offers two options and that needs to be changed in any case for clarity. If you create an SQL Database Binding and review your choice at the Resource Bindings Configuration screen, you get a much spiffier presentation. Please reproduce the spiffier presentation in the first context. There is no benefit to giving the user a choice only after the original choosing; and the story is not that difficult to understand from the beginning. Making this change in time for the Wednesday meeting would make a better impression.
Saul - I don't understand what you are requesting here. Can you clarify? My $0.02 is that the text for the 2 radio button options in the Add Resource Binding > SQL database binding are way too long - users should immediately understand what the 2 options are. Shorter, simpler options could be: ( 0 ) Link to workspace connection ( 0 ) Copy settings from workspace connection Also, the "(retrieved at runtime)" text on the first option is not really correct: the connection settings are always retrieved at runtime, either from hard-coded settings in the DD or via the workspace connection.
Will, There was some tendency in Rational Business Developer to have additional options shown on the page where you edit the binding, but not on the wizard page where you create the binding. Having different content seems a mistake for two reasons: o We should allow the developer to set up every detail on the one screen, rather than requiring an order of events: first set up the binding, then edit it. As a design principle, we should not force an order of events if we can avoid forcing an order of events. o More important, it is easier for someone to understand the details of a binding if it is all on the wizard page as well as on the edit page. The help topic or wiki page ties it together, why separate out a few pieces? Jon Sayles once said that someone could understand EGL in a week and become expert in a month. With EDT, we can cut those times in half, and we can have "prove-its": sessions at company sites where employees write enterprise applications faster than was thought possible. Anyhow, some of the new JNDI details are not on the wizard page. Rather than changing the phrasing that is on that page, let the content on the edit page be copied to the wizard page. It'll look good. That's the proposal.
Brian says this: *** I think there are a few 'green threads' that we need to consider: 1) A user is developing an application and the database to go with it at the same time. This user will most likely want us to default JNDI to ON and probably is not concerned with the name that we pick for the connection. 2) A user is developing an application for an existing database that has been configured to use JNDI on a server. This user will most likely want us to default JNDI to ON as well, but they are going to have to change the connection name after closing the wizard because it is most likely going to be wrong. 3) A user is developing an application for an existing database, and they do not want to use JNDI. This user will want us to default JNDI to OFF, so they will have to change the connection information after closing the wizard. Given these scenarios, I am wondering if we are overloading the current JNDI content in the EGLDD editor to mean two different things (i.e. 'Deployment' and 'Bind'). I am thinking it would be better if we reserve the current JNDI UI for scenario 2, which involves a user creating a binding for an existing database connection, and then indicating that that connection should use JNDI with a specified name, because that is how it is configured on the server. A side affect of this configuration is that the IDE Test Server, which also supports JNDI, needs a database connection profile to be able to create its own JNDI connection with the same name that is used in the production environment. I believe this means the EGLDD editor would look like: * Connection Profile * Connection Information * JNDI * Debug Connection Profile I believe this also means that the Binding wizard should allow the user to specify both the JNDI name and optionally a connection profile, basically replicating the content of the Resource Binding tab. The JNDI information needs to specified in the wizard in this example because it is just as important as the database connection information for someone that is using JDBC without using JNDI. At the same time, I think we also need to support scenario 1 above, but this scenario would now require the user to configure the resource binding as in scenario 2, and also define the JNDI name that we would create for them on the server. While having to specify this information twice seems redundant, I believe there is precedence in our Service support, which provides a Service Deployment tab and a Service Binding tab, where a user may need to configure a binding and deployment information for the same EGL service. (Let me know if this is not the case). One option would be to rename Service Deployment to Resource Deployment, and add the ability for someone to define when a JNDI connection should be configured on the server with a given Database connection. Another option might be to add another checkbox to the JNDI section of the Resource Binding that says, "Create this connection during deployment if necessary". In the short term, at least for .8 I2, I think we should leave things as they are. At the same time, I think we need to add the JNDI information to the binding page, since defaulting JNDI to ON, and to the wrong name in scenarios where a connection already exists, seems less than ideal. I would suggest that we open a work item to make these changes, and possibly some additional changes in the DD Editor for .8 I3 if there is time. ***
Deferring to Future.
