Situation: I am currently moving from using Struts 1 to Struts 2. In Struts 1, it was necessary for form classes to follow the JavaBean specification. Since my business data objects are all immutable, this required creating a JavaBean version of many classes, and methods mapping between the two.
Does Struts2 support using immutable objects for forms?
If so, how do I configure it such that the immutable object is instantiated from its builder using the form fields?
The object being populated from the request can't be immutable, because OGNL calls setters on it–that's just how OGNL (and most ELs) work.
I figure you have two options: you could either do something with a custom parameters interceptor, or create a constructor or builder that takes a bean used for the form.
Without any real thought, I'd probably do the latter, although I might create a quick tool to generate the form classes if there are a lot of them. An interceptor would be more elegant, but it'd probably need to use reflection.
Related
When would be the bean tag used in struts.xml configuration file using Struts 2? What is difference between action class properties and bean tag in Struts 2 configuration file struts.xml?
Some places have strict separation of work or for what ever reason you can edit the view (JSP) but not the actions source.
In this case the bean tag becomes most useful (otherwise I agree it isn't particularly attractive). It is generally easiest to produce what is needed for the view within the action and also process that data such that it is readily displayable. As such there is not generally much need for append, generator, merge tags either... but once again if you consider the content people separate from the backend people these tags would be used more often.
In theory it is possible to use the bean tag to access things like singletons for counters and such, but if the view is acquiring resources in this way it is kind of a component way of thinking(as opposed to action based thinking). This is also why the action tag's use isn't particularly favored either. If you need it, the action class should be the main one responsible for getting it (or interceptors, but certainly not the view) at least following action based thinking.
I was going through differences of Struts1 vs Struts2, and came across this point:
Struts 1 Actions are singletons and must be thread-safe since there will only be one instance of a class to handle all requests for that Action.
Struts 2 Action objects are instantiated for each request, so there are no thread-safety issues.
Now my question is: in Struts2, why there are no singleton concept for Action class? As I think because, unnecessarily, there is more Object creation for every request.
Please correct me if I am wrong.
Object creation is ridiculously fast in Java. Programming thread-safe action classes (and servlets, etc.) is irritating and error-prone.
Like with everything, there's a trade-off.
New instance in the sense, its not creating new object but jvm will create instance of that object hence there is no matter that how many request is comming for a particular object...even if the instance is more, the applcation will not hang...
I have a number of interfaces I use to pass business objects around in my application. Using Ninject, I can do whatever I want with them without needing to know the type of the actual object; in this case, most of them are actually various Linq to Sql objects that implement the interface.
For example, I have a Linq to Sql object called Listing that implements IListing.
Where I've run into a problem is with serialization. I've tried using the built in JsonResult and JsonNet. Both of them attempt to serialize the actual Linq to Sql object, not just the properties defined in the interface type. This leads to circular reference issues, but the larger problem is that I only want the properties defined in the interface being serialized and passed around.
So, is there an elegant way to serialize just the properties defined in an instance of an interface that I pass to a serializer?
You could define a new transport type containing only the properties you need and then use AutoMapper to convert between your domain object to this type which will be used for serialization.
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! ;-)
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.