In a custom plugin in custusX i use mServices->patientModelService->getPatientLandmarks()->setLandmark to programmatically alter some landmarks. I want to perform the registration with a already present volume.
In LandmarkPatientRegistrationWidget in org.custusx.registration.method.landmark, performRegistration() calls mServices.registrationService->doPatientRegistration().
However, I'm not sure whether my approach to get hold of a registrationService instance is right.
I have so far added org_custusx_registration to the CMakeLists.txt file and added "cxRegistrationService.h" and <cxRegServices.h> as includes.
Now I can define a RegServices mRegServices and initialize it in the constructor with the mContext of the plugin.
But do I create an own registration service or do I get access to the already existing? How can I get access to the already running registration service?
Your method correctly reuses the existing running registration service.
The default setup of CustusX register a single instance (object) implementing the cx::RegistrationService interface. The cx::RegServices helper class contains a cx::RegistrationServiceProxy, which acts as a smart pointer referring the object. Service objects are only created by the plugin that implement them: Users simply get access to these objects.
The RegistrationServiceProxy implements this using a ctkServiceTracker and related classes, see for example this tutorial on OSGi, section 5.4 (in java, but the principles apply).
Related
I'm writing a custom controller that would listen to a CR I defined and update/create other resources (ones defined by Istio). All the examples out there show either how to handle native resources or custom ones created in the same package. But the resources I want to manage already exist and are registered in the cluster. So what I'm failing to understand is how to create or update them in Go code without describng them with my own types.
So I fgured out there is no way to do this without actually defining schemas for all the objects I want to manage in my own code.
I suppose it would be a good idea for anyone providing open source CRDs to also provide a go library that defines the types for them
I can't seem to grasp the modules of dagger.
Should I create a new instance of a module each time I want to inject stuff?
Should I create only one instance of a module? If so where should I do it?
Is there a more complex example of fragments and activities used with dagger?
Thanks
You should think more about #Component than #Module. Modules just create objects that need further initialization. The actual work happens in Components, which modules are part of.
Should I create a new instance of a module each time I want to inject stuff?
You should create your module when you create the Component it is part of, since only this component is going to need it. If you find yourself creating the same module multiple times, you are most likely doing something wrong.
A module uses additional arguments (pass them in via the constructor) to create more complex objects. So if you were to have e.g. a UserModule you'd pass in the a user to create user dependent objects from the resulting component. If the user changes lose the old component and create a new module and a new component—the old objects should not be used anymore.
Keep the component where / when appropriate and be sure to use Scopes, since they determine the lifetime of your component.
Should I create only one instance of a module? If so where should I do it?
You most likely will just create a single instance of #Singleton annotated Components and Modules. In android you'd most likely keep the reference to the component (not the module!) in the Application or some real 'singleton'.
Is there a more complex example of fragments and activities used with dagger?
Try googling. There are lots of high quality tutorials with linked github repositories that go into much more depth and detail as would be possible here on SO. e.g. see Tasting dagger 2 on android.
I'm thinking about a platform-neutral (i.e. not .NET MEF) technique of implementing chain-of-responsibliity pattern using web services as the handlers. I want to be able to add more CoR handlers by deploying new services and not compiling new CoR code, just change configuration info. It seems the challenge will be managing the metadata about available handlers and ensuring the handlers are conforming to the interface.
My question: any ideas on how I can safely ensure:
1. The web services are implementing the interface
2. The web services are implementing the base class behavior, like calling the successor
Because, in compiled code, I can have type-safety and therefore know that any handlers have derived from the abstract base class that ensures the interface and behavior I want. That seems to be missing in the world of services.
This seems like a valid question, but a rather simple one.
You are still afforded the protection of the typing system, even if you are loading code later, at runtime, that the original code never saw before.
I would think the preferred approach here would be to have something like a properties file with a list of implementers (your chain). Then in the code, you are going to have to have a way to instantiate an instance of each handler at runtime to construct the chain. When you construct the instance, you will have to check its type. In Java, for instance, that would take the form of instanceof (abomination ordinarily, but you get a pass for loading scenarios), or isAssignableFrom. In Objective C, it's conformsToProtocol.
If it doesn't, it can't be used and you can spit an error out to the console.
I am starting to develop a GWT application in MVP style (GWTP) and which uses Spring security for authentication and authorization on server side.
In many views of the application, I have to enable or disable controls with respect to a granted authority of the current user. I already have an RPC service which provides access to a userDetailsDto containing all the necessary information.
Now my question: What is the best place to store the user DTO on client side?
Since the user rights are relevant in many presenters, I would have to pass it around everywhere. Alternatively, I could set an RPC service instance in every presenter and requets the user details each time (probably cached on client-side). But i don't like the idea of having a user RPC service in each presenter just for this purpose.
To be honest, I'd rather would prefer a central registry where to put the UserDetails object and which is accessable from anywhere in my app. Is there already such a registry in GWT?
As in my example, you might often be confronted with horizontally used objects. How to deal with them in GWT?
Simply store your current user in public static variable.
It will be accessible from everywhere.
I inject an "AppState" object into all of the presenters that need to know things like the rights of the user logged in, their preferences, etc. I prefer injection to a public static variable because it feels more controlled, is easier to mock up in tests, and the extra typing forces me to consider whether each object really needs access to the global data.
i was reading Zend Framework Book: Survive the Deep End about resource methods. it speaks about how resource methods will override resource plugin.
But wait, there's also a Resource
Plugin
(Zend_Application_Resource_View) which
may also create a Resource called
View. Can we have two View Resources?
The answer is no - we can have one and
one only
in Zend Framework Manual,
a good way to create re-usable
bootstrap resources and to offload
much of your coding to discrete
classes is to utilize resource plugins
... the intention is that developers
should write their own to encapsulate
their own initialization needs
to me, resource methods seem like a more intuitive way to initialize resources, why then should I use plugins? is it just a question of which do I prefer? or are they used in different circumstances?
will resource methods replace or add to the functionality provided by the provided resource plugins? because if it replaces, I would need to make sure i initialize all variables or whatever I need?
By returning the new Zend_View
instance from _initView(),
Zend_Application will accept the
replacement and will not attempt to
overwrite our changes by running
Zend_Application_Resource_View to set
up a standard default Zend_View
instance with the flaws we just
corrected
if I dont return a Zend_View, it will be as if I didn't have the method? can I say that I should always return something from resource methods?
Here, we do the same thing by using
the getResource() method to retrieve
an instance of Zend_Controller_Front
created and configured by
Zend_Application_Resource_Frontcontroller
from the above, can i say that if i want my resource methods to have the defaults set by the provided resource plugin, i can do a getResource() 1st?
Answering your questions:
Should I use resource plugins or methods?
I would say it's largely down to personal preference. As your quote from the manual says, if you use a resource plugin, it becomes easier to reuse the code in another project (as it's easier to move around/test a class than it is to cut'n'paste text from a method). In my opinion methods make it a little easier to see what's going on in the bootstrap, at least until they start becoming a bit complex, in which case it'd make sense to convert them into a plugin.
Will resource methods replace or add to the functionality provided by resource plugins?
I believe the way it works is that plugins are loaded up and initialised when the bootstrap class is first instantiated. The bootstrap will then go through your methods and run those. If you have a method named the same as a plugin resource, your method will override that plugin. However you can also access the existing resource from your method and modify it, in which case your method is adding to the functionality provided by the plugin.
Remember that plugins don't magically run by themselves (apart from the front controller plugin, which will always run). They will only be used if your application.ini triggers them (or if you call them from your own methods).
If I dont return a Zend_View, it will be as if I didn't have the method? can I say that I should always return something from resource methods?
It is good practice to return something from resource methods as this allows that resource to be accessed by other methods or other parts of the application. However the method will still run without the return value. But if you added an _initView method and setup a new Zend_View object, if you don't do anything with it it won't have any effect on your application.
Can i say that if i want my resource methods to have the defaults set by the provided resource plugin, i can do a getResource()
Yes. But I would make sure you return the resource in this case, just so that any other methods that access the resource are using your modified one rather than the one setup by the plugin.
Personally I would either stick to application.ini + resource plugins, or resource methods. It's easier to see what's going on if all of the resource stuff is in one place.