I have created a confirmation page a link and a button on the Update page. When i disable the postvalidation the confirmation page will appear after i hit submit on the update page and when i click the back link on the confirmation page it will go back to the list page. The problem is it is not posting any changes made.
I need it to run the postSaveActions, post the changes if valid, display the confirmation page and then return to the list page when the link is clicked on the confirmation page. Can anyone help with this. If i do not disable the postSaveactions it will skip over both and return directly to the list page with out saving the changes.
Thanks in advance.
This topic has been locked.
5 replies Latest Post - 2013-01-22T15:36:42Z by Codeoline
Pinned topic Confirmation Page
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
- 305 KB
Updated on 2013-01-22T15:36:42Z at 2013-01-22T15:36:42Z by Codeoline
Re: Confirmation Page2013-01-15T21:11:12Z in response to CodeolineI used DSUI to create this app and i do not need to display the users input. I just need to give them a warm fuzzy that the data they entered was saved to the DB. Does anyone know of an example of this using a DSUI?
Thanks in advance
mburati 060000VQ202361 PostsACCEPTED ANSWER
Re: Confirmation Page2013-01-15T21:25:04Z in response to CodeolineI haven't had time to really look through what you're doing there, but it looks like you replaced the control that the DSUI update submit was going to do, with your own button (currently disabled) that just went to the confirmation page? If so, that's going to skip what DSUI typically does for you.
There's a section called "Settings for the Create and Update Pages" in DSUI. When you enable "Update" operation, there should be an input in that settings section that says what action DSUI should call after it completes the update operation. Unfortunately, it doesn't look like it lets you specify your own action there, but it does appear to let you go to the Details page for the just updated record (instead of just back to the list page, which is the default), so that could act as a confirmation to the user that their changes were saved. Please try that and see if that's enough of a confirmation for your needs.
I hope that info helps,
The postings on this site are my own and do not necessarily represent the positions, strategies, or opinions of IBM.
Re: Confirmation Page2013-01-16T01:43:23Z in response to mburatiI did create another button because i was trying to follow the example in the book. Thanks for the idea of using the details page but i dont think that is what they are looking for unless i could change it some way to say your changes have been updated. Is it possible to use an action list to fire the confirmation page?
mburati 060000VQ202361 PostsACCEPTED ANSWER
Re: Confirmation Page2013-01-18T15:28:01Z in response to CodeolineI'm not sure which book you're referring to, but if you are trying to replace a button that DSUI generates then it would be best to look at what DSUI is generating for you by default and ensure that you are calling the same/similar stuff in the same way, in addition to the extra steps that you intend to add.
Look at the WebApp in the Design View of the designer, to see what methods are generated by the DSUI builder (it generates methods to call operations and then go to or back to a given page etc, along with wiring buttons to that generated flow).
For instance, with the out of the box OrdersServiceConsumer sample, looking at the uiUpdate page in the Application Tree view and expanding the "All Named Elements" section, I can select the "submit_button" element and see the generated page artifacts in the Design View on the right. Switching that Design view to "Source" view, I see it has highlighted a couple of generated HTML elements within the vf_buttons div, for the update submit button.
Looking at uiUpdate_NextAction in the Application Tree view (it's hidden by default so you need to enable show hidden objects under Window -> Preferences -> Show Hidden Objects from the Eclipse title bar) you can see that DSUI generated update method checks for page automation errors and if there are any it goes back to the uiUpdate page to display them, otherwise it calls the generated uiFinishUpdate method (also hidden by default). The generated uiFinishUpdate method calls the actual service, marks the current consumer copy of the list dirty (since it's been updated in the backend) and then calls the generated uiToDetailPageWithArg method, passing it the order id of the just updated row (if you had selected go back to list instead of details in the DSUI buidler, this generated method would go there instead of to the details page.
So, if you're going to try to do something in addition to what DSUI is doing for you there, you need to do it in addition to all that work it does for you, not instead of all that work (eg, if you just put a button on the update page and have it go somewhere else, you're bypassing all that work it does for you that I explain above.
There may be a better way to insert an alternative action for the post update action, but given that I don't see a way in the DSUI builder to specify an explicit action there, here's "one" alternative to modify what DSUi generates for you there. Note, this has at least one caveat in that if a future version of DSUI changes what it generates there, your customization may need to be redone to pick that up, but for a given version, this may work for what you're trying to do:
- For any generated method, you can find it in the web Application Tree, right-click on it, select Methods -> Override and it'll bring up a dialog based Method Builder ui with the current contents of that Method, letting you generate a NEW method to override the generated one, where you can tweak the generated code and/or add to it (eg, change the page it goes to at the end of uiFinishUpdate). This is not a general use case as it has the limitation that you now have a hardcoded version of that Java method in your model, so if the builder generates new/alternate code for you in the future due to a fixpack or new release containing new/fixed functionailty, OR you change the builder inputs to no longer generate the original overridden method to something other than what you copied and customized, your custom method will be out of date (and you may not know it). But, if you have no other way to modify a particular generated method and the current builder calls in your model do everything you want except one tweak needed to a generated method, this is one way WEF lets you override/extend what it generates (with the above risk/caveat of future version changes).
Another option, if DSUI's flow does not easily support an alternative flow/use case you need without resorting to overriding its generated methods, then you do not have to use it if it's creating more work for certain use cases. DSUI is a superset of View and Form's capabilities and both are built on the same page automation and method generation capabilities, so you can use View and Form and add DSUI-like capabilities to what View and Form generates for you, when DSUI itself ends up leading you down a path that doesn't match your use case.
I hope that info helps,
http://www-10.lotus.com/ldd/pfwiki.nsf/The postings on this site are my own and do not necessarily represent the positions, strategies, or opinions of IBM.
Re: Confirmation Page2013-01-22T15:36:42Z in response to mburatiThis information is very enlightening.
I think I will forgo the confirmation page for now and create my next portlet using View and Form.
The book I have is Rapid Portlet Development by Bowley.