Alfresco Content/Process App Module/extension mechanism

[binduwavell]

I have created the following issue for the Alfresco Content App (ACA):

Module/extension mechanism · Issue #179 · Alfresco/alfresco-content-app · GitHub 

Following is the initial detail, let's use this page on the community to discuss our needs in this area:

I believe that there has been some work to create a module system where we can create an Alfresco Content App (ACA) customization artifact and drop it into a location in the OOTB app without extending the code of the ACA. It would be great to have some discussion about the approach(es).

There are a few higher level goals here:

• Provide a way for implementors to create re-usable enhancements to ACA that can be composed when creating a solution.
  • e.g. I want to add AOS and Case Management
• Provide a way for implementors to create enhancements that are likely to be upgrade safe

Following is an initial list of highly desirable features of such a system (in my opinion):

• It should be possible to add page components to the router via configuration
  • It should be possible to configure that certain custom pages show up in the toolbar
  • It should be possible to configure that certain custom pages don't show up in the toolbar (if they are contextual.)
• It should be possible to add buttons to the main toolbar
• It should be possible to configure actions for the "New" menu
• It should be possible to configure actions for the User menu (far right of toolbar)
• It should be possible to add document list actions (and associated logic for when to display/enable the same) via configuration
  • Ideally it should be possible to affect the ordering of these actions via configuration
  • Ideally it should be easy to add an action to route to a custom page
  • Ideally it should be easy to route to another ADF app; passing context, credentials and a back link (I will create an ADF issue for this.)
  • Ideally one action can be configured as the default in certain conditions (i.e. don't go to preview, instead route to another application when a document is activated.)
• It should be possible to configure custom result columns
  • Ideally it should be possible to configure different columns depending on context. e.g. under contracts I want to show one set of columns, under finance a different set of columns should be displayed
• It should be possible to configure custom cell content renderers
• It should be possible to configure flag providers
• Once search is fleshed out it should be possible to configure advanced search providers
  • It should be possible to configure the zero state when a search returns zero results
• It should be possible to configure additional "smart folders" like "My Favorites", "Shared Documents" etc.
  • Ideally it should be possible to affect the ordering of these via configuration
• It should be possible to configure preview components
• It should be possible to configure metadata forms (create, edit, view at least)
• It should be possible to configure custom field renderers fro metadata forms.
• It should be possible to configure Open With menu items
• It should be possible to configure "More Options" items
• Would be great to allow us to configure components to trigger during the upload process
  • Some might be passive (once upload completes perform some API calls against the uploaded docs)
  • Some might be active, gather metadata before or after the upload
• It should be possible to configure left and right trays based on contextual information/logic
• Ideally "modules" can interact with each other. As such, having some control over load order of modules may be important.

As an overarching goal there should be a single config file in ACA and one in each "module" that plugs the module into the ACA. i.e. don't make devs sift through many different configuration files. Ideally configuration merging/replacement strategies will be well documented and easy to determine the effective configuration once all modules have been deployed.

I'm sure other folks will have additional ideas, I hope this is a reasonable starting point.

[douglascrp]

It would be useful to have something similar to evaluators (both document list and module).

About the items below, a good example would be to be able to implement something just like the uploader-plus addon:

Would be great to allow us to configure components to trigger during the upload process

• Some might be passive (once upload completes perform some API calls against the uploaded docs)
• Some might be active, gather metadata before or after the upload

[dvuika]

Good feedback, thanks. We already have an Upload Service with a set of hooks: ADF Component Catalog It's a good candidate to extend with more lifecycle events like you've mentioned above.

[binduwavell]

I just posted the following ADF feature request related to this discussion: Provide a best practice / sample implementation for cross-app routing · Issue #2871 · Alfresco/alfre... 

Here is the detail from that issue:

As ADF starts being used we expect implementors to create and share many types of components. Additionally it is likely that some special purpose apps will be created. I believe it will be very useful for such apps link to each other, passing context and credentials and possible a return path.

I realize that this is likely more of an Alfresco Content/Process App type issue. However I believe it will affect bespoke apps as well built with ADF. As such, I think that providing some guidelines on how to perform app linking (and return) will be beneficial for folks creating ADF solutions.

Imagine we are creating an ADF application for a large company. Realistically we may want to create apps for each department or possible for each role/use-case. Imagine a sales rep is in the Sales App and they find some documentation related to a product that is in development. It would be ideal if the Sales App could route to the Engineering App passing along the context of the product the sales rep located and also any credentials that were used to log into the Sales App. This way, the sales rep will enter the Engineering App without having to provide credentials again and they will be navigated to the appropriate user experience for the product they are interested in. Ideally the routing mechanism would understand that the user came from the Sales App and would in the case provide a button in the toolbar to go back to where they were in the Sales App when they entered the Engineering App.

[mromano]

Great list 

[afaust]

While the specific features / use cases for individual components may be useful as examples / validations, I personally am much more interested in a generic extension / customisation concept at this point, which should be applicable to any part of an eventual DMS/Collab app - even those added by extensions from 3rd-party providers.

Regarding components / component instances...

Ability to

• Remove a component instance
• Replace a component instance
• Change the component type while keeping all other attributes (i.e. replace base implementation with extension)
• Add a component instance before / after another component instance
• Add / Modify / Remove configuration attributes of a component instance
• Target a specific component instance, i.e. if same component type is used twice in a context / page, I only want to apply customisation to one of them
• Target component instances of a specific type
• Target a component instance at any level of nesting, i.e. when components wrap each other (nesting in top-level markup or via component specific markup), don't have to unwrap/modify all layers just to add/modify a minor thingy

Regarding other stuff...

Ability to

• Remove / modify / add a routing
• Bundle multiple customisations into an atomic bundle
• Provide multiple bundles of customisations per extension / addon module
• Have customisation / bundle of customisations or extension / addon module depend on another (for activation / implicit order)
• Have customisation / bundle of customisations or extension / addon module ordered on additional priorities / via administrator intervention (latter unlikely without a server component)
• Have customisation / bundle of customisations or extension / addon module be enable/disable-able at runtime via administrator intervention (unlikely without a server component)
• Target a single customisation / bundle of customisations only to
  • specific routing, generally or based on tokens from the route
  • specific user / role / group
  • arbitrary dynamic evaluation via provided evaluator function / component
• Provide configuration (app.config.json, and others?) mutations (removal / modification / addition)
• Provide custom i18n resources, potentially overriding defaults
• Provide custom SCSS variables, potentially overriding defaults
• Switch between SCSS variable sets for different routes / contexts (or reload browser with current app state but different SCSS variable set)
• Have end-user / customer "guaranteed-last-wins" override over any customisation applied from extension / addon modules

[deas0815]

Excellent write-up Bindu!

To be honest, getting (retrofitting?) all this (Share alike) runtime extensibility into the ACA and/or ADF looks like a huge effort to me. I might be wrong, but I don't think this functionality has been a first class design goal. Maybe there were even compromises sacrificing potential implementation. I'd appreciate designers and stake holders of those components making a statement about their feelings with regards to general technical feasibility.

[dvuika]

For ADF 2.2 release we are working on Lazy Loading support that opens doors to many great scenarios, including modules that are loading extra features on demand and adding extra routes for the application and main routing. So I suggest reading on that: Angular Docs 

[mikel_asla]

I published this post trying to expose our view, hope it helps

[ohej]

We really appreciate the momentum on this topic. Keep the good feedback coming. 

‌ and I will pick up this topic early next week for internal discussions to see how we can plot a strategy for covering some of these use cases. Please note that this is not a commitment (yet), but we are listening and discussing. We will most likely be reaching out for some interviews to gather more structured feedback.

Stay tuned.