I am trying to make a taglib to represent an object (to read and display at the UI). When creating an object (save method in the controller), I see the domain class and association are created by the auto assignment of parameter
def Book = new Book(params)
It also maps complex types (for eg: joda time). I wonder about the naming convention necessary to facilitate this mapping. Out of curiosity, can someone also point where in the grails source code I could see how grails handles this mapping. I'm still learning Spring and probably this would be a good exercise.
Thanks,
Babu.
AFAIK the naming conventions are rather straightforward. If there's a field params.foo and the object you are binding to has a field foo, it will bind the value, assuming the type conversion works properly. If there's a params.bar.id set with an Long value and your object has a complex property of type Bar, it will lookup this instance and inject it.
If you need more control over the binding process, you might want to use bindData.
If you are interested into the details of the binding process, have a look at Java's PropertyEditor as this is what is being used in the background. I wrote a blog post on how to create and register PropertyEditors a while ago, maybe it helps you getting started with that stuff.
Related
In my Java 8 Play 2.6 application I have this particular line in a MessageConsumer class that reads a "Rule" record in the DB and sends the JSON message (node) to a specific processor based on the type configured on the rule column. ProcessType is an enum of Sub Classes that all extend from a base (Super class) process.
Play.current().injector().instanceOf(ProcessType.getClass(matchingRule.getProcessType())).processMessage(node, matchingRule);
I'm having trouble figuring out how to refactor this and don't want to add the allowGlobalApplication = true config parameter if I can avoid it.
The most straightforward approach is to inject the Injector into the component that contains this call (the MessageConsumer). This can be done the same way as any other Play component.
You can also inject the Application instance, which would return the same thing as Play.current(). This could be useful if you need more information from the Application object, but if not, injecting the Injector directly would be preferable, as it would create less coupling between the MessageConsumer and other components.
This assumes that the MessageConsumer is created by DI itself. If not, please add more details to the question, including the context code.
Coming from a Rails background, I don’t really understand what transient means in Grails. I read this, http://www.grails.org/doc/1.3.7/ref/Domain%20Classes/transients.html
So as it says
"...In this case it doesn't make sense to persist this property..."
The guide is referring to String getUpperCaseName() { name.toUpperCase() }
I understand that String name will be picked up when trying to save to the database but why will grails bother with a getter method? It is a method to start with..
The reason why it "bothers" with a method is because of bean naming conventions where properties (in Java) are based on setters and getters. The pattern for identifying a "property" (through reflection) based on these are: getXYZ() and setXYZ() where XYZ is the property name in bean format (name becomes Name and fullName becomes FullName).
The reasoning was the fact these methods are public they can be reflected upon and derive properties from, since actual properties were typically private (for many good reasons). I still recall when this came about. (I'm getting too old)
That's why. Java.
It's not a Grails thing. It's a Java thing. You can read more about the JavaBean specification if you want a deeper understanding of the technologies you are using..
I'm currently working on a Rails project, and have found times where it's easiest to do
if object.class == Foo
...
else if object.class == Bar
...
else
...
I started doing this in views where I needed to display different objects in different ways, but have found myself using it in other places now, such as in functions that take objects as arguments. I'm not precisely sure why, but I feel like this is not good practice.
If it's not good practice, why so?
If it's totally fine, when are times that one might want to use this specifically?
Thanks!
Not sure why that works for you at all. When you need to test whether object is instance of class Foo you should use
object.is_a? Foo
But it's not a good practice in Ruby anyway. It'd much better to use polymorphism whenever it's possible. For example, if somewhere in the code you can have object of two different classes and you need to display them differently you can define display method in both classes. After that you can call object.display and object will be displayed using method defined in the corresponding class.
Advantage of that approach is that when you need to add support for the third class or a whole bunch of new classes all you'll need to do is define display method in every one of them. But nothing will change in places where you actually using this method.
It's better to express type specific behavior using subtyping.
Let the objects know how they are displays. Create a method Display() and pass all you need from outside as parameter. Let "Foo" know to display foo and "Bar" know how to display bar.
There are many articles on replacing conditionals with polymorphism.
It’s not a good idea for several reasons. One of them is duck typing – once you start explicitly checking for object class in the code, you can no longer simply pass an instance of a different class that conforms to a similar interface as the original object. This makes proxying, mocking and other common design tricks harder. (The point can be also generalized as breaking encapsulation. It can be argued that the object’s class is an implementation detail that you as a consumer should not be interested in. Broken encapsulation ≈ tight coupling ≈ pain.)
Another reason is extensibility. When you have a giant switch over the object type and want to add one more case, you have to alter the switch code. If this code is embedded in a library, for example, the library users can’t simply extend the library’s behaviour without altering the library code. Ideally all behaviour of an object should be a part of the object itself, so that you can add new behaviour just by adding more object types.
If you need to display different objects in a different way, can’t you simply make the drawing code a part of the object?
This is a word of warning more than a question, if you are using RIAServices with Custom ValidatorAttributes.
Here is the Senario, I was creating a custom DataAnnotation that would validate a property based on whether or not a possible series of other properties had been set, such as; if Prop1 was 100 then Prop2, Prop3, or Prop4 could not be 0 one of them had to be set. I am also using RIA Services so I created the ValidatorAttribute my .shared.cs file. After writing all the tests for the helper CannotBeZeroIf class, I began to add the attributes to the Model Class. This is of course when thing started to go very wrong. RIA Services began to throw up during the CodeGen, with a NullReferenceException.
CreateRiaClientFilesTask -> NullReferenceException
It turns out to be linked to the fact that I was using the validator's constructor to pass in the values to the class. By switching to using ObjectInitialization syntax, everything was fixed.
The Answer appears to be use ObjectInitializer syntax when dealing with RIA Services and Custom DataAnnotation Validators.
The Answer appears to be use ObjectInitializer syntax when dealing with RIA Services and Custom DataAnnotation Validators (that was easier than I thought! ;-)
This is pretty much a duplicate question but instead of using Castle Dynamic Proxy I'm using LinFu Getting underlying type of a proxy object
I'm using automapper to create proxies of interfaces that I'm sending to my viewmodel in Asp.net MVC. My problem is from what I can tell that MVC's default MetadataProvider find the properties and metadata by calling .GetType() on the model.
So what happens is EditorFor() and DisplayFor() templates don't generate any fields. What I need to do is find the proxy target type and then generate my templates. I know I can just parse the name and use GetType( "thename" ) but was wondering if there was an easy way.
LinFu.DynamicProxy doesn't directly expose the underlying object of a proxy. It simply redirects each method call to an IInterceptor implementation instance. In order to access the underlying object, you'll have to figure out whether or not the current interceptor instance actually has a target class instance, or not.
If you're working with AutoMapper, AFAIK, they use LinFu.DynamicObject to do a lot of the duck taping, and calling GetType() on a dynamic type generated by LinFu.DynamicObject won't even get you the actual type in your domain model--it will just get you an object that has been literally duck-taped together by LinFu itself.
get latest AutoMapper - it uses Castle Dynamic Proxy, and you already know how to get this from there :)