This question already has an answer here:
Migration error handling to Struts2
(1 answer)
Closed 2 years ago.
I am trying to update my code from Struts1 to Struts 2 but facing difficulty to update the below code can any one please suggest the replacement for below code.
final ActionMessages errors=new ActionMessages();
errors.add("Error Global", new ActionMessage("some_string_in_properties_file"));
sorterrormessage(errors);
Extending ActionSupport provides the addActionMessage method. It also provides getActionMessages and setActionMessages (Collection<String>) which would allow sorting them. 1
The tag library provides <s:actionmessage />, when combined with hasActionMessages allows checking for, and displaying, the action messages.
To use a property file use an appropriate getText() implementation in the action.
It would be good to know what difficulties you're actually facing as this is searchable on the web and it's in the S2 docs. A cursory examination of the functionality in ActionSupport would probably be a good idea.
1 Sorting messages is only rarely the right thing to do except under very particular circumstances, or if it's explicitly not an alphabetical sort.
Related
I want to be sure I am not going to cause a performance issue with this. We are writing a simple Money DSL and I was advised to turn on:
ExpandoMetaClass.enableGlobally()
However, I cannot determine yet exactly what this means. Does it only enable metaclass overrides on the inheritance tree for the root object, or does it apply it to every object type in memory?
Are there risks to applying Expando globally to a production instance?
Grails does this already, so whatever cost is involved is already incurred :)
This setting changes the default MetaClass implementation from MetaClassImpl to ExpandoMetaClass. ExpandoMetaClass was written by Graeme for Grails to make it easier to dynamically add methods to the metaclass, e.g.
String.metaClass.bark = { -> println "WOOF!" }
and it was added to Groovy core years ago.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions concerning problems with code you've written must describe the specific problem — and include valid code to reproduce it — in the question itself. See SSCCE.org for guidance.
Closed 9 years ago.
Improve this question
I have one repository that internally (on some methods) will need to use another repository.
I am trying to put all dependencies on the constructor, passing interfaces as arguments. However I don't know how to deal with this specific scenario.
Should I pass also this repository as an argument? Even though I will not use it on every method inside?
Thanks
You don't have any problem for making a repository depend on another repository. And, yes, pass it as a parameter
I'm assuming you're making dependency injection, specifically constructor injection.
Instancing an extra repository, which some times won't be used (because not all method use it) it's not such a terrible overhead that makes you to avoid it. If it was a more expensive resource (like opening a file or DB connection) you could use some alternative technique. For example expose the second repository in a property with a backing field which is populated in the first call to the property getter using service location, i.e. finding it directly in your container, or an smarter solution, provided but some of the DI frameworks, which does this kind of thing automatically, like Unity's Lazy and similar solutions.
But I insist, in this case, the overhead doesn't justify it.
NOTE: you could also use the property or Lazy technique if you had a dependency loop (circular dependency), to break the loop and make it work. However, int this case, it's much better to refactor your classes, (extracting a thrid class) to avoid the circular references. This is not your case.
I would probably make a service layer on top of the repositories. Inject both repositories into the service layer.
public LibraryCatalogueService {
IBookRepository _books;
IAuthorsRepository _authors;
public LibraryCatalogueService (IBookRepository books, IAuthorRepository authors)
{
_books = books;
_authors = authors;
}
public List<BookWithAuthor> GetBooksWithAuthors()
{
//do stuff to get books and get authors and then join them.
//return the list
}
}
I wish to replace the implementation of System.Web.Mvc.ActionMethodSelector as used by the FindAction method of ReflectedControllerDescriptor, but would like to take advantage of the existing implementation, ideally by deriving from ActionMethodSelector. However, because the class is marked as internal the only way I can see to do this 'properly' is to derive from ReflectedControllerDescriptor and implement FindAction by copying the code from ActionMethodSelector. I wish to avoid this however due to the quantity of code, and potential issues trying to keep it up to date with the framework.
I'm considering the following approaches:
Biting the bullet and copying the code
Using reflection so as to take advantage of the existing implementation
Are there any other approaches that I'm missing, better or otherwise?
I know it is a bit late to answer still I am giving it a try.... :)
I believe that you somehow want to tweak action method selection process in ASP.NET MVC. If my understanding is correct you can make use of custom ActionMethodSelectorAttribute by deriving from System.Web.Mvc.ActionMethodSelectorAttribute. Write your own custom logic in the custom selector and apply it on the top of the action methods. I believe in this way the action method selection process can be tweaked without disturbing the natural process.
If you wish you can visit these links: http://programersnotebook.blogspot.in/2014/02/aspnet-mvc-actionnameselector-and.html, http://programersnotebook.blogspot.in/2014/02/aspnet-mvc-actionnameselector-and_2.html
I am a beginner to Struts2. Please tell me why to extend ActionSupport class? (When one doesn't have the requirement of validation or internationalization)
Are there any other benefits provided by extending ActionSupport class?
Convenience and access to basic, common functionality.
It has default implementations of common methods (e.g., execute(), input()), gives access to Action.SUCCESS and other result names, etc.
Note that the I18N functionality goes a bit beyond simple translation, but includes some formatting, allows non-programmers to provide labels/texts, and so on.
There's rarely (ever?) a good reason not to extend it. Even REST plugin actions, e.g., those that handle JSON endpoints, often use validation and I18N support.
IF you don't want to use out of the box features provided by the struts2 you can always avoid using ActionSupport class
This is basically a helper class which provides many out of the box features for you, but at same time Struts2 framework do not ask to use this class, all it want is an entry method for your action class with return type as String and which can throw a general Exception
beside validation or Internationalization this class also provides many other features like Action level Errors etc.
Follow the documentation for detail
ActionSupport
I'm reading Struts 2 In Action, and, on the chapter five, a conversion.properties file is created to demonstrate data transfer for multivalued parameters. It includes this line:
Element_weights=java.lang.Double
And there's a list that does not use generics in the Action class:
List weights;
I replaced all this with just
List<Double> weights;
and the type conversion seemed to work just fine. Are there any drawbacks to using generics, any reason for what the authors of the book are doing?
edit: I kept reading and, in fact, generics work, and the authors even recommend it. Why they haven't used it in the first place still puzzles me, nevertheless.
Those types of conversion entries are only needed in pre-generics environments. Definitely use generics if at all possible.