I have a main Silverilght project and other modules and I'm using Prism to glue them together along with Unity for Dependency Injection.
I have one of my modules that depends on an IRegionManager which, naturally, gets injected to it by Unity.
The issue I'm running to is that, the Regions property of the RegionManager that I get doesn't contain any regions even though I have declared two of them in my Shell as follows:
regions:RegionManager.RegionName="MainRegion"
I can't figure out the reason of this behavior. I've tried registering a RegionManager as a singleton using
Container.RegisterInstance<IRegionManager>(new RegionManager());
as well as leaving unity handle this. However, I got the same results :(
what I'm trying to achieve is to inject a view into a particular region and activate it, which can't be done using
_regionManager.RegisterViewWithRegion("MainRegion", typeof(MyView));
that's why I need to get hold of the "MainRegion" object itself and manipulate it.
I hope somebody has this figured out. I would be very thankful :)
Edit:
I should mention that the view discovery works just fine, I can RegisterViewWithRegion, but when I check the Regions property of the RegionManager, I find it empty!
while thinking about this problem and the context in which it happened, it striked me that, like most bugs in software, the problem wasn't where I was looking!
My setup was as follows: I started out with the Silverlight Business Application project template. this gave me a MainPage which I used as my Shell, and a couple of views(Home and About). Now, instead of having the regions sit on my Shell, I put them in the Home view, keeping the MainPage as kind of a master page.
My take on this is that Prism sets a RegionManager for the Shell, and passes it around to whoever needs it (using a Dependency Injection Container). This way, when I asked for an IRegionManager in my module, I got the one for my Shell which doesn't really contain any region (hence the empty Regions property).
To solve this, all I had to do was put my regions in their rightfull place: the Shell, and all is working well (for) now.
Update:
Seems like my "take on this" is actually correct :), this is an excerpt from the Prism Documentation: (under Scoped Regions)
Views defining regions with attached properties automatically inherit their parent's RegionManager. Usually, this is the global RegionManager that is registered in the shell window
Related
This question is likely a particular XAML application. XAML is a custom markup to instantiate objects and, as such, define custom applications. Note that, it serves to both declare WPF user interfaces and WWF workflows. It would also help to specify, e.g., a custom source-code change detection solution. To avoid getting in deeper in unnecessary details. I need to design a custom XAML-based model that, like the one for WPF and the one for WWF do, allows me to declare a custom application on top of XAML, without having to create a WPF or WWF project. Is this sort of third-part XAML-like provider possible to build?
<Approach>
<PrimitiveExample
OriginalType={Type syntax:LiteralSyntax}
ModifiedType={Type syntax:LiteralSyntax}
Propagation.Matched={Binding MatchedPropagationCommand}>
...
</PrimitiveExample>
...
<Approach/>
Let us see it this way. Is there a way to get a stand-alone XAML file that works as follows?
a) There will be a project item, e.g., named "Stand-alone XAML".
b) I create a new "Stand-alone XAML" item named, e.g., "Solution.sccd", and I add it to a console application, class library, or many other projects. This because it will be a sort of smart .config.
c) I can set up a root instance in "Solution.sccd" (likely containing a lot of nested instances) - this is natural for XAML.
d) When declaring instances in "Solution.sccd", I can use features like attached properties, binding, and many other smart features or markup extensions that can be used with WPF or WWF, but this will not be a WPF or WWF project.
e) I can instantiate the declared root instance, e.g., with simple code line like "var rootObject = XAMLInstanceCreator.Create(Solution.sccd)", and use that object.
Does this make sense now?
Regards, Guillermo.
I've been trying to get Connections to use a customised adapter located at app/extensions/data/source/database/adapter/. I thought extending the Connections class and replacing
protected static $_adapters = 'data.source';
with
protected static $_adapters = 'adapter.extension.data.source';
and changing the connections class used at the top of app/config/bootstrap/connections.php to use app\extensions\data\Connections;
would be enough to get it started. However this just leads to a load of errors where the code is still trying to use the original Connections class.
Is there a simple way to achieve this, or do I have to recreate the entire set of classes from lithium/data in extensions with rewritten class references?
EDIT:
Turns out I was going about this the wrong way. After following Nate Abele's advice, Libraries::path('adapter') showed me where to correctly place the MySql.php file I'm trying to override ;-)
For dealing with how named classes (i.e. services, in the abstract) are located, you want to take a look at the Libraries class, specifically the paths() method, which allows you to define how class paths are looked up.
You can also look at the associated definitions, like locate() and $_paths, to give you an idea of what the default configuration looks like.
Finally, note that the Connections class is 'special' since it defines one path dynamically, based on the supplied configuration: http://li3.me/docs/api/lithium/1.0.x/lithium/data/Connections::_class()
This should help you reconfigure how your classes are organized without extending/overriding anything. Generally you shouldn't need to do that unless you need some drastically different behavior.
I am using Ninject in substitution of MEF and I was wondering if it's possible to get lazy instances via standard kernel methods and not via [inject] .
I need this since when building up my application's menu I have to pass all particular view models and then if the user is enabled on that function to add it to the menu
Thanks
Sure thing, you can inject a Lazy<T> and the value will only be instanciated when you access Lazy<T>.Value.
You can also inject a Func<T> and use it to create T whenever you like (with the func, every call creates a new instance).
Of course you can also do IResolutionRoot.Get<Lazy<T>>() or IResolutionRoot.Get<Func<T>>(), but usually that's a sign of bad design (service locator), so use constructor injection when it's feasible.
EDIT: When is the "enabling of the user" happening? Is it a one time thing? What is being displayed before and after?
There might be other/better designs to achieve this but it's hard to say with that little information.
I have been playing around the last couple of days with different solutions for mapping DTO's to entities for a VS2013, EF6, WCF Service App project.
It is a fairly large project that is currently undergoing a major refactoring to bring the legacy code under test (as well as port the ORM from OpenAccess to EF6).
To be honest I had never used AutoMapper before but what I saw I really liked so I set out to test it out in a demo app and to be honest I am a bit ashamed that I have been unable to achieve a working solution after hours of tinkering and Googling. Here is a breakdown of the project:
WCF Service Application template based project (.svc file w/code behind).
Using Unity 3.x for my IoC container and thus creating my own ServiceHostFactory inheriting from UnityServiceHostFactory.
Using current AutoMapper nuget package.
DTO's and DAL are in two separate libraries as expected, both of which are referenced by the service app project.
My goal is simple (I think): Wire up and create all of my maps in my composition root and inject the necessary objects (using my DI container) into the class that has domain knowledge of the DTO's and a reference to my DAL library. Anyone that needs a transformation would therefore only need to reference the transformation library.
The problem: Well, there are a couple of them...
1) I cannot find a working example of AutoMapper in Unity anywhere. The code snippet that is referenced many times across the web for registering AutoMapper in Unity (see below) references a Configuration class that doesn't seem to exist anymore and I cannot find any documentation on its deprecation:
container.RegisterType<AutoMapper.Configuration, AutoMapper.Configuration>(new PerThreadLifetimeManager(), new InjectionConstructor(typeof(ITypeMapFactory),
AutoMapper.Mappers.MapperRegistry.AllMappers())).RegisterType<ITypeMapFactory,
TypeMapFactoy>().RegisterType<IConfiguration, AutoMapper.Configuration>().RegisterType<IConfigurationProvider,
AutoMapper.Configuration>().RegisterType<IMappingEngine, MappingEngine>();
2) Where to create the maps themselves... I would assuming that I could perform this operation right in my ServiceHostFactory but is that the correct place? There is a Bootstrapper project out there but I have not gone down that road (yet) and would like to avoid it if possible.
3) Other than the obviously necessary reference to AutoMapper in the DTO lib, what would I be injecting into the instantition, the configuration object (assuming IConfiguration or IConfigurationProvider) and which class I am injecting into the constructor of the WCF service to gain access to the necessary object.
I know #3 is a little vague but since I cannot get AutoMapper bound in my Unity container, I cannot test/trial/error to figure out the other issues.
Any pointers would be greatly appreciated.
UPDATE
So I now have a working solution that is testing correctly but would still like to get confirmation that I am following any established best practices.
First off, the Unity container registration for AutoMapper (as of 11/13/2013) v3.x looks like this:
container
.RegisterType<ConfigurationStore, ConfigurationStore>
(
new ContainerControlledLifetimeManager()
, new InjectionConstructor(typeof(ITypeMapFactory)
, MapperRegistry.AllMappers())
)
.RegisterType<IConfigurationProvider, ConfigurationStore>()
.RegisterType<IConfiguration, ConfigurationStore>()
.RegisterType<IMappingEngine, MappingEngine>()
.RegisterType<ITypeMapFactory, TypeMapFactory>();
Right after all of my container registrations, I created and am calling a RegisterMaps() method inside of ConfigureContainer(). I created a test mapping that does both an auto mapping for like named properties as well as a custom mapping. I did this in my demo app for two reasons primarily:
I don't yet know AutoMapper in a WCF app hosted in IIS and injected with Unity well enough to fully understand its behavior. I do not seem to have to inject any kind of configuration object into my library that does the transformations and I am still reading through the source to understand its implementation.
As I understand it, there is a caching mechanism at play here and that if a mapping is not found in cache that it will create it on the fly. While this is great in theory, the only way I could then test my mappings that were occurring in my composition root was to do some sort of custom mapping and then call Mapper.Map in the library that performs mapping and returns the DTO.
All of that blathering aside, here is what I was able to accomplish.
WCF Service App (composition root) injects all of the necessary objects including my DtoConversionMapper instance.
The project is made up of the WCF Service App (comp root), DtoLib, DalLib, ContractsLib (interfaces).
In my ServiceFactoryHost I am able to create mappings, including custom mappings (i.e. map unlike named properties between my DTO and EF 6 entity).
The DtoConversionMapper class lives in the DtoLib library and looks like this: IExampleDto GetExampleDto(ExampleEntity entity);
Any library with a reference to the DtoLib can convert back and forth, including the Service App where the vast majority of these calls will take place.
Any guiding advice would be greatly appreciated but I do have a working demo now that I can test things out with while I work through this large refactoring.
Final Update
I changed the demo project just a little by adding another library (MappingLib) and moved all of my DTO conversions and mappings to it in a static method. While I still call the static method in my composition root after the Unity container is initialized, this gives me the added flexibility of being able to call that same map creation method in my NUnit unit test libraries, effectively eliminating any duplication of code surrounding auto mapper and makes it very testable.
Here's what I know so far:
DI lets me build reusable, unit-testable components
DI is verbose because it requires that I explicitly set the dependencies (via constructor or method. I still don't understand the interface injection though). This is why a container or a service locator is needed.
Container is better than service locator because classes won't need to be aware of the existence of it.
But I found these problems:
Some classes will now depend from Container? If I don't use the default config for every class, as described in my services file, some classes will need to call the container to re-configure the needed object.
On page 79 from this slide http://www.slideshare.net/fabpot/dependency-injection-with-php-53, Fabien Potencier said that a Container does not manage all the objects, only those with a single instance (yet not singletons). I'm even more confused now.
Any help is greatly appreciated. =)
Some classes will now depend from Container?
No. That's why you use dependency injection as opposed to service location.
On page 79 from this slide...
See page 82, it says "Unlike model objects". Honestly I'd never explain it like that ("Objects with only one instance (!= Singletons)" is either wrong or something very PHP specific, it doesn't apply to dependency injection or IoC+DI containers in general), but I bet what he was trying to explain is that the container usually manages service-like things, not model-like things.