I think that looks pretty nice. But it looks nothing like what I have to work with. I'm in 'how do I get from there to here' hell. I'm in the actions, then the jsps, then struts config and back to the jsp to look at some javascript and then to some beans etc. By the time I find what I'm looking for, I can't remember why I was looking for it.
I feel that pain. Despite the apparent simplcity of my page, we're far from completely immune from that phenomenon. It IS better, but we still have those byzantine bug hunts at times.
One thing to note too is that there is not a lick of Java in that code. And, AFAICT, you could implement the interpreter for that with pretty much any general purpose language. I have no problem with the above. And Java is a good language for implementing that interpreter, IMO.
My original point was obviously not well stated. The point is that a lot of developers that are not already well versed in Java see it as an extremely over-complicated platform. The thing that annoys me about this is that Java is a very simple language (minus generics) and really very easy to learn. It's all of the crazy stuff that we do with it that makes it complicated. There's just a lot of stuff that is over-complicated. Do I even need to name the example? The niceness of the above will always be tainted by the kind of JSP I am working with.
You're absolutely correct on both counts. The language IS simple, and the platform IS complicated. Frankly, annotations are the singular addition that turns around and helps us reduce the apparent and day to day complexity that we face. As with any simplifying technique, the complexity is still there. However now it's buried behind Convention over Configuration, and embedding configuration information directly in to the classes.
CoC is cleary the "cheaper" and less intrusive of either of these techniques, but even there the complexity isn't shoved in your face like it with, say, the Struts config file. A layman can look at the Struts config file vs a simple Java bean and say "boy this Struts stuff looks complicated, while this is really simple". But in truth, with the simple Java bean, there is potentially a lot being said there that the novice can not see. With JPA, for example, all you need to create a persistent class is the @Entity tag. That's the only requirement. But if you don't understand the CoC rules, then you can't readily know the mapping of that bean to the database.
The complexity is still there, the assumptions unsaid and documented elsewhere, but it certainly LOOKS simpler. (To be fair it most certainly IS simpler, the rules are not that complicated, but I'm simply portraying this as an example. But then you get to deal with the details of manage and unmanaged objects, living with the secondary caches, etc.)
The real benefit of CoC and annotations is, after learning their basic rules, is that it helps make the simple case simple, and complexity scale with the need.
In Struts, you have complexity for the most simple of actions, since there is no defaulting. Today, modern frameworks default nicely and require the extra configuration only as necessary as your requirements drift away from the defaults.
So, anyway, despite the simplicity of the Java language, the actual problems we try to solve with are actually quite complicated. HTTP SEEMS simple, but we all know what a pain stateless applications are to write, and what tedium there is in processing even the most mundane of HTTP requests.
And yes that does give me some hope. I'm not really keen on learning it but maybe I can get the person who needs help with this so often to learn how to do it.
Our ca. 2000 Struts project no doubt looks exactly like yours. Lot of new people, and the train is running with just crushing deadlines, so, anyway, not pretty. And when I was thrust in to trying to make changes to it, having someone try to explain the workflow and lifecycle was simply a nightmare.
As I said earlier, though, the best part about the tags is that it's iterative. Many JSP pages were cut and pasted in to existence, with perhaps a jsp:include for the large chunks. But the tag files are great for not just the big chunks, but even the little bits.
For example, lots of pages may have something horrible like this:
%>/imgs/button.gif)
This can become, simply using JSTL:
A simple step eliminating little Java bits.
Next you can go anther round and create your own tag:
The tag file looks like:
The tag prefixes the path for you, and the "border='0'" comes "for free" now. You can see how simple the simple tags are. Basic templating. As you build more and add use cases, you can make them more and more complicated internally.
I think the latest version is certainly cleaner and "simpler" than the first, even though there is "hidden" knowledge in the final one (embeding the context and the border attribute).
So, hopefully your developer can make some passes through your JSPs to clean them up and codify some of your assumptions that are now, no doubt, quite explicit in the code.
