fforw.de

Somehow I seem doomed to be in a constant love/hate relationship with my IDE of choice. Nowadays that’s Eclipse. On one hand, I don’t want to do any Java development without the refactoring tools and source helpers that Eclipse provides, on the other hand I find myself in a constant battle with Eclipse bugs — and they’re not of the sporadic kind, the kind every software product has, but of the soul-crushing, repetitive and long-lasting kind. Whenever there’s a new Eclipse version, I secretly hope this one will remove some of them, but usually they just get more. Sometimes bugs disappear, usually when some component is completely rewritten, but it’s very rare.

Sometimes I am lucky though and discover a way around them by either being persistent enough or by finding just the right magic combination of search terms that point me to a solution. To end this blog post somewhat uplifting, here are two fixes I found recently.

The Workbench-locks-up-at-startup Bug

This one happens fairly often for me. On startup, eclipse will do nothing or just write something like “Initialize Java tooling.. 1%” and then just stop working. Since I use Ubuntu with Compiz, that will then turn desaturate the eclipse window to signal the app is no longer responding to any window messages. There seems to be no CPU activity and this all continues until I forcefully kill the eclipse process.

Solution (found on Stackoverflow)

Delete either  .metadata.plugins\org.eclipse.core.resources.projects\.markers.snap or .metadata.plugins\org.eclipse.core.resources.projects\.snap (or both?)

Bug: “Link with Editor” does not work with Javascript files anymore

