Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Currently Supported

  • Localizable Strings
  • SCSS/CSS
  • Add UI-Path & Navigation Options
  • Backend Extensions

In Process and Undocumented

  • File Overwrite
  • UI-Route Overwrite

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

IssueDiscussionDecisionTicket(s)

Extendable UI-Views

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

Solution (A): UI-View Extension

Currently we use UI-Router to coordinate the application, where a UI-View element is implemented to display a single page component. We could extend UI-View to take a list of components, allowing multiple components to be shown in one page area. 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)

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.


(A)(B)
Pro
  • Possible to unit test component integration
  • Component registration files easy to notice
  • 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



Form Extensions

A theoretical pain point for implementers is to add a single checkbox or configuration option to a configuration screen. Example: Assign a color selection to a user setting.

This proposal would allow for Templates/Controllers to be added to a `<form>` element programatically. This would function much like extendable UI-Views, but the large technical difference is there would need to be a way to register a function to execute when the form is submitted.






  • No labels