I have an GWT module, which defines an entry point that builds an UI (let's call this module A).
I inherit module A in another module (say module B), which builds its own UI via its own entry point, reusing classes defined in inherited module A.
My problem is, when I initialize module B, entry points from both Module A and B are instantiated and triggered (via onModuleLoad method). This results in both entry points modifying same UI in turn, resulting in corrupt page.
So, I want to inherit a module, but I don't want its entry points activated during application initialization. How can I inherit a module, but avoid initialization of its entry point class?
Instead of inheriting A from B, and adding more entrypoints that need to be built, consider making a third module. The new one, Z should be the common code that both A and B need, and should not have an entrypoint. This way, both A and B can inherit from Z and each add their own entrypoint as needed.
If the above can't be used (for example if you can't edit A), another option could be to add a new module in the same package as A, call it A2, and give it the same contents of A, minus the EntryPoint. Then, B can inherit from A2 instead.
Related
I'm trying build a framework which starts with reading an input file which contains some keys and corresponding values. I then update the variables accordingly:
from Inertia import Inertia
...
d = hf.read_input(fin)
locals().update(d)
Then, I'm defining the group MDA:
class MDA(om.Group):
class ObjCmp(om.ExplicitComponent):
def setup(self):
...
def setup_partials(self):
...
def compute(self, inputs, outputs):
...
def setup(self):
...
which contains two subsystems (for now):
self.add_subsystem('d1', SomeModule(), promotes_inputs=['x1','x2'],
promotes_outputs=['y1','y2'])
self.add_subsystem('obj_cmp', self.ObjCmp(), promotes_inputs=['y1'],
promotes_outputs=['obj'])
For housekeeping reasons, since the framework will eventually contain large number of subsystems, I want to keep the classes defining the particular subsystems in separate scripts, imported the the main script (the one where the Group is defined).
The problem I'm facing is that if I only read the input file once at the level of the script where the Group is defined (before entering the Group() class), the variables retrieved this way are not defined at the lower levels, for instance, I cannot use them inside SomeModule(). I'd normally define an init() method inside SomeModule() to be able to pass some variables:
def __init__(self, d):
self.d = d
but since we instantiate the SomeModule() class within self.add_subsystem(), it does not work.
I would be really grateful for any hints.
In OpenMDAO, we deal with this instantiation timing issue in two ways:
We strongly discourage the use of the __init__ method for components or groups. Instead, we recommend you rely on the initialize and setup methods. initialize is called inside the existing __init__ (i.e. at instantiation time). setup is called much later during the build up of the model hierarchy.
We do provide a means of creating init arguments via an options system. Options allow for some built in validation and also give you the chance to change the values later if you want to.
Delaying as much as possible till setup, if you can. Pass your configuration file (or an object built from it if you prefer) into your component as an option, but don't actually use it till setup.
This goes for both components and groups. You can make the configuration data an option at all levels of your groups. They will each pass the object down to their children inside their own setup methods. This way, you only need to have the object in existence by the time you initialize the top level group. It will then pass it down to all its children.
I am trying to get the hang of IoC and DI and am using Castle Windsor. I have an object I have created that can be multiply instantiated but over different generic types. For example
MyType<Generic, Generic2>
on Installation of MyType's assembly
container.Register(Component.For(typeof (IMyType<>)).ImplementedBy(typeof (MyType<>)));
Then in my main modules initialization I install MyTypes module with MyTypeInstaller which is a IWindsorInstaller.
Then I am manually resolving the various types of MyType that I want (this will actually be spread around different installers). But something like
container.Resolve<IMyType<type1, type2>();
That creates an actual instance of MyType registered for the generic types passed in.
This works fine, I get the instances of MyType<,> I need created.
Now, finally I have another module I have created that I will install last. I want to say,
container.ResolveAll<IMyType<,>>()
then create this instances of this new object for each object that exists.
However I cant seem to resolve all of the IMyTypes<,> without knowing the concrete types that each one were instantiated as.
At any rate, it is possible I am just doing this wrong and want feedback in general as well.
First, if MyType<T1,T2> can only be instantiated once for each combination of T1,T2 then you should be registering it is a Singleton.
Second, You cannot call strongly type container methods (like ResolveAll<T>) with an open generic - it MUST be a closed type.
Third, MyType is an open generic type and the number of closed generic classes is infinite (generic type constraints are not considered by the container). So, as far as the container is concerned you can call Resolve<ANYTHING, ANYTHINGELSE> and it will attempt to provide a MyType<ANYTHING,ANYTHINGELSE> for you. If ANYTHING and ANYTHINGELSE don't satisfy the type constraints then you will simply get a run time error.
Even if you could call ResolveAll<IMyType<,>>() what would you expect it to return given that you have registered an open generic implementation?
Let's say I have a number of GWT modules which are used as libraries, and one module with an entry point which inherits all of the library modules.
Each of the submodules needs to access a single instance of SomeClass.
If I call GWT.create(SomeClass.class) in modules A & B, do I get the same instance? If so, is this guaranteed?
No. GWT.create(SomeClass.class) compiles to new SomeClass(), unless there is a rebind rule of some kind - a replace-with or a generate-with rule will cause this to instead invoke the default constructor of whatever type is selected by those rules.
This means that GWT.create is not a suitable way to provide access to a singleton instance. Instead, consider some DI tool like Gin, or manual DI by always passing around the same instance. It is also possible to use the static keyword to keep a single instance where all code compiled into the same app can reference it.
I want to build a simple 'rake' style command line tool that will allow me to define tasks in scala (that can optionally take additional command line arguments) that will be automatically loaded and accessible through a single main() method, to provide a single point of entry and minimize generating lots of wrapper scripts.
An example of what I'm looking for is Jersey, which will automatically load all annotated classes in a specified package and create REST endpoints. What's the right way to do this in scala? Basically, I just want to end up with a collection of instances of every class in a
package with a given annotation (which all have a Task trait or are a subclass of Trait, etc.)
Suppose I want to find out in which package a class is defined, e.g. say (defclass x ()()) is defined in p1. One way could be to get the package via (symbol-package 'x). the problem with this solution is that x is exported in a different package p2. Any other suggestions?
As Rainer Joswig said, classes aren't defined in packages; symbols have packages and the name of a class is a symbol.
If you want to know the value of *PACKAGE* at the time the class definition read, compiled, or loaded (which could conceivably be three different values), I do not believe there is any way to retrieve that unless you write code to store it at that time.
Furthermore, it doesn't seem like a meaningful piece of information to have. A package is simply a namespace for symbols, and there's no reason the package that was current at the time the class definition was read, compiled, or loaded should have anything to do with the class itself.
However, if what you really want is for the name of the class x to reside in a package p1, but p2 exports it, you may be interested in adding x to the shadow list of p1 in its defpackage form (or after).