Java EE

I'm currently reading this free book:

It is very well written, and explains lots of things I have been in the dark about these past few weeks at WirelessCar.

The first half of the book covers servlets. Servlets generate webpages via Java code. The second half of the book covers JSP (Java Server Pages), which are in essence HTML and / or XML documents with bits of JSP specific stuff in them, the conceptual inverse of servlets (JSPs are actually magically converted into servlets when they are accessed by a client). So JSPs use markup to generate code that generates markup.... erhm...

I doubt that anyone will be surprised to hear that my gut feeling is that I wouldn't mind writing servlets, but I would hate messing around with JSP.

First of all, Casey at Molly Rocket made a really good point in that code is more powerful than data. Servlet code, being Java code, being compilable, will not make you want to gouge out your eyes due to a typo you can't find.

JSP is data that wants to be code (with 4 different ways of embedding dynamic stuff inside of HTML, each with its own scary ass syntax). Well, maybe the capability of embedding straight Java is kind of ok. In any case, for this crap to be compiled into a servlet, you need to actually access the page, and of course maybe you made a typo and it won't even compile. Talk about jumping through hoops.

Sure, I can accept that when you have lots of static content on your page and just need a little bit of dynamic stuff, inlining some java statements in basically pure HTML wouldn't be all bad. But put a fucking cutoff on that shit somewhere! For every new technique of adding dynamic content to JSPs that is presented in the book, it just feels more and more like they wanted it to be a real programming language. It's not. It's a fucked up macro-shit-mess.

I remember the kind of pain and suffering we caused for ourselves at Massive with our various scripting languages, not really wanting to code stuff but also not really wanting to just have it be a definition language. Argh!

I haven't done a ton of web development, but I do maintain, and it didn't take long before I screamed out loud and converted things to JavaScript that generated HTML markup. The syntax is better, and WTF can you do AT ALL without functions? This is conceptually the same as using Java or C++ to generate HTML.

The book also explains what it calls a MVC approach to webapp development, with servlets handling the logic and JSPs handling the presentation. Sure it's better, but it stinks RM to high heaven. Lots of intermediate caching of stuff in so called JavaBeans (that spec is a joke), and a heavy dose of C-style procedural programming.

However, I have a gut feeling that it would be possible to use an IMGUI style approach to all of this. I'm still formulating the idea right now, but it would involve using a servlet to control how the user interface (the resulting HTML pages) got generated, most likely using a powerful HTML generator that looks like our IMGUI contexts (DoButton(), DoLabel() etc).

The goal is to allow the View servlet to generate a dynamic page based on traversing session data (internal view details) as well as Model data (the enterprise backend) on the fly for each request. This would limit the amount of stupid-ass JavaBeans flying around (evil caches), and probably limit or remove the need for any JSP.

As the new spec of Enterprise Java Beans (EJB 3.0) does a good job with persistence (using the Java Persistence API) I am not worried about the Model side of things, and I think it will be possible to emulate the IEventTarget pattern as well.

users avatar


Really interesting stuff, I have always thought web stuff is a real mess with most things messed up, and a cleaner way of handling web interfaces is a good thing, getting a more immediate mode approach is probably a good idea, at least for us...

I'm not an expert but isn't AJAX a step towards a more focused model-view separation and also more immediate?

Let's make the games we dream of playing

users avatar


I've read a bit about Google Web Toolkit, a free AJAX framework that is used for among other things GMail.

Good things about it are that you develop completely in Java (i.e. compilable), and then everything gets translated to XML and Javascript by a special compiler to save you the pain.

Evil signs abound however, for example it seems that several baked permutations of the application get generated to get around browser incompatibilities (there is an example where 12 permutations of a single app are generated), and that kind of stuff scares me. Also, it's still based around RM gui concepts, with GWT implementing a bunch of widgets for you to use.

Following on my previous post, I actually got some time today to do some serious IMGUI stuff in a Servlet. I'm still working on the core systems, but already it's down to subclassing a base Servlet class in order to instantiate your custom View class, and then you just code your view stuff in the same way we do stuff in C++.

The main caveat is the fact that it's not realtime. In my C++ IMGUIS I don't care about frame shearing, i.e. I keep generating gui even if a button gets clicked and changes state that in turn changes the gui presentation. This kind of thing is rarely noticable because the correct gui is rendered the following frame, but sometimes you see a flicker.

With IMWEB (as I'm calling it) you have to watch for this kind of stuff, as you only render a single frame (i.e. the resulting HTML document) and it is then displayed to the client until the next time the user interacts with the browser (i.e. clicks on a button). My solution is built into the baseclass, and it amounts to handling button clicks as usual (changing whatever app state you need to) and then immediately returning false to short circuit the whole gui process. The baseclass will react to this by clearing the generated widgets up to this point and then calling the same method again, and repeating this process until it returns true, i.e. the current gui is generated correctly and is up to date.

This might seem redundant, but I prefer it because it isolates all widget related stuff in a single place, and as long as you remember to short circuit it's automatic. As mentioned, we are already doing this kind of thing in our realtime apps, it's just that we can get away with shearing in those cases.

"you can't stop the change"

users avatar