I rely heavily on TypeBuilderInterface because I build my own types for GraphQL. Not just for enums. So how should I define my own types? Since api platform version 3.1, this interface is deprecated by TypeBuilderEnumInterface that has been added in that PR https://github.com/api-platform/core/pull/5199
I can't just treat my custom types like entities, because entities are handled differently by the api platform than regular GraphQL types, so this deprecation will break like many of my implementations.
I expect TypeBuilderEnumInterface to live alongside TypeBuilderInterface, not instead of it.
Related
How is our app written with GWT 2.8 supposed to make use of the latest Google Maps Javascript API?
We have been using the branflake2267 api but that seems to use a "channel" and "client" instead of an API Key. Is this the correct library to be using?
By the way, I think Google should have done something about this - after all it's their GWT and their Maps API, so why isn't there a library to interface the two?
Thanks,
Ed.
This branflake2267 api module that your mention is quite old and targets GWT 2.5, so it may need some minor mods to work with GWT 2.8.
It may also need some updating to match recent versions of the Maps API.
You can always create your own java bindings to a javascript library using GWT's JsInterop, or update/extend existing bindings such as these ones. It's using the old/deprecated JSNI to make the bindings instead of the newer JsInterop, so you could continue with JSNI or start introducing JsInterop.
By the way, GWT is now a community managed project and has been for many years. GWT now stands for "GWT Web Toolkit" (the recursion is deliberate), not "Google Web Toolkit". JsInterop is provided so that you can interface to any javascript library in java -- there should not be an obligation on Google to provide such an interface to their Maps.
Unity, Autofac and probably quite a few other Dependency injection packages all support "keyed dependency injection containers" that allow to register multiple implementations of an interface and identify them uniquely via a key (be it a string, an int, an enum or whatever else).
However, .NET Core, so far I can see at least, doesn't have such a feature and if I were to try to implement anything like this, I'd have to do a workaround or find some hacky solutions for it. I am wondering, is there a particular reason this has not been introduced in .NET Core?
Unity example:
container.RegisterType<IService, ServiceImplementation1>("1");
container.RegisterType<IService, ServiceImplementation2>("2");
Autofac example:
builder.RegisterType<ServiceImplementation1>().Keyed<IService>("1");
builder.RegisterType<ServiceImplementation2>().Keyed<IService>("2");
...,is there a particular reason this has not been introduced in .NET Core?
Short answer: Yes
Reference Default service container replacement
The built-in service container is designed to serve the needs of the framework and most consumer apps. We recommend using the built-in container unless you need a specific feature that the built-in container doesn't support, such as:
Property injection
Injection based on name (a.k.a keyed)
Child containers
Custom lifetime management
Func support for lazy initialization
Convention-based registration
note: emphasis mine
The Evernote API docs list a number of constants relating to "preferences," a key/value store containing things like shortcuts. However, there do not appear to be any actual methods in the API for accessing or otherwise working with these preferences. Have I overlooked something in the docs, is the full support un(der)documented, or are the constants just useless at this time?
Preferences are used by our first party apps, who have access to the latest versions of our thrift interfaces and docs. The version of our docs online doesn't have the latest methods/documentation.
I have Used FosRestBundle in my project.In the Documentation they used the JmsSerializer.I want know how it could be used.
Check out the JMS Serializer documentation at http://jmsyst.com/libs/serializer
From the introduction:
This library allows you to (de-)serialize data of any complexity.
Currently, it supports XML, JSON, and YAML.
It also provides you with a rich tool-set to adapt the output to your
specific needs.
Built-in features include:
(De-)serialize data of any complexity; circular references are handled gracefully.
Supports many built-in PHP types (such as dates)
Integrates with Doctrine ORM, et. al.
Supports versioning, e.g. for APIs
Configurable via PHP, XML, YAML, or Doctrine Annotations
I'm starting a new personal Prism 4 project. The Reference Implementation currently uses Unity.
I'd like to know if I should use MEF instead, or just keep to Unity.
I know a few discussions have mentioned that these two are different, and they do overlap, but will I be missing out if I simply choose Unity all the way?
Also check out the documentation:
Key Decision: Choosing a Dependency Injection Container
The Prism Library provides two options
for dependency injection containers:
Unity or MEF. Prism is extensible,
thereby allowing other containers to
be used instead with a little bit of
work. Both Unity and MEF provide the
same basic functionality for
dependency injection, even though they
work very differently.
Some of the capabilities provided by both containers include the following:
They both register types with the container.
They both register instances with the container.
They both imperatively create instances of registered types.
They both inject instances of registered types into constructors.
They both inject instances of registered types into properties.
They both have declarative attributes for marking types and dependencies that need to be managed.
They both resolve dependencies in an object graph.
Unity provides several
capabilities that MEF does not:
It resolves concrete types without registration.
It resolves open generics.
It uses interception to capture calls to objects and add additional functionality to the target object.
MEF provides several
capabilities that Unity does not:
It discovers assemblies in a directory.
It uses XAP file download and assembly discovery.
It recomposes properties and collections as new types are discovered.
It automatically exports derived types.
It is deployed with the .NET Framework.
I am currently doing the same investigation. I was last week attending the p&p symposium at Redmond. I had the chance to chat with some of the p&p people on that.
MEF
+Part of .net, no need for extra libraries
+Very powerful in extensibility, modularity scenarios
-More generic approach, less flexible for DI scenarios
-You need to decorate with attributes, your code is glued to MEF
Unity
+Very flexible for DI scenarios
+If you stick with ctor injection and avoid using named instances then you
don't need to use any attributes. Most
of your system doesn't rely on Unity
-No out of the box support for extensibility, modularity scenarios
-Need to deploy the 3rdparty libraries
What I think is a good idea is to use MEF for extensibility (manage the modules of your app, localize registrations) and use Unity for DI.
Well this has to be clear that MEF implements Inversion of control but it is not a part of it, so this means that they are not same, there is a difference, that we use unity when we have static dependency and MEF provides us with dynamic dependency.
MEF also provides us with extensibility, by which we can induce a port type mechanism and can also specigy the type of component which can interact via that port.
more can be understood from: MSDN Document