IIDM extension design issue

[geofjamg]

• Do you want to request a feature or report a bug?
  A bug or at least a design flaw

• What is the current behavior?
  Network model has been split in API and implementation part so that we can have different implementations for different purposes but a single API. So processing on top of network api like merging, import, export, simulation could be reused for any implementation.

Unfortunately this has not been done for extensions.

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

Example to add an XNode extension to a dangling line:

DanglingLine l = ...
l.addExtension(Xnode.class, new Xnode(l, "FR"));

So here we directly instantiate the extension and add it the dangling line.
What about if DanglingLine is not coming from in memory default implementation but from a persistent connected to a db one?

• What is the expected behavior?
  As for network API extension could be split into API and implementations and provide a builder like way to create it in order to hide the instantiation.

DanglingLine l = ...
Xnode xNode = l.newExtensionAdder(XnodeAdder.class)
   .withCode("FR")
   .add();

And depending of impl, correct Adder will be used. For this we could imagine a plugin archi like

interface ExtensionAdder<E extends Extension> {

   E add();
}

interface ExtensionAdderFactory<A extends ExtensionAdder> {

   // infos to link with correct Network impl ????

    A createAdder();
}

• What is the motivation / use case for changing the behavior?

To allow alternative IIDM implementation to use extensions.

• Please tell us about your environment:

  • PowSyBl Version: 2.5.0-SNAPSHOT
  • OS Version: -

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

[miovd]

Maybe ExtensionAdderFactory can be more understandable than ExtensionAdderProvider?

[geofjamg]

Maybe ExtensionAdderFactory can be more understandable than ExtensionAdderProvider?

Ok for ExtensionAdderFactory

[jonenst]

What's the relationship between l.newExtensionAdder and ExtensionAdderFactory.createAdder ?

[jonenst]

is the newExtensionAdder added to the Extandable interface ?

[geofjamg]

What's the relationship between l.newExtensionAdder and ExtensionAdderFactory.createAdder ?

newExtensionAdder() impl will look for a ExtensionAdderFactory plugin matching criteria and then call ExtensionAdderFactory.createAdder.

[geofjamg]

is the newExtensionAdder added to the Extandable interface ?

yes

[geofjamg]

A similar design has been done in AFS, for instance:

ImportedCase importedCase = folder.fileBuilder(ImportedCaseBuilder.class)
                .withCase(aCase)
                .withParameter("param1", "true")
                .withParameters(ImmutableMap.of("param2", "1"))
                .build();

[miovd]

Resolved by #1152