Are there any Documentum Webtop developers on here that know how to launch the DocList component within a simple container such as dialogcontainer ? I'm trying to implement some custom functionality for one of the screens in my Webtop-based application so that when the user clicks on the link for a folder, the DocList component is invoked to display the contents, then after the user is done looking at them, she can click the OK button provided by the container to return to the previous screen...
I've tried a couple different ways to do this. My first attempt was to use a dmf:link tag to call a new component I defined called doclistcontainer to contain the doclist component. My second attempt was to use a dmf:actionlink tag that called an action I defined which executes doclist within a container. In both cases, I end up with a blank screen, generic title, the OK button doesn't do anything... When I run a debugger on the code, I can see that the DocList behavioural class is being called despite the blank screen being displayed. What am I doing wrong?
Sheldon
Related
I have a simple Aurelia application that displays accounts. The default view is a list of accounts. There's also an account details view.
I'd to make the details view open in a modal/dialog over the top of the list view. However, I want the presence of the modal to show up as part of the URL.
I found it easy to use the aurelia-dialog plugin to display the details view, but can't figure out how to get the dialog's presence to show up in the URL.
Another option might be to throw out aurelia-dialog and use a child router to display the details view, then figure out how to make that show and hide as a modal.
And, of course, another possibility is that there's a better way that I just don't see yet.
Has anybody seen or created something like this?
One possibility that occurs to me would be to add the dialog's presence as a parameter to the current route and then call it. You could use the route like /account?dialog=true. Run some tests to ensure that the ?dialog=true still routes to the same page. Then, use that route to check whether that parameter is set and display or hide the dialog window. When you refresh the page, the dialog window should still be open/closed. This also means that whenever you open or close the dialog window, you need to send a new route to the router (basically same route but different parameter).
This isn't a detailed solution but might get you on the right path.
I want to change default values which gets populated in the below picture.
I tried modifying get_v_role method but it didn't serve my purpose.
Please help.
In personalize->personalize settings, there is sort option. It sometimes overwrites this arrangement of values of get_v method.
Also code can be written in inbound plug of this view. I did it for overview page drop down and it worked. You can try for your search page.
For filtering/changing drop-down value of search parameter, You've to Re-define GET_DQUERY_DEFINITIONS method of ZCL_XXX_IMPL class of component. GET_V_XX methods are only used to modify drop-down/F4 help of view pages not the search view.
STEPS:
Click F2 while placing the cursor on Account ID(for which parameter you want
to modify) drop-down.
Go to BSP Component using t-code - BSP_WD_CMPWB
Enter the component name and Enhancement set
Select the view.
Go to Implementation class .
If your component is enhanced then it will be having ZCL_XXX_IMPL class. otherwise you've to enhance that component. Click on that class.
After that find GET_DQUERY_DEFINITIONS method and implement same way as
GET_V_XXX.
Is there a way by which I can duplicate or clone dijit widgets?
Basically, idea is to improve page rendering performance by minimizing widget creation time.
We have a single page web application and we do not reload the entire page whenever the user performs any action.
The flow of events is as follows,
The main page is loaded by the browser. It contains a dijit ContentPane which acts as a master container and displays the entire page using various other dijit widgets like textboxes, tabs, datefield, Enhanced grid etc.
The user performs an action (e.g. click on a dijit button)
The application sends an ajax call to server which processes the button click event and generates UI of the next page.
Browser receives successful response from ajax call and calls refresh method of dijit ContentPane. Which triggers destruction of existing widgets and new set of widgets are created and placed at appropriate position. (instead of refreshing the entire page)
The user again performs some action and again the refresh method is called which triggers destruction of existing widgets and new set of widgets are created and placed at appropriate position.
Because of such architecture the browser has to destroy existing widgets and recreate them again and again. Which results in slow performance.
The idea is to have a set of widgets always readily available on the browser clone them and place at appropriate position and update them instead of recreating each time.
Yes this is possible with something called _AttachMixin.
Basically there is no getting around the fact that your widgets would need to attach event listeners to the HTML Document. What can be cut out though is the time in the Dijit Widget's lifecycle to generate the DOM. As we well know, simple Dijit widgets like a dijit/form/Button has a div inside a div inside a div etc.
This is explained in detail here http://dojotoolkit.org/reference-guide/1.9/dijit/_AttachMixin.html
Here is an example using Node.JS as a backend. http://jamesthom.as/blog/2013/01/15/server-side-dijit
This is a tough problem and this concept isn't explained very thoroughly. If you have a backend that is not Node.JS you have to manually make the widget string and pass it as a response to your AJAX and an follow the example from the 1st link (Ref Doc)
We have had lots of widgets of our app render nicely within the client side. A far less complicated approach would be to simply show / hide (instead of render and destroy) widgets as and when they are needed. I assume that you app's access policy would focus on data and not which person has access to which widget.
In my Durandal app, I have a search page - I'd like to:
Load a clean search page when it's loaded from the menu (router.navigate('#/search'))
When navigating to an item from the search page, then using the back button, this should return to the original search result & criteria.
I'm also storing my search criteria & results as a (app-wide) singleton, which is injected to the view model via RequireJS.
Am I able to: distinguish how the user entered the page? I can see that the activate() lifecycle call is triggered under both entry methods.
If you want to know if the user landed to the search page by clicking a link/button from your app or by visiting by entering a url/back button, what I would do is to raise an event when the user clicks on the link/button and on the search page check if the event has been raised or pass some parameter in router.navigate.
I have been recently doing some work on distinguishing a user click from within the application and a back or forward button from the browser. If you are using router.navigate() to navigate around the Durandal application the router.explicitNavigation flag is set to true. But you would want to capture this before the 'router:navigation:complete' event in 'router:route:activating' event as the flag gets set back to false on 'router:navigation:complete' event.
Bottom line is if you are using router.navigate to navigate around the application the router.explicitNavigation property will be set to true and if navigation is triggered using the back/forward button in the browser router.explicitNavigation will be set to false.
In actual case you might not even need to perform router.navigate() to distinguish between an in app navigation and a browser back/forward because Durandal's router module listens to all 'a' tag click on the document level and sets the explicitNavigation flag to true. However I haven't tested this fully.
The MSDN Documentation explains when to call WinJS.UI.processAll() yourself in your apps and when it's done for you automatically:
If you aren't using the Blank Application template or if you're adding
the control to a page that you created yourself, you might need to add
a call to WinJS.UI.processAll.
If you added the control to your app's home page (which is usually the default.html file), add a call to WinJS.UI.processAll in your onactivated event handler, as shown in the previous example.
If you added the control to a Page control, you don't need to add a call to WinJS.UI.processAll because the Page control does that for you automatically.
If you added the control to another page that is not your app's home page, handle the DOMContentLoaded event and use the handler to call WinJS.UI.processAll.
What's the reasoning behind the system calling WinJS.UI.processAll() automatically for you inside Page Controls, but not elsewhere?
It's also because the Navigation template (and the Grid template which is derives from the Navigation template) includes at least one data-win-control element so it needs to be processed to function.
We (Microsoft) don't want to put too much in the blank project template because after all it is "blank". So the blank project template just gives you the single page, no navigation, no controls, and thus no need for any processing. You can decide to add that on your own.