Building a custom RAP Widget based on Select2

This weekend a started to play aorund with new new RAP API introduced in 2.0. It really looks promising.

I started off with the CKEditor Example and created a combo-replacement based on Select2.js. By the way I had more a fight with the select2 api (that I didn't know) than with the rap api thats quite straightforward. I could answer nearly all of my questions from the source.

Here's the example for those who want to try:

It supports markup and (what I always miss on the standard combo) it has "clear selection". When you create it with SWT.MULTI it supports the cute Multiselect feature of select2.

https://gist.github.com/eiswind/5611873 java backend

https://gist.github.com/eiswind/5611866 js client

Consuming emf bundles from p2 with maven : b3

Some of the eclipse libraries are not so thightly bound to OSGi and lately I wanted to use EMF in a grails project. It came to me that there are no current maven artifacts available for EMF, so I had to roll my own.

Asking stackoverflow, I first tried to re-jar the bundles with tycho, but that gave me all the OSGI-deps in one jar, what wasn't what I was looking for. After reding through some discussions around maven and p2 in the eclipse bugzilla, I noticed that b3 has the capability to mirror a p2 repository in a maven compliant layout.

As I wanted to use the xsd to ecore converter I created a aggregation for the xsd sdk
notice the maven config at the end of the aggregator tag.

https://gist.github.com/eiswind/5381710

Then I uploaded it to google drive, so that I can consume the repo from heroku build. One major drawback is, that the source bundles are not maven conformant, so that attaching them automagically won't work.

building a tree: my first three weekends with javascript

I guess I have been writing java code for quite a while now, and it still makes my living. But for the last twelve months I have been working in the agency business and I finally wanted to havy some control of whats going on in the browser.

I set myself a simple, but non trivial goal: I wanted a lazy loading tree backed by orient db only using commercial-friendly licenses.

• Dojo

Being used to the big java-frameworks, dojo looked promising. But the dojo tree is outdated, needs api adapters to work with the current store backend. making the rest store lazy load and adapt the orient db objects still didn't work after two days of code investigation. So I dropped it as a #fail.

• jQuery/jsTree

I got jsTree with jQuery working quickly. Adapting the json from orient to json for jsTree was simple.

But: unlike dojo jsTree has no concept of a model. So the thought of propagating changes back in to the tree model looks like #pain and made me drop that too.

• homegrown/angular

Finally I gave myself a kick and grew my own tree with angular (using a recursive template and some css magic). And although I'm a javascript beginner and had little to no idea about angular concepts I got a working tree in less than two hours. I wrapped angulars resource in a service that wraps the orient objects with stuff needed for the tree and rendered the tree with a template recursion. It was so simple.

Conclusion

I didn't look too deep into backbone. Dojo seems a little over-engineered and not consistent in its development state. jQuery is nice sugar, but its not a serious programming framework. I think I fell in love with angular. 

Code:
https://github.com/eiswind/angular-orient-tree
https://github.com/eiswind/jstree-orient

A human-readable jackrabbit persistence manager prototype for orientdb

After working with jackrabbit for a while, I still and always wondered about the database persistence managers that jackrabbit provides. Storing the node serialized in a blob always seemed like a little perversion when using he concepts of a database.

Some while ago I just thought wether I could do that in a more "database" way. The idea was to use orientdb, as it stores documents (nodes) as well as a graph (the jcr tree). Jut to see if I can do it, I wrote a functional, test-passing prototype that stores the node in a human readable orientdb document, and persists the child relations as edges in the graph.

This has some limitations, as jackrabbit will still access only one node at a time, being able to traverse the graph at the storage level is simply not intended by the whole api. But it works, it's readable, can be modified at the db level easily.

You can grab the code at https://github.com/eiswind/jackrabbit-orient

Thymeleaf & Magnolia: a prototype

I've been working with magnolia for a while now, and I tend to like it's simplicity. But I don't like freemarker and even less JSP's. So I tried to integrate thymeleaf with magnolia, which wasn't as straightforward as expected.

Magnolias rendering engine API is based on working on a character stream for creating it's output. It does so when including areas & components, which didn't work wout with thymeleaf, that does includes based on it's internal DOM representation. So what I've created by now is a little hackish, I started with thymeleaf's include processor and mimik'ed the spring controller invocation from blossom and provided the magnolia content/context objects locally to the dom for rendering.

It's not very beautyful, as I had to copy some code fragments from magnolia and spring (cruel final and private api), but it's working like a charm.

You can find the code on github, should be a good starting point if you want to use thymeleaf with magnolia.
https://github.com/eiswind/magnolia-blossom-thymeleaf-proto