The Eclipse team keeps changing the javascript editor, usually for the worse. Where it once was a simple syntax-highlighting editor that was of no big help, but did not stand in your way, either, it now tries to help you writing Javascript without seeming to actually understand Javascript at times. For example, it complains when you write “var undefined;” which is perfectly valid JavaScript and useful, too. (“undefined” is not a keyword like “true” or “false” but just a special value. Every variable that gets declared but has no value internally has that special undefined value. Redefining undefined locally makes access to it faster because it is already found in the local scope and also enables Javascript compressing tools to shorten the variable name.

Eclipse also acts weird when you try to type stuff like

$(function() {

});

or

(function() {

})();

Eclipse reorders round and curly braces etc.

So my strategy with the new JavaScript editor was basically to switch off what I could and ignore or suffer through the rest. Until the “Link With Editor” Bug came up. I really like “Link with Editor”, because it lets me collapse my whole project tree and then open up those branches I’m actually working on currently — but suddenly, it no longer worked with .js Files (WTF!?)

Turns out Eclipse is again trying to be clever and now forces you to set up all your script folders to have your scripts then listed under “JavaScript Elements”, something I couldn’t manage to with my current project.And if you fail to do so, Eclipse punishes you by taking away “Link with Editor” from you.

Solution (found that one myself)

Either use the “package explorer” of the Java perspective, not the “project explorer” or in the project explorer, click on the small triangle that opens the “View Menu” and select “Customize View…”; and then on the second tab, disable “JavaScript Elements”. Now Eclipse will honor “Link with Editor” with .js files again.

On the occasion of presenting CouchDB and jcouchdb at my place of work, I got around to finally create a small example application that is now downloadable as sneak preview. There need to be bugs fixed, features implemented and lots of documentation to be added, but it kind of works.

It’s called “Hood” for neighbourhood and allows you to mark places or people around a place of activity of yours, called hood. it is meant to foster collaboration / tips on local places etc.

It’s Spring Web Application demonstrating some techniques of working with jcouchdb. It’s an eclipse WTP/Spring IDE project with all dependencies you need besides couchdb and tomcat or another servlet container.

Stay tuned for hood to grow into a fullblown app.

Links:

• Hood Alpha – download at code.google.com
• Hood Beta 2 – download at code.google.com

After again spending time to fix issues resulting from a collision of the yuicompressor jar and the normal rhino jar in one of my projects, I came up with a more radical solution:

1. Download the source codes from yuicompressor and the corresponding rhino release
2. Replace every occurance of “mozilla” with “yuizilla”
3. PROFIT!

 So now I have a version of the yuicompressor that works fine and does not conflict with the rhino version I also have in my project. And I don’t need any stupid jar class loaders or have to write stdin/stdout handling for some terribly slow external yuicompressor process. I can just use the classes

• com.yahoo.platform.yui.compressor.CssCompressor
• com.yahoo.platform.yui.compressor.JavaScriptCompressor 

and be done with it. Hurray for fast dynamic server-side script and style compression!

• Download yuizillacompressor-2.4.2

I played around with some ideas about JavaScript on the server-side and came up with this little prototype. It’s a set a spring components that allow running the scripts in a website on the server side in case a user has no support for JavaScript or has disabled it.

The following diagram shows the way things work:

The parts of jsserv

The DOMInterceptor intercepts the HTML output of other controller and initializes a dom state with it. The document itself is parsed into a DOM tree and the referenced scripts are loaded and executed. Additional patch scripts can be defined to alter the behaviour of other scripts.

The current version adds

<a class="eventHelper" href="/app/event?uuid=42">...</a>

Links around every element for which a onclick handler is registered. The links point to a DOMEvent Controller that triggers updates in the user’s DOM State.

A little example scripts implements a collapsable tree that changes the style classes of nested unordered lists. With the JsServ DOM Manipulation this works with JavaScript as well as without JavaScript on the client side.

While this code is only a rough sketch it promises a lot in terms of vastly reducing the amount of work for sites that must use javascript to get an optimal user experience but who cannot or want not to have a java-script only site. Although the link-as-click event method is rather limited, it is good enough to make a lot of DOM manipulations possible. Expressed only once in JavaScript. Running in it’s deluxe form for people with client-side JavaScript and in a basic form for people with the help of using server-side JavaScript. All is seamlessly integratable into all kinds of Controllers.

Links:

• Download JsServ 0.12
  
• code.google.com project page for jsserv

Dependencies:

• Bringing the Browser to the Server
• Mozilla Rhino
• Spring Framework

_{Edit: code.google.com link added, update to 0.12}

The ff javascript library is now available in the version 1.11 which is a small maintainance update to version 1.1

Changes are:

• introduced ff.extend
• made ff.dom functions ignore null arguments and handle the tabindex attribute correctly in Internet Explorer

See the documentation for the ff.extend.

Links:

• Download
• Documentation

After some more work on it, I am proud to announce the version 1.1 of the ff javascript library. It includes various bug-fixes ( ff.dom.append , various Internet Explorer compatibility fixes especially in the DOM builder) and some more functions in ff.dom and ff.style. The ffjs documentation moved to a new location. It includes a lot more documentation and 2 examples. I may add some more examples in the future. 

The project documentation has been moved.

One problem when trying to do “The Right Thing ™” and separate your webdesign into different layers is what to do when you need additional information to transform your nicely id and class annotated DOM nodes into fancy, javascript-enabled goodness:

Where do you store that information? How do you associate it to the DOM nodes? I will present three approaches to this problem..

Method 1: The squeaky clean

The first method is relatively straight-forward: You add ids or classes to your DOM nodes. Then you include a dynamically generated javascript library in your document.

The problem with this is that the generated javascript library is requested in a new request which makes it nescessary to provide this request with the nescessary context to generate it. You also need to write code which finds your DOM nodes and finds the data from the included javascript library and associates both. You also walk over the server side data twice: Once to generate the DOM nodes and once to create the javascript library.

Method 2: Compromising

The second approach is to compromise a little on the separation ideal and render the javascript data from the first method right into the page source.

You don’t need to carry the context for the data into a second request for the javascript library, but you still need to wak the data twice on the server side, you still need to associate the DOM nodes to the data, and you have a big block of js data in the head section of your document.

Method 3: Annotating DOM nodes with JSON

I thought about a way to directly associate the DOM with additional data. JSON seemed to be a good format to store the data. At first I thought about using a custom attribute but I did not like the idea of invalid HTML markup. Then I got another idea:

Why not use the event handlers? Something like

<a href="/no_js" onclick="return { foo: 'extra', bar: 1};">Link</a>

works pretty well. It is totally valid HTML, the onclick contains valid javascript code which can also be easily parsed by other tools. (It is basically just a JSON string wrapped with a “return [...] ;” ) When javascript is disabled, the link just executes normally and can provide non-javascript functionality. The data can be retrieved by executing “var data=linkNode.onclick();”. “But what about the fake event handler?” you might ask. Well.. if someone clicks on the unmodified link in a javascript enabled browser: nothing happens. The script just returns some data and does nothing else. The return code will be ignored by the browser environment due to this age-old, pre-DOM standard of canceling the event if the handler returns false and just going on if it returns true — since the data is something it evaluates to true so it’s just ignored.

On the server side things get much easier. Not only does no context need to be carried into another request but you also only need to walk over the data once. You can ouput the HTML and the additional javascript data into the same part of the document.

I admit that this approach bends the rules of separation a little, but in my opinion that’s ok.

• It uses onclick=”" but does not really put any code in there, just some data
• The semantics of the original markup are kept as they are. The method only allows to annotate this “base data” with additional information.
• The pros vastly outweigh the cons