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.
Related
With Grails, in UrlMappings.groovy, it seems I can specify the controller and action:
"/someURL" (controller: "Some", action: "someAction")
Or I can specify the view:
"/someURL" (view: "someView")
But I can't specify the controller, action, and view:
"/someURL" (controller: "Some", action: "someAction", view: "someView")
Instead, I have to specify the view in the controller. Is there a way to specify the view in the UrlMappings.groovy? Or is it just not possible?
To do this, you would first need to know that Grails uses Spring Web under the hood. Spring Web is the most complex web framework I can think of (capable of doing anything AFAIK). At any rate, the important thing to know is how Spring Web's Request Life Cycle works. You can get a feel for it by reading the documentation of the "DispatcherServlet" which is the main Servlet in Spring Web (and consequently in Grails):
http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/web/servlet/DispatcherServlet.html
Here is a great article from the grails team about how grails is really just spring:
http://spring.io/blog/2010/06/08/spring-the-foundation-for-grails/
The important part relevant to this question are these two lines from that documentation:
Its view resolution strategy can be specified via a ViewResolver implementation, resolving symbolic view names into View objects. Default is InternalResourceViewResolver. ViewResolver objects can be added as beans in the application context, overriding the default ViewResolver. ViewResolvers can be given any bean name (they are tested by type).
If a View or view name is not supplied by the user, then the configured RequestToViewNameTranslator will translate the current request into a view name. The corresponding bean name is "viewNameTranslator"; the default is DefaultRequestToViewNameTranslator.
What you really want to do is create a customized ViewResolver or RequestToViewNameTranslator. The world is quite complex - if a View is supplied by the user in the Grails Controller explicitly, then you would want a ViewResolver. If instead a Map is returned (or some other custom object), then you want a RequestToViewNameTranslator.
Don't forget that grails has customized these two things already, to use the whole "convention over configuration" idea. So, you have to be careful in how you implement yours - I would recommend looking at the grails default implementations of these things.
Source for the GrailsViewResolver is here:
https://github.com/grails/grails-core/blob/master/grails-web/src/main/groovy/org/codehaus/groovy/grails/web/servlet/view/GrailsViewResolver.java
Now, the real fun begins. The grails team didn't just provide custom implementations of spring web's default life cycle, they completely customized the dispatcher servlet as well. This means you need to be aware of how their universe differs from the spring universe (thus rendering many helpful spring forum questions irrelevant). Here is a link to the GrailsDispatcherServlet source code:
https://github.com/grails/grails-core/blob/master/grails-web/src/main/groovy/org/codehaus/groovy/grails/web/servlet/GrailsDispatcherServlet.java
So if you managed to read this far, you can probably envision how to write a customized view resolver to return the view you want, but how to get access to the URL Mappings configuration data, so you can define views in there (however you see fit). The UrlMappings file relates to a spring bean, which will be available to autowire using the property "grailsUrlMappingsHolderBean" - see http://grails.org/doc/2.3.4/ref/Plug-ins/URL%20mappings.html
From that bean, you can access UrlMappings object, which you can get access to all UrlMapping definitions. See:
https://github.com/grails/grails-core/blob/master/grails-web/src/main/groovy/org/codehaus/groovy/grails/web/mapping/UrlMappings.java
https://github.com/grails/grails-core/blob/master/grails-web/src/main/groovy/org/codehaus/groovy/grails/web/mapping/UrlMapping.java
I'm not entirely convinced whether you can just throw anything in there, but since it's groovy I'd think you can. If not, you would have at least 2 options:
Create a new config file for just controller/view mappings your custom view/viewname resolver would use
Customize the URLMappings based on the grails source to interpret your custom configuration
A little off topic, here is an interesting article about removing the default mappings file and home-rolling your own:
http://mrhaki.blogspot.com/2011/12/grails-goodness-customize-url-format.html
Again, I found several posts online where people went down this path, and it ended up being too hard because of the numerous configuration pieces need to make it function. Thus, I highly recommend against it. To a certain degree, I agree with the response on this page (which is what you will see alot trying to do something out of the grails universe):
Bypassing grails view resolvers?
I need to use Struts2 <s:if> Tag to evaluate a function return value from different JSP pages.
The function is implemented inside a Class, and I want to use it in different JSP pages
Example:
<s:if test="%isLogin()==true">dosomething</s:if>
<s:if test="%{isLogin()}">dosomething</s:if>
Or better yet:
<s:if test="%{loggedIn}">doSomething</s:if>
Naming matters.
Don't fight the framework and Know your libraries.
Stop a minute and learn how it works. Then you will probably have no need to change its behavior anymore, but if you will, you will know how to do it in the right way.
If something is common to a lot of Action / JSP AND it is VIEW stuff (like providing data that must be drawn on every page), then put it in a BaseAction and extend it from the other actions.
If something is common to a lot of Action / JSP AND it is BUSINESS stuff (like checking if the user is logged in or not), do it serverside, with an an Interceptor.
Never put logic in JSP, the JSP must not even be reached in that cases.
Some useful readings are:
Introducing Interceptors
Interceptors
OGNL
OGNL Language guide
But I suggest a deep dive in the whole Struts2 documentation... you will get better code and will save a lot of time after few days...
Is it possible to assign the value to the bean property by implementing ModelDriven interface but having different name in request and bean
for eg Ajax request
DemoStruts.Action?param_a=649
the value of param_a parameter must set to the property paramAR in the bean. For doing this is there any xml configuration or annotation to specify this mapping
The normal mechanism is the alias interceptor, although I haven't used it for deep aliasing.
There are some pretty hideous games you can play with this technique. I've never been entirely sure if it's a good idea or not, though; another option is to just map parameters manually in the action itself. This is often easier to understand.
I want to output a value which is global in all the templates or even layout in Grails, like Django's context processor where you could render the context and use it as global variable in the templates.
Is there a concept like this in Grails? And, how can I use that in the layout?
I am not familiar with Django at all. Looked up Django's context processor in google, I think I get it. Basically it configures reusable data that gets injected into every template? Anyway, as far as I know nothing like that exists in Grails. You can try the following as a workaround.
Use ApplicationContext
Every view has access to the applicationContext. So make a service that holds all the data you need, let's say it is called fooService, and the data item you want is a field in the service called bar (could be a method too of course). Then in your view do ${applicationContext.fooService.bar}. Resource for accessing applicationContext in view: http://mrhaki.blogspot.com/2011/11/grails-goodness-get-grailsapplication.html.
Use your layout
I am not sure about this one, so use at your own risk. The top one is of course extremely verbose. It would be annoying to call that over and over again in different views. So instead, call it once and make it a variable in your layout with g:set. I think the variable will be available in every view that uses that layout.... but not sure. Here are the docs for g:set -> http://grails.org/doc/latest/ref/Tags/set.html.
If I didn't get what context processors do in python I am happy to try again...
I have a bit of a dilemma, which to be honest is a fringe case but still poses an issue.
Currently I am using Ninject MVC and bind all my controllers like so:
Kernel.Bind<SomeController>.ToSelf();
Which works a treat for 99% of things that I have needed to do, however at the moment I am doing some wacky stuff around dynamic routing and dynamic controllers which require me to manually write a method to get the type of a controller from ninject. Now initially I thought it would be easy, but its not... I was expecting that I could get the controller based on its name, but that didnt work.
Kernel.Get<IController>("SomeController");
That got me thinking that its probably because it only knows about a binding to SomeController, not IController. So I thought, I can just write all my bindings like so:
Kernel.Bind<IController>.To<SomeController>().Named("SomeController");
This way it should be easy to get the type of the controller from the name doing the previous code, however if I were to bind this way, I would have a problem when I come to unbind the controllers (as plugins can be loaded and unloaded at runtime). So the normal:
Kernel.Unbind<SomeController>()
Which was great, will no longer work, and I would have to do:
Kernel.Unbind<IController>();
However then I realised that I need to give it some constraint to tell it which binding for this type I want to unbind, and there seems to be no overloads or DSL available to do this...
So I am trapped between a rock and a hard place, as I need to satisfy the ControllerLookup method, but also need to keep it so I can add and remove bindings easily at runtime.
protected override Type GetControllerType(RequestContext requestContext, string controllerName) {
//... find and return type from ninject
}
Anyone have any ideas?
(Just incase anyone questions why I am doing this, its because of the way I am loading plugins, Ninject knows about the types and the namespaces, but within the context of creating a controller it doesn't know the namespace just the controller name, so I do this to satisfy the isolation of the plugin, and the location of the dynamic controller, it is a roundabout way of doing it, but it is what people have done with AutoFac before Example of similar thing with AutoFac)
In my opinion the bindings should be created once at application startup and not change anymore after the first resolve. Everything else can lead to strange issues. Unless you have proper isolation using an AppDomain for each plugin you can not really unload them anyway. Instead of unloading bindings you can make them conditional and disable them using some configuration.
If you really want to unload bindings then I suggest not to do it for single bindings but take advantage of modules. Load all bindings belonging to one plugin together in one or several modules and unload those modules instead of the single bindings.