I'm using Grails 1.3.8 (old but gold). In my view I render a template with the same variables as of the containing view via:
<g:render template="areaInfoTemplate" model="${pageScope.variables}"/>
This works unless I try to access methods on domain classes inside the template:
<g:if test="${currentState == State.findByName('foobar')}">...</g:if>
Leads to:
Exception Message: Cannot invoke method findByName() on null object
If I access State in the main view gsp everything is ok.
My domain class is:
class State {
String name
String value
static constraints = {
name(nullable:false,blank:false,size:0..255)
value(nullable:false,blank:false,size:0..255)
}
}
Grails isn't PHP - please don't make database calls from the view layer (unless you like to fight artificial, self-inflicted scalability issues). Just make the calls in a controller or service and pass the data to the view to be rendered. GSPs should only be responsible for rendering output, not higher-level concerns like database access.
I forgot to add an import statement at the beginning of the file:
<%# page import="my.wonderful.package.State"%>
Related
I am using Grails 3, and am working on a template page, which contains the outline for the rest of the website. I and am attempting to call a method from a controller, by using the following code, as recommended by the official documentation:
<g:include controller="layouts" action="loadUsers" />
My controller looks as follows:
class LayoutsController {
def loadUsers() {
println("we are in here")
}
}
When the include statement gets executed on my embedded tomcat, I get the following error:
[http-nio-8443-exec-4] ERROR o.a.c.c.C.[.[.[.[grailsDispatcherServlet] - Servlet.service() for servlet grailsDispatcherServlet threw exception
javax.servlet.ServletException: Could not resolve view with name 'loadUsers' in servlet with name 'grailsDispatcherServlet'
Ofcourse, the error makes sense, as I do not have that view/gsp page. I want to just simply invoke a method to create some stuff in the backend, not tie it to a gsp page. Is this possible? Basically, a similar approach to JSF where I can execute a public method on a bean.
When a controller action is invoked, unless the action invokes something like redirect or render, then a view will be rendered. That is by design and how controller actions are supposed to behave. If the view isn't present, then an error occurs.
It isn't clear what you are trying to do but if you are just trying to invoke some logic and you don't want a view that is a little bit of an unusual thing to be doing from a GSP, but you could do it by invoking a custom GSP tag that does whatever it is you are trying to accomplish. Normally all of that sort of thing is done before the view is rendered (so, before any GSP code is involved).
I have created several controllers in my Grails project and put data for each controller in the bootstrap, but the data does not appear in the table for each controller that scaffold provides as the default view. I have checked inside dbconsole to be certain that the data is there, which it is. I have also refreshed the dependencies to make certain that the version of the scaffolding plugin is not corrupted. I am using Grails 2.3.5 and Scaffolding 2.0.1.Are there any suggestions of what could be wrong?
class DepartmentController {
static scaffold=Department
def index() { }
}
Looking back at other examples of using scaffolding I realize now that I should have taken out the index portion of the code, even though it is empty.
Remove your the index method and make it like this:
class DepartmentController {
static scaffold=Department
}
Put some log messages into the controllers (or debug the app) right after the controller loads the data using the domain class in order to see if the query has resulted in any domain instances.
If not, activate sql logging and check the exact select statement executed. Possibly you have something wrong in your domain mapping so a wrong select stmt is sent to the db
I am trying to write a custom src/templates/scaffolding/Controller.groovy and was wondering if there was any way to get access to the controller name? Right now it seems like you can only get the "model" class. The reason I need it is I am customizing the render to prefix the templates directory based on the controller.
For instance I have a controller named AuthorAdminController and I need to customize the list to use the /admin/user/** directory.
Let me know if you have any questions. I am getting ready to look into how to customize DefaultGrailsTemplateGenerator but I am not sure if that is the correct route to go.
Example:
class UserAdminController {
static scaffold = User
}
Currently in my Controller.groovy I get className='user' so I have no access to the controller.
I don't think you can, as the way scaffolding works your template will always be generating a class named DomainClassNameController (i.e. UserController in your example), which gets loaded into a new classloader and then the metaclass of the real controller (UserAdminController) gets new actions added to it which delegate to an instance of the generated UserController.
Now every controller has access to the controllerName property during execution of actions, so this may provide you with a workaround. I haven't tried it, but you could try putting a log.info("controller: \${controllerName}") into the template and see which name it gives you (the backslash to make it resolve at runtime rather than generation time).
I am building an application using Play for Model and Controller, but using backbone.js, and client side templating. Now, I want the html templates to be served by Play without any backing controller. I know I could put my templates in the public directory, but I would like to use Play's templating engine for putting in the strings in my template from the message file. I do not need any other data, and hence dont want the pain of creating a dummy controller for each template. Can I do this with Play?
You could create a single controller and pass in the template name as a parameter, but I am not sure if it is a good idea.
public static void controller(String templateName) {
// add whatever logic is needed here
renderTemplate("Controller/"+templateName+".html");
}
Then point all your routes to that controller method. Forget about reverse routing, though.
I think I would still rather have a separate controller method for each template. Remember that you can use the #Before annotation (see Play Framework documentation) to have the message string handling in exactly one place, that is executed before each controller method. By using the #With annotation you can even have this logic in a separate class.
You can use template engine from any place in your code:
String result = TemplateLoader.load("Folder/template.html").render(data);
I have some experience maintaining Grails apps; now creating a "task management" application as an exercise.
Apparently there is a view dichotomy of Groovy Server Pages versus Controller actions that render a view, as evidenced by this snippet from a URLMappings.groovy example:
static mappings = {
// ..
"/" (view:'/index')
"/login/$action?" (controller: 'login')
"/logout/$action?" (controller: 'logout')
"500" (view:'/error')
}
where user-facing URLs must be mapped to either views (GSPs) or controllers rendering a view, e.g.:
class LoginController {
/**
* Show the login page.
*/
def auth = {
// .. auth logic
String view = 'auth'
String postUrl = "${request.contextPath}${config.apf.filterProcessesUrl}"
render view: view, model: [postUrl: postUrl, rememberMeParameter: config.rememberMe.parameter]
}
}
From a design perspective, how do I choose which method to use? When do I create views with GSPs/taglibs like typical server pages outputting HTML, and when do I map a URL to a controller that renders through a delegate GSP? Can I combine both approaches? Have I oversimplified the options here?
To add to what hvgotcodes said, related to your question, the only time you'd want to map directly to a GSP view is when that view is effectively "static".
By static I mean that it isn't relying on the database or any real calculations for rendering the view. It can still be dynamic in that it relies on tag libraries for dealing with common elements, and things like the "Welcome user" text at the top of pages.
As soon as you want to deal with user-supplied input, looking up database information, manage more complicated URLs, or include calculations, you should be using a controller.
The end goal is that GSPs only contain visual and layout information, as well as the occasional static block of text. But you should always avoid mixing any logic in with the GSP, because it clutters the code and always leads to maintenance headaches later on.
Edit regarding Tag Libraries:
As I wrote below:
Tag libraries are for any logic that is connected to the view, like looping over elements, or toggling the visibility of something. Whenever you are tempted to put code directly into your GSP, it probably should be put in a tag library. Of course, there are always exceptions for one-offs.
So, if you have logic code in your view, that specifically relates to visual or layout content, that should be put in a tag library. A good example is the <sec:ifLoggedIn> tag from Spring Security Core, which can be used to toggle the visibility of an element if the user is logged in. This is much better than writing it manually like so:
<sec:ifLoggedIn>blah blah</sec:ifLoggedIn>
<g:if test="${session.user?.loggedIn}">blah blah</g:if>
Because it makes the purpose clearer (by its title), as well as abstracting the logic away, so if you later need to change the way something works, you only have to change it in one place.
tl;dr:
GSPs - Simplified "static" content
Tags - Reusable dynamic components specifically for visual or layout content
Controllers / GSPs - dynamic content
I don't think it's a dichotomy. GSPs and Controller actions (are intended to) work in tandem, the controller invoking services to load data in preparation for passing that data to the appropriate GSP.
The url mapping stuff is for if you want to break the Grails convention for urls, which is orthogonal to how loading data and displaying data (are supposed) to work.
The only time (IMHO) there is a dichotomy is when developers in a project code functionality inconsistently; i.e. it is certainly possible to give the appearance of a dichotomy.