tags:

views:

372

answers:

2

It has been a long while since I have really worked with J2EE so please excuse my ignorance. My recent engagement in a Grails project has peaked my interest in Java once more and especially in Grails as it makes building web applications on the Java platform fun again. That being said, I would like an expert to comment on the following requirement that I have for an application built using Grails:

The Design Team (web designers) require access to the GSP pages and edit the view files (layouts, templates, etc.) without bothering the development team (software developers). This scenario can take place both during construction and after deployment into production.

The communication level between the Designers, Developers, and Business Users are not an issue here. However, about 40% of the time, the Business Units involved request changes to the front-end that have no impact on the Developers time but require the time of a Design Team member. Currently, the deployment workflow follows the Grails application through the deployment of a War file to a Tomcat server. I imagine there is a simpler way to allow the Design team to make UI changes without going through the build and deploy lifecycle.

Several of the Design Team members have had exposure to PHP in the past and at times miss the ability to just overwrite a template file to make a UI piece more functional or improve a layout template. I hope there is a similar way to accommodate such simplicity within Grails. I have been told that exploding the War file might be an option but that still requires the reload of the Tomcat hosted application.

If you believe that I looking at the desired solution the wrong way, please do chime in as I am more interested in a workable compromise for all the team members involved. Thank you.

A: 

You could run a server with a version of the application via run-app in development mode. The designers can then make changes to the views and they will reload. They would need to be able to acccess the source code on the server via a share of some kind. As a plus, if you checked out the source the designers could then commit their changes from the server.

The downside is that if the reloading fails or you run out of memory (has been known to happen with lots of reloading) either a developer would need to stop and start the app or you could provide the designers with a script to run to bounce it.

You'd obviously take a performance hit by running in development mode and via run-app but it might a ok trade off in your case.

cheers

Lee

leebutts
Thank you for that suggestion. We did explore the option of using the Grails application in development mode but the performance became a problem quickly. Maybe we could have played with the settings some more but as I understand it, for production use, this method is not recommended.
Amir Khawaja
Correct, it's not meant for prod us, it will always be a lot slower than a deployed WAR. Unfortunately I can't think of any other way to achieve what you want.
leebutts
Production has dynamic recompilation turned off for performance reasons. That's why it's production. Development has it turned on for ease of development. :)We usually have our designers learn how to pull from Git, build and run the app, and develop in place. A lot of times they don't know how to use version control so we've got to teach them, but we get a huge benefit all working on the same space once they get used to it.
John Stoneham
Thanks for the comment, John. The Design Team here is also used to a version control. We use Subversion. However, in an ideal world, I would like to see the Design team just work on the design. As I said, it would be nice if I could just somehow separate out the coding elements from the design elements. I don't know if there is another way to look at this problem to arrive at a reasonable solution.
Amir Khawaja
+1  A: 

You need to specify the following settings in Config.groovy:

grails.gsp.enable.reload=true
grails.gsp.view.dir="/path/to/gsp/views"

The 'grails.gsp.view.dir' is typically the path to your checked out SVN repo. You can then just 'svn up' everytime you want to update the views.

There is one caveat: When a GSP view is compiled it uses up permgen. Eventually you will run out and need to restart the server.