Barracuda - Miscellaneous Features
barracuda.gif (11357 bytes)This document describes some of the miscellaneous features within Barracuda, as well as how to access them.
  1. URL Rewriting
  2. Disabling the Back Button
  3. DOM Pretty Printing

URL Rewriting - Barracuda supports the notion of URL Rewriting through a helper class called org.enhydra.barracuda.core.util.http.URLRewriter. This class provides methods used by the rest of Barracuda whenever it needs to generate a URL. URL Rewriting ensures that the servlet can access Http Session information for individual clients, even if the client has cookies turned off.

By default, URL Rewriting is turned off, due to a bug in Enhydra 3.x which we're running against on the main Enhydra site. To turn on URL Rewriting, simply set URLRewriter.REWRITE_URLS = true. You can do this programatically by modifying the actual code, or (the better way) you can set this value dynamically when your system starts up using the Barracuda assembler file (ie. ex4.xml). To use this latter approach, simply add a line like this to the assembler file:

<constant class="org.enhydra.barracuda.core.util.http.URLRewriter"
                name="REWRITE_URLS">true</constant>

It's also important to spell out what this approach doesn't handle. Right now, we are only doing URL rewriting on links manipulated by Barracuda. This means that if you have a link embedded in a template that is NOT processed by Barracuda, that link will not get modified. I believe the XMLC DOM renderer provides some default processing to support URL Rewriting, but we haven't researched that fully (so that may be an option for further exploration).


Disabling the Back Button - Barracuda also makes it easy to disable the back button within client pages. What we mean by this is not that the button itself is physically disabled within the client browser, but rather that a URL gesture (ie. clicking a link, submitting a form, etc) causes the resulting page that is returned from the server to replace the current page in the browser history. This means the user can still go backwards in the browser history, its just that the page which generated the URL gesture is not there to go back to--its been replaced!

To get an idea of what we mean by this, you might want to look at the URL Rewriting / Back Button Example.

Now that you understand what we mean by 'Disabling the Back Button', here's how you would utilize this as a developer. Barracuda's BAction components provide a simple setDisableBackButton() method...if this value is set to true, the component will be rendered so as to prevent the user from going back. What this means is that any markup element which can be controlled using BAction components -- buttons, links, forms, select, and input elements -- can be modified so that when the user invokes them, the resulting page is loaded into the current page of the browser's history, thereby preventing the user from resubmitting, etc.

At this point you may be wondering how it all works. Well, let's just say its magic. Ok, so maybe its not THAT amazing, but the underlying logic is pretty complex. Basically, when we wish to reload a link or submit a page and have the results loaded into the current history location within the browser, we have to invoke some Javascript to do this. In the case of a link (<a> element), it's pretty straightforward: we can just do a location.replace(). In the case of a form, however, it's much more complicated since we need to submit the form (which effectively causes a new page to be loaded). The solution we came up with is pretty nifty.

First, we use dynamic HTML in conjunction with Javascript to create an iframe (IE, Mozilla) or layer (NN). From there, we use Javascript to dynamically create/submit a form to a special Barracuda ParamGateway servlet, which unloads all the form values and caches then in the client's session. Then the ParamGateway redirects the browser to the proper URL (which can be loaded using the location.replace approach described earlier). When the client issues the GET request, the param values are restored from the session cache and processing completes with no one--neither client or server--the wiser.

The bottom line is that this approach solves the back button issues in a manner which is easy to use and will work for a majority of developer needs.

The inspiration for all this came from Brent Ashley [brent@ashleyit.com], who has created the JavaScript Remote Scripting (JSRS) Library. We had to modify Brent's code quite a bit, but are nonetheless deeply indebted to him for this piece of functionality. If you think it's cool (like we do), you might want to drop him a line and say thanks.

Obviously, a Javascript solution will have certain limitations. First and foremost, its only going to work in browsers that support Javascript. We've tested and verified it in IE 5, NN 4, and MZ (NN 6). If you need to use it other places you may have to come up with your own solution. It should also be noted that within NN 4, forms are actually submitted using GET (regardless of whether the form is actually specified to use GET or POST). This is because NN uses layers and they don't support a target of POST. This means if you have really big forms you may run into some size problems. If you do, well, don't use the Back Button Features.

That's about it. While its not a perfect solution, its still pretty dang useful. Enjoy!


DOM Pretty Printing - Barracuda's DefaultDOMWriter supports the notion of pretty printing. To turn it on, all you have to do is instantiate your DefaultDOMWriter with a boolean value. Alternatively, you can set the DefaultDOMWriter.defaultPrintPretty = true to make all DOMs use pretty printing by default.

The way we handle pretty printing is by using the Tidy formatter (the version that ships with XMLC) to reformat the resulting markup that comes back after the DOM has been initially rendered. This means that pretty printing is not particularly efficient, and as such should probably NOT be used except for debugging purposes.

Also note that there currently seems to be several bugs in Tidy, whereby it incorrectly inserts spaces into <td> cells that contain only images and no text. In addition, it seems to split <textarea> cells incorrectly (thereby inserting spaces in the control when rendered in the browser). Both of these may have adverse affects on your display, so you probably don't want to use pretty printing for anything other than debugging at this point. If anyone knows how to fix these issues, please let us know.


For all the latest information on Barracuda, please refer to http://barracuda.enhydra.org
Questions, comments, feedback? Let us know...