John Topley's Weblog
October 2004 Article ArchiveGolden GoogleSaturday, 23 October 2004Google are golden at the moment. Their search engine has been number one for as long as anyone can remember, they've just successfully gone public and now they're churning out innovative and useful software at a rate of knots. I've been using the Google Toolbar for a few months and I appreciate its pop-up blocker and PageRank counter. That said, anyone who thought that Google's software ambitions were limited to making IE add-ons was in for a shock. First there was Gmail, which a lot of people took to be an April Fool, for that was when it was announced. Surely they couldn't really be offering a gigabyte of storage they asked, but they were the fools, for they were wrong. However, the generous storage capacity isn't the most interesting thing about Gmail. After all, Google have had a petabyte filesystem for some time and it's likely to be quite a while before a significant number of users are approaching the limit of their one gigabyte allocation. No, the most interesting thing about Gmail is its user interface. It's as close as a web application has ever got to a desktop application. It's been called audacious, for it tears up the rule book about what you can do with dynamic HTML. I've recently been fortunate enough to receive a Gmail invitation and it is amazing to see it in action. If you'd like see it too, leave a comment on this article (include your e-mail address) and I'll mail you an invitation. I only have one invitation to give away like this, so the first person who asks for it gets it. Please don't pester me for an invitation after that because I can't oblige. Not content with conquering search and web-mail, last week Google made their first inroads into the desktop, with the announcement of Google Desktop Search. Now you can put the power of Google to work on your desktop and you don't need a huge cluster of Linux boxes to do so. All you need is the 446 KB setup file, although this isn't without its problems. You have to have administrator rights to install the software, which my regular user account doesn't have. I tried using RunAs, but this didn't work because you have to run the installation as the user who is going to be using the search engine. The solution I had to adopt was to temporarily make my user account a member of the Administrators group. Not ideal. I'd also like a way to specify where to install the program and where to store the search indexes, which can get pretty large. Still, Google Desktop Search is beta software, as indeed is Gmail.
It currently indexes Outlook and Outlook Express e-mail, Microsoft Office documents, text documents and the IE cache. Other file formats are sure to follow. I've no idea how it works but it just does, with the absence of fuss that we've come to expect from Google. Near-instantaneous full text searching from the desktop is nothing new, but what is new is that the strength of the Google brand should ensure that it's adopted like never before. Google beat Apple and Microsoft to it and they even have the cheek to put a Microsoft-esque icon in the shell notification area whilst they're at it. I was going to claim—like others have done—that Google have delivered the promise of WinFS today, until I educated myself about what WinFS is really about. There's been much less fanfare around the fact that there's now a Google Search Appliance for the enterprise. This is a funky-looking yellow box that you can mount in your server rack. It contains a customised version of Linux for running the search engine, and I assume that it isn't limited to searching the same file types as the dekstop search product. It really is Google-in-a-box—so now there's no excuse for knowledge workers wasting a quarter of their time searching for documents, which is a statistic I've seen quoted. One of the Web's worst-kept secrets is that a Google Browser is on the way. It's hard to see what value the kids from Mountain View can bring to the browser over and above the likes of Mozilla Firefox, but I guess such lack of vision is why I'm not one of Google's new millionaire staff members. Some have speculated that a Google browser would be little more than a branded variant of Mozilla, but I'm hoping for something a little more compelling. Google are riding the crest of a wave at the moment and the general feeling is that they can do no wrong. Many are even saying that Google are the new Microsoft and if nothing else, the company must surely be the largest blip on Redmond's radar since Netscape. It's not all good news though. Some people fear the power of Google as it positions itself to become the gatekeeper of the modern information age at home and at work, both online and offline. In spite of their often heard “don't be evil” mantra, Google's commitment to privacy remains a cause for concern, as does its position on web standards and accessibility. I don't think Microsoft are beaten just yet. They've been around over two decades longer than the pretender to their throne, and last time I checked, their core products were doing rather well. And of course they have a lot of money. Google are producing some genuinely good software that benefits people, but I think that most of the hyperbole about them being the new Microsoft is driven by their current golden reputation. Good reputations are hard for companies to build and even harder to keep. It doesn't take much to screw up. A salutary lesson for Google is that Microsoft used to be in a position where they could do no wrong and this lasted for years, probably culminating in the Windows 95 launch. Then a raft of security problems and most recently, a perceived inability to keep their Windows Longhorn strategy on track, took the shine off their reputation. It would only take a high visibility occurrence of being evil for the same thing to happen to Google. Jakarta Struts De-Mystified Part 4Saturday, 16 October 2004Last time we wrote most of the JSP to display the list of topics and I introduced some of the Struts custom tags for looking up message resources, conditional processing and collection iteration. Without further delay, let's write the code that makes each topic subject a hyperlink. As I mentioned before, each installment in this series is going to be much shorter from now on. The Struts html:link tag is used to render a hyperlink, as the name suggests. The code below uses the tag's forward attribute to specify the name of the global ActionForward that contains the URI of the hyperlink, in this case ViewTopic: <tr> —I'll explain the use of the name attribute in a moment. First of all, I want to explain what the filter attribute is doing in the bean:write tag. Quite simply, when set to true it replaces HTML reserved characters with their equivalent entities. Although the default value is true, I've included it within the code to make it explicit what's going on. Back to the task at hand. You may also recall from part one of the series that we want topic hyperlinks to be shown in the unvisited link colour when there are new replies to a topic. This means that the hyperlink needs to be subtly changed when there's a new reply. Somehow we need to encode within the hyperlink not only the unique ID of the topic that we want to view, but also another query parameter indicating the number of replies to that topic. The link tag lets us reference a JavaBean that contains a Map of query parameters, or has a property that itself contains such a Map. In our case, we can create such a bean and refer to it by using the name attribute within the link tag. The jsp:useBean tag is used outside the logic:iterate loop to create a page-scope bean called params that is a HashMap. Within the loop, we have a two-line scriptlet that:
—Unfortunately I couldn't work out how to eliminate the scriptlet code, but at least it's only two lines. I'm sure it could be done using the JSTL, but I haven't used that yet. Besides, this isn't a JSTL tutorial. The complete code is shown below: <jsp:useBean id="params" class="java.util.HashMap" scope="page" /> The actual hyperlinks end up looking like this: <a href="/webforum/ViewTopic.do?pid=1&r=1">Some Topic</a> Source Code DownloadsTo reduce the download sizes, I've split the Struts JAR files that go into WEB-INF/lib into a separate download. The files below are the full source code for the application, in both JDeveloper and non-JDeveloper form.
Next TimeThe application doesn't do very much at the moment. Next time we'll take a look at how we're going to display an individual topic and its replies. Jakarta Struts De-Mystified Part 3Sunday, 03 October 2004I've decided to make a couple of changes to this series. First off, I've had requests to make the full source code for the Web Forum application available for download. Initially I didn't want to do this because I only wanted the relevant code to be associated with each installment. I've changed my mind because it's going to save me a lot of time if I don't have to strip out code every time I write an article. Secondly, I've decided to split the series up into much shorter, bite-size chunks. I'd wanted each article to cover a particular aspect of the application and Struts, but it's just taking me too long to write this way. Hopefully it won't seem too disjointed. I do have something planned for later that will bring it all together again, but now's not the time to mention that. So without further ado, let's press on. Last time I explained the persistence and business object layers and we wrote the code to retrieve the list of topics from the database and represent them as objects. We used a Struts ActionMapping and an ActionForward to get as far as the JSP that will actually display the topics on the screen. Displaying The TopicsStruts comes with a bean taglib that provides JavaBeans-related functionality, and an html taglib that renders common HTML attributes and JavaScript event handlers. Both are used within topics.jsp, as is the logic taglib mentioned earlier. The following code fragment from topics.jsp illustrates the use of the bean:message tag, which is used to render an internationalised message based on a message key and locale. This means that the user interface string constants within the application can be separated out, rather than being hard-coded in the JSPs. These strings are looked up in a Java properties file specified using the message-resources tag in the Struts configuration file. <bean:message key="app.doctype" /> —This code uses bean:message tags to render the DOCTYPE declaration as well as the HTML Content-Type and Content-Language meta declarations. The html:html tag is used to render the HTML tag at the start of the document, using an XHTML format declaration and appropriate locale. The declaration in the struts-config file for the properties file containing the string constants is: <message-resources parameter="com.johntopley.webforum.view.Resources" —This section must come after the <action-mappings> section. It tells Struts to expect to find all of the user interface string constants in the files Resources.properties and GlobalErrors.properties, and that both of these are located in the com.johntopley.webforum.view package. The null attribute isn't very intuitive, but setting it to false means that any errors caused by not being able to find a message resource within the properties file are displayed on the JSP, which is useful when debugging. I've also declared that I'll be using a separate properties file for storing error string constants. The key attribute tells Struts that I want these to be stored in the HTTP request under the key GlobalErrors. Note that storing the error strings in a separate properties file to the rest of the user interface text is entirely optional. I do it because I like the extra separation. The html:rewrite tag is used in the stylesheet link statement to generate the correct URL for the path to the stylesheet, which is then passed to the HTML link tag as normal. Taking a look at the Resources.properties file, a convention I like to use is to prefix application-wide string constants with “app”. All other string constants I prefix with the name of the JSP in which they're used. For example, these are the constants for the Topics page: #-- topics.jsp -- Recall from last time that we have a Posts class stored in the HTTP request that contains an ordered collection of Post objects. We somehow need to loop through this collection and retrieve the relevant information from each Post object. Struts comes to our rescue with three tags within the logic taglib. We use the iterate tag to iterate through the collection, but first of all we need to account for the fact that we might be dealing with an empty collection. In other words, there may not be any topics to display. The notEmpty tag and its opposite number, the empty tag, allow conditional processing based upon whether a particular variable is null or an empty String, Collection or Map object. Here's the outline code from topics.jsp: <logic:notEmpty name="com.johntopley.webforum.postlist" property="posts"> There's quite a lot going on here. The name attribute used in the notEmpty, iterate and empty tags tells Struts the name of a JavaBean that holds the collection to be iterated over. In this case, it's com.johntopley.webforum.postlist, which you may remember is the HTTP request key that we stored the Posts objects under in the ViewTopicsAction Action class. We used a bit of indirection there because we didn't refer to the key directly, but instead by the POST_LIST_KEY public static variable in the KeyConstants class. By the way, notice how I prefix the key with the package name to help avoid namespace collisions within the HTTP request. The property attribute is also used in all three tags. It tells Struts which property on the bean referred to by name contains the collection. The value for this attribute should be set to the name of the accessor (getter) method in the collection class, but without the “get”, or for boolean properties, without the “is”. Our Posts class has a getPosts method, so we simply set property to the value posts. The id attribute in the iterate tag creates a local variable within the tag body that we can use to refer to the current row within the loop. I've called it topic. Think of it as being similar to the “i” variable within a for loop. I've also used the length attribute to specify that we only want to display the top sixteen topics. Finally, the type attribute is the fully-qualified class name that we want to downcast the object representing each row to. This is important because without doing this cast we won't be able to access the properties of each individual Post object within the collection. Notice that the combination of the notEmpty and empty tags effectively allow use to create an if/else structure, but without having to resort to scriptlet code. It's good practice to try to avoid scriptlets in JSPs, because they should only contain markup and not bare Java code. This conditional if/else processing pattern is repeated with other tags within the logic taglib. Adding the body to the loop gives us the list of topics at last: <logic:notEmpty name="com.johntopley.webforum.postlist" property="posts"> —The most important point to note here is the use of the bean:write tags to render the contents of the JavaBean referred to by that tag's name attribute. What joins it all together is that we set the value of this attribute to the topic bean provided by the iterate tag. And because we've cast the objects within the collection to the correct type, the write tag can access the properties of each Post object using the JavaBeans convention explained earlier. Source Code DownloadsTo reduce the download sizes, I've split the Struts JAR files that go into WEB-INF/lib into a separate download. As stated earlier, I'm now providing the full source code for the application, in both JDeveloper and non-JDeveloper form.
Next TimeIt still seemed like quite a large bite, at least to me writing it! The important thing is that it didn't take me several days to get there. Next time we'll finally get around to adding the hyperlinks to the listed topics that allow the user to click on a topic to view it. |
 |
 |
 |
 |
 |
 |
