Community
Participate
Working Groups
I successfully use the o.e.w.common.frameworks.ui.wizardPageGroup extension point to add additional pages to the Session Bean wizard. In my case I add a third page that has a single text field "Service Endpoint Interface". I want to synch this text field to a property SERVICE_ENDPOINT_INTERFACE. For this, I need to extend the session bean wizard's data model. I do it by using the following code snippet: public DataModelWizardPage[] createPageGroup(IDataModel dataModel, String pageGroupID) { IDataModel wsDataModel = DataModelFactory.createDataModel(new WebServiceDataModelProvider()); wsDataModel.addNestedModel(dataModel.getID(), dataModel); return new DataModelWizardPage[] { new AddWebServiceWizardPage(wsDataModel, "Web Service Page") }; } I create a separate web service data model with the new SERVICE_ENDPOINT_INTERFACE property. I also nest the original session bean wizard's data model inside the new one. This way I have access to the session bean wizard's properties in the contributed pages. Later on in the operation I can retrieve the new "extending" data model as a nesting model of the base one that is passed to the operation. The above approach, works well, if I go through the first and second pages of the wizard. But, if I just click the Finish button on the first page, then the third contributed page is not created at all and therefore the wizard's data model is not extended with the new property. The reason for this is that the wizard creates the contributed third page at the time it has to determine if there is a "next page" on the second wizard page. In my opinion, the wizard should initialize all page groups (original and contributed) at the wizard's initialization time. This way all additional data models will be constructed from the very beginning.
I am in process of preparing a tutorial for EclipseCON 2008 based on this functionality. It would be great if this bug is fixed by M5.
I recommend you perform the nesting in the other way, i.e. you nest your new Model with the single property under the existing one used by the rest of the wizard. The general rule is client's should never need to grab the nesting model; the major idea behind DataModels is that your clients can simply ask for a property and get a value back on any model as long as it or one of it's nested models contains the property. As for loading all the pages up front, I don't believe that is how the framework is designed. Instead, the framework should recognize that there are additional extensions that still have not been loaded and not allow the user to finish until those extensions have been loaded and are satisfied. If this is not how it's working, then there is likely a bug (or my memory is bad). Please double check your extension points.
(In reply to comment #2) > I recommend you perform the nesting in the other way, i.e. you nest your new > Model with the single property under the existing one used by the rest of the > wizard. The general rule is client's should never need to grab the nesting > model; the major idea behind DataModels is that your clients can simply ask for > a property and get a value back on any model as long as it or one of it's > nested models contains the property. If I perform the nesting in the other way then the WebServiceDataModelProvider would not have access to the properties of the nesting original data model. The latter is very important, because in most cases the extending properties would want to relate to the ones of the original model. For example, I would want the default value of the SERVICE_ENDPOINT_INTERFACE property to be based on the value of the INewJavaClassDataModelProperties.CLASS_NAME property. And purely semantically, if we have model B that "extends" model A, then model B should nest model A. This way through model B one would have access to the properties of both model A and B. And through model A - only to the properties of model A. This is similar to the Object Oriented paradigm. Let me know if I get the idea wrong.
(In reply to comment #2) > As for loading all the pages up front, I don't believe that is how the > framework is designed. Instead, the framework should recognize that there are > additional extensions that still have not been loaded and not allow the user to > finish until those extensions have been loaded and are satisfied. If this is > not how it's working, then there is likely a bug (or my memory is bad). Please > double check your extension points. I simply use the org.eclipse.wst.common.frameworks.ui.wizardPageGroup to contribute new pages to the wizard. And this generally works. The problem I see is that the PageGroupManager does not invoke the createPageGroup() method of the contributed DMWizardExtensionFactory before completing the root page group. It is supposed that the extension of the data model is loaded in the createPageGroup() method (where else?). So, it happens that if the user does not advance to the last page of the root page group, the createPageGroup() method of its DMWizardExtensionFactory contribution is not invoked. It is a valid case that the user does not go to the last contributed pages, but finishes the wizard earlier (e.g. first page). The contributed page could contain fields with default values that are good for most use cases and the user would need to rarely modify them.
Kaloyan and Jason, Which one of you wants to own this bug? We need to get it out of the inbox.
Picking an owner, since no one has volunteered. I don't think this was supposed to be targeted to 3.0.1 either.
Well, it was even targeted to 3.0... This bug is beyond my understanding of Data Model Frameworks, otherwise I would have already fixed it.
Hi I cannot entirely agree on the definition of the bug. The problem is that the model for the post operation is not initialized, so the post operation fails. There are 2 solutions 1. To init the model in the post operation if it hasn't been done already, but this will bring duplication, since the same has to be done in the UI also. 2. To change (add) extension point where instead of the operation, the data provider will be defined so the Data Model Framework will be able to initialize the model itself any other opinions will be useful
Changing it to enhancement request for 3.1 (see my previous comment) in general DataModelProvider to be possible to be specified as post operation, so the DataModel could be initialized right away.
