We're updating code to use Autofac. We'd like to use custom delegate types to define factories instead of Func's. But we also use an obfuscator, which renames parameters. We'd like to tell the Autofac container to match by type instead of name as it does with Func's. Is this possible?
On the official documentation of Autofac, you have this information
By default, Autofac matches the parameters of the delegate to the parameters of the constructor by name. If you use the generic Func types, Autofac will switch to matching parameters by type.
http://docs.autofac.org/en/latest/advanced/delegate-factories.html
Could you customize the obfuscator to use the same name for the parameter name of the delegate and the constructor?
As mentioned, the way to do it right now is to use Func. Even if it were possible with just delegate factories, Autofac won't know what to do when there are two parameters of the same type. Here's my answer to a very similar question.
Thanks guys. We ended up creating a custom registration source using Autofac's source as a guide. In our testing, if there are two parameters of the same type, it appears to fall back to order.
Related
How can I pass parameter to constructor of Native code in Codename one?
I could only see NativeLookup.create method which takes no parameter. The requirement is to create native object based on parameter (like port number or url).
NativeCode nativeCode = (NativeCode) NativeLookup.create(NativeCode.class);
It would be even great if there is any way to get instance from a factory method which takes parameter. Thanks in advance.
You can't and you don't need to!
The native interface is a simple interface. If you have an object that needs a constructor argument just create it within the native object methods. Keep in mind that passing an argument to a constructor might work well for Android but when you want to do the same thing in iOS's Objective-C etc. this might not make sense.
I was reading about Builder pattern and as usual I got confused with Factory pattern.
I have seen a good article which shows the difference between Abstract Factory and Builder pattern.
http://champika-nirosh.blogspot.in/2008/04/what-is-difference-between-abstract.html
But my confusion is that, more than Builder pattern similar to Abstract Factory I feel like it is similar to Factory Method pattern. Not sure my understanding is correct. But in Factory Method also we are using a separate factory (Method in Concrete Factory) to create one particular object (not a family of product). In that scenario how Builder differs from Factory Method pattern. I knew that Builder requires more steps to create object, other than that is there any particular scenario we need to use one over another? Please guide me.
Thanks.
Your particular usage case will affect which (if either) you might choose. But to essentially reiterate what's on the link you reference:
Both abstract factory and factory method are creating instances of unknown types. Generally these will be returning a class that corresponds to an interface, but you don't know (and shouldn't care) what the concrete type will be. To use the picture from that link, it's using a WindowsFactory, meaning the abstract factory is returning an instance that is compatible with Windows. If your factory were instead a LinuxFactory, you might get an object back that works on Linux. Note, also, that you probably wouldn't know if you had a LinuxFactory or WindowsFactory, just that you had a Factory of a particular type.
So the abstract factory & factory method patterns are about building polymorphic types (including when you don't know or care what the concrete type will be). However, the call to get an instance of the type is usually trivial. To build from a factory you're probably just calling:
MyInterfaceType myInstance = myFactory.getTheItemOfMyInterfaceType();
The builder pattern is more about building complex objects that may or may not be (but probably are) of a known type. In this case you'd expect a complex series of calls to construct the type, often setting one parameter after another. Because there's a lot of known parameters and arguments, you generally know what type of object you're going to get back from it (don't have to, but it's more likely than with an abstract factory). Builder is used when constructing the object is complex, but not necessarily polymorphic (it might be polymorphic, but that's not the premise of the pattern). A builder call to construct something might be (see Android AlertDialog for some real examples):
Builder b = new Builder();
b.setSomeValueA(myChoiceForA);
b.setSomeValueB(myChoiceForB);
MyInterfaceType myInstance = b.build();
Hope that helps.
I get a instance for all controllers by calling getController on the application instance which seems not to use the alias. But I found examples where the alias is set on some where it isn't set.
So is it recommend to define a alias for my controllers or can/should I spare this property?
Well you should be able to answer this question yourself...
Based on the structure of a MVC project in ExtJS and the way controller get invoked you should never need a alias and the getController() method doesn't use one. So you can spare these lines.
But if you like it you can define one, I don't think that there is any recommendation that can be given for pro and con beneath that you don't need it.
I'm using HtmlPage.RegisterCreateableType method to call some C# code from javascript. In MSDN documentation they say:
Registers a managed type as available for creation from JavaScript
code, through the Content.services.createObject and
Content.services.createManagedObject helper methods
There isn't more explanation about these two methods and I don't know what are the differences. Anybody knows differences between these methods?
Tons of information on both of these methods here.
createObject
Description: Given a registered scriptAlias, this method returns a
script wrapper for the corresponding managed type.
createManagedObject
Description: Given the typeName of the target .NET Framework type,
this method creates a default instance of the type by using either a
parameterless constructor (for reference types) or the default value
representation (for value types).
Basically, you use createObject if you have a script alias to an object. If you just need to create an instance of a type of object you use createManagedObject.
I have a report which uses a custom assembly for purposes of localization/globalization.
I am creating my translation object (I'll call it "dictionary") and initializing a Dictionary property of this object in the custom code OnInit() override.
Everything works fine in report body, but when I try to reference the object I describe above in either the Report Header or Report Footer- it is not accessible (object ref is not set to instance of obj error..).
Can anyone either tell me why this is or how I might be able to workaround it? I really don't want to have to re-initialize this localization object separately for the Header and Footer. I was under the impression custom code class instances were accessible anywhere within the report definition.
Thanks in advance for any light anyone can shed on this.
I am not sure of your implementation, but the recommendation is to use static methods rather than instances. Understood that this is not always the best case for each design, but in your case, it sounds like you could use a static method and then in that case, when called from your header and footer, the custom assembly static method will initialize all data. It will be easier that putting the implementation or instance creation in the RDL.
This appears to just be by design. A custom class instance is not accessible to the Report Header or Footer. My solution was to simply add a check to the custom code function which the report expressions call (psuedo-code):
If IsNothing(myCustObj)
{
///initialize myCustObj
}
That seems to be the best workaround.