Hi Dan, I cannot make the connection between what you have described and my need for someone else to be able to add a few extra properties to a persistable class.
New actions/methods can be added by to a class using mixins but how can someone add properties? I can use Java inheritance and the support of that in Datanucleus, but then my question is how to get the new subclass (created by someone else) to be created by an injected repository instead of my original class? Maybe the module mechanism means use the last added implementation of a repository interface in the module hierarchy? Cheers On Mon, Dec 11, 2017 at 2:34 AM, Dan Haywood <[email protected]> wrote: > 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 > > >
