Requisition Splitting - UI Extensions

Currently Supported

Localizable Strings
Allows for updating strings or adding languages through transifex
SCSS/CSS
Replace variable settings, change layouts, colors, ect
Add UI-Path & Navigation Options
Add additional pages into UI, and they get exposed
Backend Extensions
Requisitions product grid has columns that are defined entirely through the backend

In Process and Undocumented

File Overwrite
Update logo files, template layout files, or how a service operates internally
UI-Route Overwrite
Change a view definition at runtime, changing the template or controller

Gliffy Diagram is only supported by the cloud editor

Because Forge macros arent supported by the legacy editor, you'll need to convert this content to the cloud editor to display this macro properly. Find out more about converting to the cloud editor

Depth of Extendability

UI-View (Global)
Allow views defined in UI-Router to have additional content added before or after
Requisition Page
Take the time to build extendable hooks into highly used pages, so that implementers can add functionality to those specific pages. This would discourage developers from forking main parts of mark-up, but it would be important to have enough documentation to support these features or changes.
Budget popover
Many large pages have small sections that may require extension, but the functionality here is limited and fairly small. Is it worth investment to build hooks into these components or allow for small pieces of code to be forked.

Questions

Issue	Discussion	Decision	Ticket(s)

Issue

Discussion

Decision

Ticket(s)

Extendable UI-Views

Need: Ability to add or modify the components within a page's layout

Solution (A): Extension Directive

Create an angular directive that allows implementers to register a state to a uniquely named extension directive. This would allow a HTML layout template to display a set of components in the order they were registered. This extension directive could be inserted into administration forms to allow for single checkboxes form configuration items to be added to a page. The feature set for this extension would include:

Component registration with a unique id
Component order enforced by priority
Resolved values injected into controller (not passed by scope)

Gliffy Diagram is only supported by the cloud editor

Because Forge macros arent supported by the legacy editor, you'll need to convert this content to the cloud editor to display this macro properly. Find out more about converting to the cloud editor

Solution (B): Template overload

In the build process, we are planning to combine UI-repositories/docker-volumes by merging file structures based on file paths. This allows an implementer to replace the HTML markup for a page's layout and add the components that they need.

Gliffy Diagram is only supported by the cloud editor

Because Forge macros arent supported by the legacy editor, you'll need to convert this content to the cloud editor to display this macro properly. Find out more about converting to the cloud editor

	(A)	(B)
Pro	Possible to unit test extension directive Component registration files would have obvious	No additional work needed Most layout files have simple code, that shouldn't change much
Con	Implementation could be difficult	Effectively forks the template files that are being overloaded Impossible to unit test Relies on components being modular (not including variables from $scope)

Documentation

What is the best way to document extension points?

JS Documentation
Markdown documentation guide
Sample extension git repository
- What would make a good example to illustrate/test all features?