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.
Related
In OWL API, there method getObjectPropertiesInSignature() can be used to obtain the set of object properties in an ontology. I have two questions with respect to this:
By using this method, will it return also the object properties in imported ontology ?
Also, this method is deprecated in the latest version of OWL API, is there another method with the same behaviour ?
getObjectPropertiesInSignature() has an overloaded version with a boolean flag, its purpose is to allow you to choose to look in the signature of the ontology or in the signature of the imports closure. Use it to get the object properties for the whole imports closure.
The method is deprecated and the javadoc suggests using the stream based method. For all such scenarios in OWLAPI 5, methods named getXxx() have an alternative version named xxx() that returns a stream. It is preferable to use them if you need only one iteration through the underlying collection (it saves having to make defensive copies). If you need multiple iterations or lookups, you can keep using the deprecated methods or collect the data from the stream in a set.
I have the Ecore model which has the attribute ID.Now in the Sirius we can set the attribute values through the set operation by specifying the feature name of the attribute and the value Expression in the Sirius design.Now the problem is,i want to set the attribute value id so i want to use the methods given by java to create random numbers so how can i call that method in the value expression such that the feature name has the value of the method return type.
The Set operation in Sirius uses an expression to get the value to set. The expressions can be written in a variety of query languages. Most support calling back to so-called "Java services", which are plain Java methods which must conform to a few rules. See the corresponding documentation section for details.
Basically for your case you need to:
Write a small Java class which exposes the "random number generation" code you want to call in a way that Sirius can invoke as a service.
Register the corresponding class in your VSM (this is described in the documentation).
Finally, invoke the service from the expression in your Set Value operation, with something like service:getRandomId.
The advanced Sirius tutorial also has a section at the end about using Java services which may be usefull.
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.
I've been trying to find some info on difference between instantiating form fields through static method and the new keyword. Can somebody tell me what are the practical implications, limitations, between new MyFormField and MyFormField::create() esp. with regards to SilverStripe
Using the create factory method would check for overloads (set via Object::useCustomClass()) and return an instance of the custom class in that case.
This method first for strong class overloads (singletons & DB
interaction), then custom class overloads. If an overload is found, an
instance of this is returned rather than the original class. To
overload a class, use Object::useCustomClass()
So using the create method rather than instantiating the Object yourself would provide a possibility to overload the used Class without altering the code.
see
http://api.silverstripe.org/3.1/class-Object.html#_useCustomClass
http://api.silverstripe.org/3.1/class-Object.html#_create
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.