AFL Layouts, Dialogs and navigating

[Max Widmaier]

Hello, we are working on some custom AFL applications and I’m investigating the capabilities and specific implementations of things in AFL. The problem I’m running into is that there is very limited documentation available. For example, there is some information on creating custom portlets, however, what about dialogs and layouts? Something specific that would be very useful is navigating to existing workspaces and opening dialogs. We are working specifically with React, and it would be useful if we could render already built NexJ components (Such as pickers, or opening existing dialogs).

The most documentation I could find on what libraries are available is here. As for navigation there is some documentation on the Portal API for JavaScript (Under PortalAPI.navigate). However, there seems to be no documentation on how to use it in an AFL application. I assume that methods such as this could be accessed through a callback in the main component’s props, and I assume something similar would apply to rendering pickers/dialogs, however, I have no idea if that would be compatible with React, or if we’d have to build our own pickers.

The capabilities of AFL seem to be large; however, there is just a lack of documentation on other (and quite important) topics like navigation. I can understand not rendering pickers and such with react as they aren’t necessarily compatible (with my knowledge), but if they are, they could be rendered through callbacks. How would that be achieved though?

Thank you very much for your time!

0

[Max Widmaier]

There are three use cases specifically we are looking into.

Use case 1: Using existing pickers inside of applications. We are developing an application which would benefit from being able to use pickers for sorting and searching through objects. For example, I would like to be able to access the UserPerson picker instead of building one myself. This way the application(s) would have more parity with the main CRM and would also make developing easier. This use case also applies to existing dialogs and such.

Use case 2: This is specifically in regards to custom layouts. We are looking into a custom HTML-based, mass email builder. It would be more convenient to just use a dialog in the Contacts workspace rather than creating a whole new workspace.

Use case 3: Navigation. This one is mostly self-explanatory. If a user wants to open a contact, opportunity, or task from a custom application and can’t, then that’s a big detriment to user experience. It is part of the Portal API, I just don’t know what libraries to include in the portlet definition in order to use that method.

0

[Max Widmaier]

For use case 3, I just was reading through the documentation when I spotted something on URL navigation. I believe that should be sufficient in most cases.

0

[Author]

Posts