Hi Steve,
We've been working on some stuff regarding the app manifest recently that I
think will be relevant and useful for you. (We've done this in Estatio
originally, but I've been pushing down into the framework for the benefit
of all).
The main new concept is Module, which is now an actual applib-defined
interface along with a no-op default implementation, ModuleAbstract. A
Module can declare its immediate dependencies, and from this we calculate
the full set of transitive dependencies. A Module might be one-to-one with
Maven modules (in which case the declared dependencies will mirror the
compile-time dependencies within the respective Maven pom.xml files) or
alternatively a Module might be "logical", with several defined within a
single src/mina/java Maven module (ie Maven is merely the compilation
unit). (Aside: this latter design is much less boilerplate, and is
probably the way in which we see Java 9 modules being used within Isis once
we get there).
Along with the new Module and ModuleAbstract, I've also subclassed
AppManifest and AppManifestAbstract, namely AppManifest2 and
AppManifestAbstract2. The latter has its own Builder. The main idea of
these variants of AppManifest is that they are bootstrapped with a single
Module, but can then customise if necessary.
With respect to your requirement, yes, you would still have a custom
AppManifest for each customisation, but the customisation would basically
be delivered as a Module which is then defined as an additional dependency
of your original AppManifest.
For example, something like:
package com.mycompany.myapp.standard;
public class TopLevelModule extends ModuleAbstract {
public Set<Module> getDependencies() { return Sets.newLinkedHashSet(new
CustomerModule(), new OrderModule(), new ProductModule());
}
public class StandardAppManifest extends AppManifestAbstract2 {
public static class Bulder BUILDER = Builder.for(new TopLevelModule);
public StandardAppManifest(BUILDER);
}
Then, suppose your customisations for "client A" go into
CustomisationsModuleForClientA
package com.mycompany.myapp.clientA;
public class CustomisationsModuleForClientA [ ... }
You would then do:
public class AppManifestForClientA extends AppManifestAbstract2 {
public static class Bulder BUILDER =
StandardAppManifest.BUILDER.withAdditionalDependency(new
CustomisationsForClientA());
public AppManifestForClientA(BUILDER);
}
How does this sound?
Cheers
Dan
On Sun, 10 Dec 2017 at 02:10 Stephen Cameron <[email protected]>
wrote:
> Hi,
>
> I want to provide an Apache Isis application and I expect others to extend
> the default entities, I think that the way to acheive this is for
> 'repository' domain services to be overridden, the new versions will create
> the extended custom entities instead of the default ones.
>
> In the security module this is done by creating an implementation of
> 'ApplicationUserFactory' that has a method 'newApplicationUser' where you
> return your custom ApplicationUser. I can study this to see Apache Isis
> knows to use the altenative factory implementation instead of the default
> one.
>
> However, I am wondering if the is different way to do this that I can use?
> I'm thinking of how the app manifest can be used for this purpose. So the
> person wishing to extend creates an new app manifest and changes
> isis.properties for the framework to pick this class for startup. This then
> hase the effect of injecting alternative repository (or 'factory') classes.
> All such factory classes will have to implement one or other interface
> obviously.
>
> Thanks
> Steve
>
