Commit | Line | Data |
---|---|---|
3c1d89bc | 1 | # Roadmap |
8a0ffdf9 | 2 | |
3c1d89bc TO |
3 | The `afform` extension is a proof-of-concept. It aims to demonstrate the core model/concept in which AngularJS |
4 | provides the standard data-format and component-model shared by developers (working in code files) and administrators | |
5 | (working in a programmatic GUI). | |
8a0ffdf9 | 6 | |
3c1d89bc TO |
7 | As a proof-of-concept, it is necessarily incomplete. In particular: (a) some functionality is envisioned for |
8 | additional extensions and (b) within this extension, there are known issues. | |
8a0ffdf9 | 9 | |
3c1d89bc TO |
10 | ## Suite of Extensions |
11 | ||
12 | This extension is expected to be the base for a suite of related extensions: | |
13 | ||
14 | * `afform`: Base framework and runtime. Provides APIs for developers. | |
15 | * `afform_html`: Present web-based editor for customizing forms in HTML notation. Use Monaco or ACE. | |
16 | (In the near term, it's a simple demonstration that forms can be edited by users in a browser; in the | |
17 | long term, it occupies a smaller niche as a developer/power-admin tool.) | |
18 | * `afform_gui`: Present a web-based editor for customizing forms with drag-drop/multi-pane UX. | |
19 | (In the long term, this is the main UI for admins.) | |
20 | * `afform_auditor`: Report on upgrade compatibility. Test changesets. Highlight dangerous/unknown/unsupported form elements. | |
21 | Score maintainability of the system. | |
22 | ||
7046c8a9 TO |
23 | ## Documentation |
24 | ||
25 | * Development and Refactoring: A guide for making changes to supported markup in a maintainable fashion. | |
26 | (*What if I need to rename a tag? What if I need to deprecate a tag? Ad nauseum*) | |
27 | ||
f314d4b0 TO |
28 | ## Known Issues |
29 | ||
30 | Within this extension, there are things which need updating/addressing: | |
3c1d89bc | 31 | |
894cb44d | 32 | * Test coverage for key Angular directives (e.g. `af-api4-ctrl`, `af-api4-action`) |
3c1d89bc | 33 | * There are several `FIXME`/`TODO` declarations in the code for checking pre-conditions, reporting errors, handling edge-cases, etc. |
470fae95 | 34 | * Although afforms can be used in AngularJS, they don't fully support tooling like `cv ang:html:list` |
3c1d89bc | 35 | and `hook_civicrm_alterAngular` changesets. We'll need a core patch to allow that. (Ex: Define partials via callback.) |
8a0ffdf9 | 36 | * We generally need to provide more services for managing/accessing data (e.g. `crm-api3`). |
3c1d89bc TO |
37 | * We need a formal way to enumerate the library of available tags/directives/attributes. This, in turn, will drive the |
38 | drag-drop UI and any validation/auditing. | |
8a0ffdf9 TO |
39 | * Haven't decided if we should support a `client_route` property (i.e. defining a skeletal controller and route for any form). |
40 | On the plus side, make it easier to add items to the `civicrm/a` base-page. On the flipside, we don't currently have | |
4f4b6487 | 41 | a strong use-case, and developers can get the same effect with `civix generate:angular-page` and embedding `<div hello-world/>`. |
afc4a89b | 42 | * Injecting an afform onto an existing Civi page is currently as difficult as injecting any other AngularJS widget -- |
4f4b6487 | 43 | which is to say that (a) it's fine for a Civi-Angular page and (b) it's lousy on a non-Angular page. |
afc4a89b TO |
44 | * The data-storage of user-edited forms supports primitive branching and no merging or rebasing. In an ideal world |
45 | (OHUPA-4), we'd incorporate a merge or rebase mechanism (and provide the diff/export on web+cli). To reduce unnecessary | |
46 | merge-conflicts and allow structured UI for bona-fide merge-conflicts, the diff/merge should be based on HTML elements and | |
30821357 TO |
47 | IDs (rather than lines-of-text). |
48 | * API Request Batching -- If a page makes multiple API calls at the same time, they fire as separate HTTP requests. This concern is somewhat | |
49 | mitigated by HTTP/2, but not really -- because each subrequest requires a separate CMS+CRM bootstrap. Instead, the JS API adapter should | |
50 | support batching (i.e. all API calls issued within a 5ms window are sent as a batch). | |
51 | * Default CSS: There's no mechanism for defining adhoc CSS. This is arguably a feature, though, because the CSS classes | |
52 | should be validated (to ensure theme interoperability). | |
9384980c TO |
53 | * `Civi/Angular/ChangeSet.php` previously had an integrity check that activated in developer mode |
54 | (`\CRM_Core_Config::singleton()->debug && $coder->checkConsistentHtml($html)`). This has been removed because it was a bit brittle | |
55 | about self-closing HTML tags. However, the general concept of HTML validation should be reinstated as part of the `afform_auditor`. | |
56 | * `hook_alterAngular` is used to inject APIv4 metadata for certain tags. This behavior needs a unit-test. |