Just a Thought...

What would happen if you could integrate a word processor and a compiler? That’s precisely what geoProgrammer from Commodore 64 fame did. The Graphical Environment Operating System (GEOS) team had several tools available out of the box. That included geoWrite and a few other cool apps. Because the GEOS team controlled the file formats for all the tools that were part of the system, they could integrate things a bit better than others. There was no plain text editor in the GEOS system, that wasn’t sexy. That wasn’t graphical. So why bother with it?

You wrote your applications in geoWrite and compiled them with geoAssembler which produced relocatable bytecode. Finally you linked it with geoLinker . The whole suite came with a comprehensive API manual which was quite nice considering that GEOS was all assembly language. The experience taught me that you can have very elegant code even when you are working at the assembly level. However, an interesting side effect of using geoWrite to write the code was that you had fonts and font sizes available. It was actually rewarding to write nice looking comments. In fact, the comments would be more noticeable than the code. It was an unexpected side-effect from using a word processor for writing code.

Another very nice side effect was that if you wanted to embed graphics for buttons and such, all you had to do was paste your graphic into the document with some marker so that you can reference the graphic in your code. Can you imagine if your code would make it that easy to reference a graphic instead of having a large byte field encoded in numbers or relying on the linker to get it right?

Something like this has never been done since, for a number of reasons. First, it used to be that graphical operating systems were simply too expensive. Next, it was that all word processors had their own proprietary formats. Finally, you have the geek chic of only using text editors because that’s what geeks do. You’d be surprised what a little style can do to make the code more readable. One example are the text editors and IDEs that color your code for you. Now that we have an Open Document that most word processors can be extended to use, why not leverage that standard?

It turns out that the answer is that it makes the compiler more complicated. Of course, it’s easy enough to write a bit of code that simply strips out all the style and feeds the compiler/interpreter the plain version of the code. Do I expect something like this in the future? I’m not sure. There has to be a cultural demand for it to happen, and right now we are still stuck in the mainframe and resource starved origins. I think that UTF support in the source code is going to be a sooner cultural demand than WYSIWYG prettifying of code. The future is still unwritten.

Java ActionPack is not complete yet, and there are a few rough edges. One of the temporary work arounds I have is that markup is in my Java code. This is not an ideal solution. These are what Ruby on Rails uses partials for. I need to get the partials code working. Another issue, that I really would like some input on is whether JSP code belongs in the WEB-INF directory. I’m planning on making the View base configurable, but defaulting to where it is right now (the context root). That means all your view code (HTML and JSP) will be in the WEB-INF directory if you so choose. I’ve been told this is an industry practice, but I’ve never seen any examples or articles telling me this is truly the case. Lastly, I need a way of writing URLs based on the action/view/parameters that we set up in the Routes file.

I’ll probably have to do this in two stages. The first being all the hook code necessary to generate these things in ActionPack. The second being a new JSP ActionView library to provide a tag and expression library you can use in your pages. The idea is that if you don’t use JSPs, you can still use the core functionality built in to ActionPack. However, if you do use JSPs, you can simply use the convenience parts to make it nicer.

Of course, the next thing I need is a lot more documentation. I realize that Java ActionPack is at the place where Spring used to be a couple of years ago. It’s still an underground technology that really can make it easier to get things done. It is something that can be used along with Spring if you choose, and at the end of the day it is all about what makes it easier for you to get the job done.

Something that I have been struggling with is how to work with Helpers. In Rails, you have Helper modules that get mixed in to both the Controller and the View logic. It can help clean up code, but in Java there is no real clean way to handle this. I could have a dynamically generated “helper” attribute that gets populated when the controller is instantiated. I could do that through a setter ala Spring, a constructor ala Pico, or something similar. The problem is something that requires much more thought. The controller would probably be an easier proposition than the view.

I’m definitely going to need some help, or this will take a long time. I still want to keep ActionPack very focused and as simple as it possibly can be, but there are some cool things that will make developing applications much nicer coming down the pike.