topic Re: Alfresco Content/Process App Module/extension mechanism in Alfresco Forum

Alfresco Content/Process App Module/extension mechanism

binduwavell — Tue, 23 Jan 2018 17:30:20 GMT

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 cr

Re: Alfresco Content/Process App Module/extension mechanism

douglascrp — Tue, 23 Jan 2018 17:38:10 GMT

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

Re: Alfresco Content/Process App Module/extension mechanism

binduwavell — Tue, 23 Jan 2018 17:43:27 GMT

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/alfresco-ng2-components ·…

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.

Re: Alfresco Content/Process App Module/extension mechanism

dvuika — Tue, 23 Jan 2018 18:26:22 GMT

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.

Re: Alfresco Content/Process App Module/extension mechanism

mromano — Tue, 23 Jan 2018 22:18:12 GMT

Great list

Re: Alfresco Content/Process App Module/extension mechanism

afaust — Tue, 23 Jan 2018 22:19:52 GMT

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

Re: Alfresco Content/Process App Module/extension mechanism

deas0815 — Wed, 24 Jan 2018 05:28:44 GMT

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.

Re: Alfresco Content/Process App Module/extension mechanism

dvuika — Wed, 24 Jan 2018 08:21:51 GMT

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

Re: Alfresco Content/Process App Module/extension mechanism

mikel_asla — Fri, 26 Jan 2018 11:39:33 GMT

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

Re: Alfresco Content/Process App Module/extension mechanism

ohej — Fri, 26 Jan 2018 20:53:22 GMT

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.

Re: Alfresco Content/Process App Module/extension mechanism

anakin59490 — Tue, 06 Feb 2018 17:21:41 GMT

Hi,

alfresco-content-app is a great job !

But it will be very useful if ADF app could communicate with platform-jar structure in order to reproduce this kind of simple scenario : Form from sdk3 to ADF

Congratulation for your work !!

Re: Alfresco Content/Process App Module/extension mechanism

ohej — Thu, 08 Feb 2018 09:04:56 GMT

Hi all

I just wanted to give a heads up that we have not forgotten about this topic. We've had quite a few internal meetings about the topic last week, and we are actively exploring options.

Essentially we are working on a mechanism that allows runtime loading of "plugins", which would allow you to hook into different parts of the application - routes, content projection and much, much more.

We're currently doing some internal evaluation to see if the potential solution is fit for purpose. Once we feel good about it, we will start doing some validation with you guys where we present the proposed solution and gather feedback.

We haven't planned out the exact way we share the findings, if it will be a blog, tech talk live, individual or group meetings - most likely a combination.

We will start sharing some technical details soon!

Re: Alfresco Content/Process App Module/extension mechanism

deas0815 — Fri, 23 Feb 2018 12:54:05 GMT

This page seems to be one of the entry points with regards to the recent UI runtime-extensibility-/module efforts. People jumping in at this time might get the impression it is already over. The other day, Denys Vuika mentioned on Twitter it is covered somewhere in TTL. Just saying.

Re: Alfresco Content/Process App Module/extension mechanism

cjose — Fri, 18 May 2018 17:35:41 GMT

I just saw this thread for the first time and thought I'll add an example approach which we took recently for a demo which we built on top of Alfresco Process Workspace aka APW (OOTB ADF based app with APS) and leveraging some components of ACA . In this case I leveraged the "App" container in APS as a case container. Then used the app.config.json in APW to determine the things I want to include/exclude in each Apps. An example entry in the app.config.json show below. Hopefully this will help someone develop case management style apps using ADF!

"1001": {
            "name": "Drone Case Management",
            "defaultLandingPage": "insights/support-cases",
            "showOOTBDashboards": false,
            "apsApp": true,
            "showInsights": true,
            "showProcesses": true,
            "showTasks": true,
            "showCreateTask": true,
            "showCreateProcess": true,
            "showContents": true,
            "showAdvSearch": true,
            "showDataLookup": true,
               "accordionGroups": {
                    "insights": {
                         "default": "support-cases",
                         "items": [{
                        "id": "support-cases",
                        "name": "Cases & Faults"
                    },
                    {
                        "id": "sentiment-analysis",
                        "name": "Sentiment Analysis"
                         }]
                    },
                    "advsearches": {
                         "default": "case-search",
                         "items": [ {
                        "id": "case-search",
                        "name": "Search Cases"
                    },
                    {
                        "id": "fault-search",
                        "name": "Search Faults"
                         }, {
                        "id": "recall-search",
                        "name": "Search Recalls"
                         }, {
                        "id": "repair-search",
                        "name": "Search Repairs"
                         }]
                    },
                    "datalookups": {
                         "default": "models",
                         "items": [{
                        "id": "customers",
                        "name": "Customers"
                         }, {
                        "id": "models",
                        "name": "Drone Models"
                         }]
                    }
               }
        },‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

The above config resulted in..

Re: Alfresco Content/Process App Module/extension mechanism

afaust — Sun, 20 May 2018 12:36:11 GMT

This requires the customer / client to override the packaged app.config.json, which violates the idea of an immutable app shipped by the vendor (which was a big argument for Alfresco to push for JAR extensions in ACS). Ideally, any extensibility feature would not require overriding default files.

Are there any plans for APS to support moving away from "magic numbers" for targeting such customisations to specific apps (i.e. the DB ID 1001 for your app) towards proper app naming? I.e. I'd like to be able to create a customisation for process app using the same abstract (logical) ID in DEV, UAT and PROD, without having to account for their different DB IDs, e.g. having separate config files for each target environment.

I hope all those "names" are localised somewhere, i.e. not like the ADF / APW language selection list which is always English even after user already selected German language.

Re: Alfresco Content/Process App Module/extension mechanism

dvuika — Sun, 20 May 2018 12:44:42 GMT

Would be nice if you raise a ticket for the language selection list with steps to reproduce and ADF version. If you find JIRA difficult, we also accept the GitHub tickets and then manually move them to JIRA if needed: https://github.com/Alfresco/alfresco-ng2-components/issues/new. Thanks in advance.

Re: Alfresco Content/Process App Module/extension mechanism

afaust — Tue, 22 May 2018 12:27:57 GMT

Since APS is an Enterprise product, the proper way is to go through Support, which I can't. The customer has filed their ticket today as ACT 00964167. They are typically a few weeks behind on reporting issues we find in our project(s), because 1st level support is annoyingly inefficient in reproducing obvious out-of-the-box issues and requires a substantial amount of hand-holding.

Re: Alfresco Content/Process App Module/extension mechanism

cjose — Tue, 22 May 2018 12:51:56 GMT

Thanks for the feedback Axel. As I said, this is something that I adopted for the current version of APS. Creating a logical environment-agnostic name for all deployment models is an item that I hope will be tackled as part of Activiti 7 and APS 2.0, and agree it is a pain! Feel free to provide your valuable comments to all the Activiti 7 related RFCs such as https://community.alfresco.com/community/bpm/blog/2018/04/11/rfc-activiti-cloud-application-service

Btw, the environment specific model ids eg:1001 were replaced with model keys (environment agnostic) in Activiti 6. Another reason for me to believe that it will be fixed in APS 2.0

Re: Alfresco Content/Process App Module/extension mechanism

john_knowles — Thu, 06 Sep 2018 16:46:13 GMT

Quick update for you Denys just merged version 1.4 which includes the first phase of extensibility work. Please see the documentation for more info on the details.

We are looking forward to feedback on the progress so far on both extensibility in the app, and the associated documentation.