I have created the following issue for the Alfresco Content App (ACA):
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:
Following is an initial list of highly desirable features of such a system (in my opinion):
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.
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
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.
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.
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...
Regarding other stuff...
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.
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
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.