And away we go...
*Yawn* *Stretch* *Crack knuckles*
Okay, I'm back. Just in time for the long weekend where no one is going to read this anyways. So where the hell was I and what did I lose? Well, I was here and it was my mind, obviously. Much better now. The break was good. Full reset in all parts of my life and now I'm back on track.
So... I wanted to rework my weblog code before I started up again. Since I really wanted to start posting again, having to get the code done before I could write was good incentive, so I took a few hours last night and this morning to *finish* the stuff I've written and rewritten a dozen times in the past year or so. Yes, that's right, the MiniBlog is gone after all this time, may it rest in peace. For those that don't know, "MiniBlog" was what I called a two-JSP page webapp that I wrote (and published) two years ago when I first started this weblog. In two pages it did just about everything that a weblog needed to do. But then as I started adding little features here and there, it got bigger and uglier until it was completely unmaintainable.
That said, the idea of a server-side Java based weblog created with just some Jars and JSP pages appealed to me. It's the J2EE equivalent of PHP, so when I redid the code, that's what I whipped up. This site is now being generated with JSTL and Java-based JSP Scripts to do complex actions (like posting and validation) and the ever-amazing UrlRewriter in the front controlling the entire thing. It's a work of art if I do say so myself. The result is a flexible web app that separates code from markup, but doesn't require that I compile anything to tweak and add features. It doesn't have templates or XML-RPC, or categories (this by choice), or multiple weblogs or authors (yet)... but it has everything I require for this blog and that's a good start.
I also made the choice to rely heavily on MySQL in my scripts. Thus, as I wrote about before, I'm calling my creation MyBlog. Yes, it's not a great or unique name like Blojsom, Pebble or Roller... but hey, neither was MiniBlog. After I've used the code on this site for a week or two to work out any of the big issues, I'm going to publish the code.
One of the main rationals for creating a JSP-only blog was to prove a basic tennet: JSPs *are* Java. They get compiled to classes just like servlets and are therefore just as useful and scalable. The problem is that most JSP developers tend to mix code and markup, which is what the core of what most MVC architectures are trying to prevent. But the MVC frameworks also insanely complex and require a compilation step and loads of xml-based settings to do their job. 80% of web-apps don't need that headache and JSPs are still a great way to crank out server-side web-sites - it's a shame to subject ourselves to the pain of something like Struts for so little reason. So I just cut through the cruft and separated the layers. The Prime Directive: No Java and Markup in the same JSP page, period. That's a pretty easy rule to follow, no? If I need to do something complex - say validate a web post, check authorization, save to the database and decide on a display page, I can do that all in what I call "JSP Scripts." For example, I'd create a page called /scripts/doSavePost.jsp - all written in normal Java - and then when I'm done, I do forward() to the proper "JSTL View" page (a JSP created with JSTL) which manages the SQL query and presentation of that page.
It's fast, it's scalable, it's maintainable and it's easy code to crank out. And in case you have some reservations about "embedding" the SQL in your view pages, then you can do the queries in your JSP Script pages, load up some HashMaps with data, throw them into the context and use them in the JSTL View page for presentation. Done. Though I'm not sure why it matters - why copy data out of perfectly good repository (the ResultSet object) just to re-use them a microsecond later? Being able to see and optimize the SQL query in the same page that's presenting the results is not something to be easily blown off for the sake of MVC religion.
What I will say is missing from JSP Scripts is a decent way to just create common methods without compiling and calling an external Java class. I got around this the old fashioned way by doing a hard include of a code.jspf page which contained common functionality - like the ever-popular checkForNullValue() method or connections to the database pool. But it'd be so nice if there was a special type of JSP page that you could just add functions to on the, but without having to copy that code into the final class file (which is what the hard include does). This would be mimicing how PHP works and would be very useful. The new JSTL functions in JSP 2.0 go somewhat towards this, but I want to call these methods from within a JSP page. Besides, have you tried to create a function? What a pain.
Speaking of JSTL functions, the thing I haven't done yet is actually use the JSP 2.0 functionality in Tomcat 5, even though that's what's on my server. I've been debating it since it would require an upgrade to be used. I'm not sure if that's important, really. I have one chunk of code that would be great to use as a .tag file and the pages could be considerably cleaned up by getting rid of the various c:out's all over the place.
But again, what's really needed is arbitrary methods. I'd love a page where I could just add methods in Java and have them dynamically accessible from the Expression Language or in my other JSP pages. I guess like Velocity Macros. Think about all the utility methods you could come up with that right now is being met with custom tags. Hey, I'm down with XML as the next person, but there's a place for a tag and a place for a simple method call. The JSTL functions are a perfect example of this.
Anyways, all of this I'm writing about is what I'm doing on my own site. At work, I've developed another more complex architecture which handles a lot more functionality such as multiple handsets, etc. There is enough going on that it's important to have compiled classes, detailed hierarchies, support for multiple clients, asynchronous events and more. And tweaking without checking into CVS would be bad. All this has crossed over the threshold into that 20% that needs a complex architecture. It was nice to step back and crank out a simple website. I mean, most of the code was written actually - I've rewritten the code behind this site soooo many times before, it was easy to just grab chunks from the aborted attempts, apply my new architecture (if you want to call it that) to it all and crank it out.
"Finishing" things is nice, no? I'm going to start doing more of that.
-Russ