Login
Register
Contact- This topic has 2 replies, 2 voices, and was last updated 4 years, 9 months ago by
.
-
Posts
-
-
Our business clients have requested the ability to navigate within the application by clicking on one of the dashboard badges. I.e., if the user clicks on the “opportunity” badge, then the application should navigate to the Journal > Opportunities tab for the current contact.
We have seen success with this on a small scale. If “screen” contains “form A” and “form B” in a group layout, then form A can fire an event that it does not handle. The event bubbles up to the screen, which handles it by setting the current tab to form B. So navigation to a “sibling form” is possible.
However, the badge problem is an attempt at navigating on a larger scale. The EntityDashboard form is contained in the EntityDashboardPortlet screen, which itself is contained in the Person screen (among other places, but we can start with Person to keep it simple). An event fired from EntityDashboard bubbles up to EntityDashboardPortlet, but does not appear to bubble up any further. So Person.screen cannot perform any tab switching as described above. We also tried using the push redirector to send a notification to the Person screen to fire a UI event, but with no success. (Admittedly, I have little experience with the push redirector, so I may not be working with it correctly. However, all of us involved with this project agree that this is a heavy-handed approach.)
TL;DR: Is it possible to programmatically navigate within the application? If so, how is it done?
0 -
-
Hi Louis, please note in Classic the workspace definition screens (e.g. Person.screen) are used only for seeding workspace layout and registering accepted context, and their scripts will not execute.
Using Push is possible but would execute asynchronously and delivery is best effort so it might not be timely. The handler would be placed in ContactBrokerPortlet.
It sounds like you already know this but UIEvents can be added to HTMLLabels with (@event …) that can be handled by the portlet. From there you should look at how navigation works in other event handlers such as clicking a contact on a grid. If you examine the goToContact event handlers in EntityActList they’ll point to functions such as act-go-to-contact -> client-got-entity-model. The internal function event-fire eventually leads to firing events through the context adapter, which is how events are allowed to leave a portlet, reach the container and communicate with other areas of the application. Please review your Portal documentation for more information on this topic. Handling of navigation for “navigateToEntity” is then handled in ContactBrokerPortlet.screen calling into (navigate …)handling navigating to another workspace and then setting context again.
There are similar paths for other model types to navigate. Given the many examples of this approach, I would recommend proceeding down this path.
0
-
- You must be logged in to reply to this topic.