There is an old saying called the [nail rhyme](http://www.enchantedlearning.com/Nailrhyme.html) that starts off “For Want of a nail…” and ends “… the kingdom was lost”.
I attended a conference on the weekend. There was a session denigrating Struts and promoting Webwork. I didn’t go to the session because I have used and intensely dislike both web frameworks. The reasons why can be the topic for another blog. This was much to the disappointment of the speakers who aimed a jibe at me before realising I was absent.
Later that evening over several beers the most zealous of the presenters found me and sought to convert me to the new truth.
I said that “we used JSP, JSTL and our own home-grown set of classes for our framework and that it seemed to work very well. We roundtrip with a designer. The pages are very fast to edit and test. No problems.”
“But” he said, “you have to build a jar and deploy to your server after each edit before you view or test”. That was when the penny dropped. It occurred to me much of the effort to find alternatives to JSP was to avoid this problem.
There are two ways of avoiding the build-jar-deploy-unpack problem:
* use an exploded directory structure
* use a small shell script called weblinks.sh
Exploded Directory Structure
—————————-
In this approach you configure the app server to use a directory rather than ears, wars and jars. We use Orion application server, and I have used that approach in the past.
Both the IDE and the app server are pointing to the same place. You press save. Then if you run a test against the page or call the page, the app server notes the new timestamp, parses, compiles and executes it. Easy.
Weblinks.sh
———–
But we are even lazier. What if you could leave your build script to create jars, wars and ears and still get instant deployment.
Here’s how:
1. deploy the app as an ear.
2. let the app server expand it
3. delete each web resource (jsp, image, javascript file etc) and replace it with a symbolic link to your IDE’s web source directory.
4. Edit your JSPs, press save amd voila! Instant deployment.
The technique works equally well for a Java IDE, Dreamweaver or any other HTML or text editor.
As with the previous technique, when a file is saved the app server sees a new timestamp. Instant deployment.
Attached is a Unix/Linux/MacOSX shell script called [weblinks.sh](https://gregluck.com/blog/weblinks.sh) which does this.
Now back to my missionary friend. He objected to the shell script on the basis that it was “changing the operating system”. The last time I checked, if you have a shell account you can write scripts.
“But I run Windows”, he said. Another penny dropped. Just in case any of my readers was in any doubt I have developing on Linux for the last six years, which I mix up with a bit of development on my Mac. Shell scripts are easy on both. On Windows, I guess if the IDE does not do it it is not possible.
Well, the last time I checked, it was possible to write batch scripts in the miserable DOS. If you are running on NTFS on W2K or higher, then you can create symbolic links. See [here](http://shell-shocked.org/article.php?id=284) for a discussion of the command line tools and options for doing so.
For want of a symbolic link
—————————
For want of a symbolic link
the JSP was lost.
For want of a JSP
designer roundtripping was lost.
For want of a designer
usability was lost.
For want of usability
the project was cancelled.
For want of a project
the developer was sacked.
For want of a symbolic link…
Greg,
To be fair JSP vs alternatives is a different discussion to Struts vs alternatives…
Also, I think you will find that our mutual ‘missionary’ friend is using the Exploded Directory Structure technique on his current project. 🙂
Although these techniques are significantly faster than packaging and deploying an ear they still require parsing and compilation which can represent a significant time lag when you are trying to do TDD. Testing also becomes a little bit more painful when you have to consider that some of your code is running locally and some inside your server.
The basic problem here is that JSP ties rendering a view with serving the result. These are distinct concepts but cannot easily be performed or tested independantly with JSPs.
Whether this problem is worth worrying about froma pragmatic sense, I suspect depends largely on the complexity of the views being developed.
cheers
Perryn
PS Why does using a technology other than JSP imply that you can’t round trip with a designer?
Whilst this doesn’t address the issues with JSPs, perhaps this helps paint a different picture http://www.pubbitch.org/blog4php/blog.php?entry=2004/10/10/every_time_you_use_struts_god_kills_another_kitten
Pez, in answer to your question about JSPs, the commercial tools that web designers use such as DreamWeaver can parse JSP tags and mark out scriptlets but cannot do so with alternative mark ups such as that introduced by velocity.