Donnerstag, 11. Dezember 2008

Apache Jackrabbit 1.5

Apache Jackrabbit was just released in version 1.5.

It looks that this is the "yes, we heard you" release, and is a huge jump forward for straightforward usage:
1) grab the jar-file
2) java -jar jackrabbit-....jar

And... there is no step 3 :).

I can't stress out enough the importance of such easy usage. While it already has been more or less simple to use Jackrabbit in, say, semi-professional setups, it now has the chance to hit the Main Street. "Want webdav? Well, you'd better use that jackrabbit thingie".

Ok, there may be some steps 3, but I will write about those later

Dienstag, 18. November 2008

Fun with annotations in Groovy/Griffon

The 1.6 version of Groovy seems to have full-fledged annotation support.

I took the occasion to finally learn to create some annotations on my own, and wrote an annotation which can be used in a Griffon model to give the controller some hints about how to best display its data.

I might have taken this a little bit too far, but it is also possible to declare strings in annotations which can later be evaluated.

Take this annotation as an example:

package annotations

import java.lang.annotation.*

public @interface TableModelInformation {
boolean displayed() default true
String displayName() default ""
String displayValue() default ""

This can be used in the model like this:

@TableModelInformation(displayValue='"Total Subprocesses: ${object.subprocesses.size()}"')
List subprocesses = []

(Note the weird string syntax: only double quotes (i.e. GString) are rightfully not interpreted as Strings. Furthermore it expects to receive an instance of the object in a variable named (tadaaa) "object".

This can be evaluated later in the controller:

return new GroovyShell(new Binding([object:object])).evaluate(object.class.getDeclaredField(field).getAnnotation(annotations.TableModelInformation).displayValue())

("object" and "field" are available in the context of the controller)

I am not sure how to optimize this code, especially the verbosity of annotation retrieval. It nevertheless is kind of funny to see groovy behavior in an (at least from me) unexpected way...

Freitag, 14. November 2008

Using ocmgroovy as Persistance Layer for Griffon

Griffon is a very interessting approach to create an agile and fun framework for building Swing applications. Currently a very shy version numeration is used (0.0.1 is current), but the whole package is built using large know-how.

One thing missing is the persistance layer. It is planned to use GORM, the hibernate-based layer of Grails.

This situation is an opportunity for ocmgroovy, my "framework"(*) for persisting Groovy objects into a JCR. While beeing a little ugly hack atm, the basic things like save() and get() seem to work, at least for my basic test cases.

Using ocmgroovy in grails is one annoying and 2 easy steps
  1. download ocmgroovy (either create the project via pom.xml or download all dependencies manually, which basically means to download all jackrabbit dependencies and xstream with its dependencies) and install it into {griffon_project}/lib directory
  2. declare the class to be persisted in {griffon_project/lifecycle}/Startup.groovy
  3. use it in your Griffon mvc

Step 2 looks like this

TransientRepository repository = new TransientRepository()
def session = repository.login(
new SimpleCredentials("threatmanagment", "password".toCharArray()))
JcrPersister strategy = new JcrPersister()
strategy.session = session
strategy.instanceRoot ="threatmanagment"

strategy.instrumentate(ThreatModel, "name")

This makes model classes ThreatModel and Dataflow persistable, i.e. currently mostly adds save() and get() methods to instance and class, respectively

And Step 3: about as easy

ThreatModel model = new ThreatModel("name": "TestModel")
ThreatModel model2 = ThreatModel.get("TestModel")

Please note that this is all very shaky at the moment (and therefore will create a black hole if you try it at home ;)), but might prove usable in the future.

I probably will release a PoC-project in the near future.

(*): ocmgroovy is very alpha and only used by myself. Therefore I do not consider this to be a framework

Mittwoch, 17. September 2008

Ditching Flex ... for now

Well, killing another fairie: I am dissing Flex for my pet project. There are several reasons:
  1. not too good Flex-Support in IDEA
  2. roundtrips are slow (create compile load)
  3. open source built on closed source doesn't work
  4. mxml: simply don't like those
  5. actionscript will not be the next ecmascript
  6. verbosity: too much to write while using MVC frameworks. Convention over Configuration is not there yet (?)
  7. HTTP support is kind of crippled
There are very good reasons to love Flex:
  1. the looks: I am no expert, but I got the feeling Flex just looks great out of the box
  2. components: component based UIs are great.
  3. event models
  4. ubiquity
I am sure that some of the points are due to the fact that I am a novice. I might come back to it, but now it is time to move on...

Donnerstag, 11. September 2008

An "in between" review of Sling

Now that I have been using Apache Sling for a pet project for some weeks now, I thought I could share some insights on it. The spaghetti western way, of course :). And all utterly subjective.

The Good

  • java -jar sling.jar -> http://localhost:8080 and dav://localhost:8080. This is fantastic.
  • Scripting support
  • REST: learn it the Sling way
  • webdav-support
  • A good community
  • best-of-breed technologies: OSGI (with Felix), JCR (with Jackrabbit)
  • JCR muscle flexing included: query, hierarchies, versioning
  • semi-structured data approach
  • it's fun

The Bad

Nothing bad, just great stuff with some edges:

The Ugly

  • Docu. Yeah I know. Is getting better, but should be more (please kill those "out of sync" pages)
  • After a fast start, there still is a learning curve (OSGI, REST, JCR, Maven, ...). Since these are hot topics anyway, this is no big deal, expect when you want something fast and nownownow :)
  • bootstrapping problem: despite the available help, I still did struggle with the question whether controls (scripts) or data should be created first. But this is just me, I guess :)
  • JCR Editor support: Days eclipse plugin is great, but unfortunately doesn't work on my Ubuntu-system
  • No out-of-the-box solution for rich applications (Except dojo, which is a beast on its own...)
All in all, Sling holds its head up high in a tight, competitive market. I am looking forward to do more stuff with it. The rough spots are being addressed, therefore I am positive and quite impressed. Most important thing now would be to flesh out the documentation....

update 13th Sept: The JCR Plugin for eclipse works after a fresh install, using Eclipse Ganymede and JCR Plugin version 3.6.6. Nice thing is, that Eclipse editors seem to work, e.g. when editing a HTML file. Have to check if this works with the groovy editor too ...

Sonntag, 7. September 2008

Flex/Flash wasn't made for REST

Well, it did take longer than others, but I finally got the message: Flash was not built with HTTP in mind. There are other issues flying around, but I think it all boils down to HTTP not being treated as first-class-citizen in the Flex/Flash environment.

I guess that the reason is a historical one: all remote connection protocols where proprietary, only in the last years Adobe opened itself a little bit (by releasing BlazeDS and open sourcing Flex). Now I think Adobe should go 2 steps further:
  1. implement standards (e.g. using HTTP how it was meant to be used)
  2. open source the whole stack
This is highly speculative, but perhaps the "Nay" to EcmaScript4 was due to the apparent closeness of the Flash ecosystem.

The saddest thing is that Flex is great! Real good default (looks nice out of the box), a real component model, just plain fun! Next stop: Dojo, I think ...

Donnerstag, 4. September 2008

Using Groovy Builders in Sling

Sling is a new approach in web development. It is, amongst other, a thin REST layer onto a JCR repository.

Sling also makes use of the language neutral scripting features of the java platform. Out of the box, several scripting languages are supported, like javascript and jruby. Since Groovy does have JSR 223 support, it is rather easy to create a groovy module to be used inside Sling. The only pity is that the Groovy Scripting Engine is not available via maven. See this Jira issue for some hints on creating a Groovy OSGI-module for Sling.

The thing I like most about Groovy is the real cool builder support. Using the MarkupBuilder, it is a snap to generate HTML or XML documents. I personally started to like MarkupBuilder syntax more than the templating approach.

The first time I saw something similar was at a demonstration of the excellent Seaside framework, where everything, including layout, is done in smalltalk. I am not sure wether the Groovy builders have been inspired by smalltalk or even Seaside, but both are sexy (I cannot speak for Seaside, haven't had the chance to play with it).

Anyways, on to some comparisons:

First a piece of jsp:

<%@page import="javax.jcr.query.Query"%>
<%@page import="javax.jcr.NodeIterator"%>
<%@page import="javax.jcr.Node"%>

<%@taglib prefix="sling" uri=""%>
<div class="blueprint detail">
<a href="">.details.html"><%= currentNode.getName() %></a>
<div id="List">
String q = "/jcr:root"+currentNode.getPath()+ "//*[@sling:resourceType='secmanagment/control']";
Query query = currentNode.getSession().getWorkspace().getQueryManager().createQuery(q, "xpath");
NodeIterator result = query.execute().getNodes();
%>Total <%=result.getSize()%>
while(result.hasNext()) {
Node n = result.nextNode();
sling.include(n.getPath() + ".overview.html");
%> </li><%
<div class="new">
<form action="">/controls/" method="POST">
<input type="text" name="name" value="Name">
<input type="hidden" name="sling:resourceType" value="secmanagment/control">
<input type="hidden" name="jcr:primaryType" value="nt:unstructured">
<input type="submit" value="create">

The same using Groovy with MarkupBuilder:

import groovy.xml.MarkupBuilder
import javax.jcr.query.Query
import javax.jcr.NodeIterator
import javax.jcr.Node

def q = "/jcr:root${currentNode.path}//*[@sling:resourceType='secmanagment/controls']";
def query = currentNode.session.workspace.queryManager.createQuery(q, "xpath");
def result = query.execute().nodes;

def builder = new MarkupBuilder(out)
builder.div(class:"blueprint detail") {
a(class:"blueprint details", href:"${currentNode.path}.details.html",
h2("Controls") {
ul(class:"List") {
result.each { node ->
//this is necessary: need to put the outer tags explicitely
mkp.yieldUnescaped "<li>"
mkp.yieldUnescaped "</li>"
h3("Create new")
div(class:"new") {
form(action:"${currentNode.path}/controls/", method:"POST") {
input(type:"text", name:"name", value:"Name")
input(type:"hidden", name:"sling:resourceType", value:"secmanagment/controls")
input(type:"hidden", name:"jcr:primaryType", value:"nt:unstructured")
input(type:"submit", value:"create")

While not being too different, those 2 samples (hopefully) show the usage of MarkupBuilders as valid alternative to a templating engine like jsp or gsp.

Dienstag, 19. August 2008

Oh what irony

So, after some years of java-programming I am getting used to dynamic, loosely typed languages, walk like a duck, y'know the drill.

Then enters Flex, enters AS3 and you know what? Explicit type declarations all the way (Not mandatory at all, but, you know, the compiler complains and stuff, so you better behave...)

This is not a problem and all, but something about the whole thing just made me smile :).

Montag, 11. August 2008

Controls Managment Project: Desiding for JCR/Sling

I am pondering for a half year on the idea of creating a piece of software which allows to manage (security) controls. There are several programs which allow to manage risks, but they assume the existence of a complete business services catalogue, broken down to hardware installations and software instances. Which I do not have atm.

What we do have is a set of controls, together with measures which describe how to implement those controls. The very basic model is:
1 control <-> m measures
1 measure <-> m implementations
A set of controls can be packet together in a workbook (haven't found a better word for it), which then can be assigned to someone (e.g. infrastructure guys) to define the implementations and their respective fulfillment.

This is all kind of vague, and it will probably will remain to be vague and not 100% defined in a strict (relational) domain model. It might for example be possible that some controls have more attributes than others. This is of course possible to be modeled with object compositions, but this is always the point where ORM starts to produce to much friction heat...

And this vagueness is imho a indicator for the need of a kind of semi structured data model. And this again is a good sign for using the data first approach: use the hierarchy as structuring model, and, well, see to more structure later. Maybe :). Therefore JCR is the weapon of choice....

As for Sling: I am still completely indecisive regarding the right client technology. Therefore it makes sense to have a REST-full interface to the business domain.

And Sling is sexy. Want to use it. 'Nuff said.

Next steps would be to answer some questions regarding Sling development. Currently I am scouting the message boards and the (way too sparse) documentation...
  • what's the best way to setup a Sling project? Use webdav for deployment?
  • How to backup/restore work?
  • How to design a JCR/Sling project? Top down? Paralell development of content model and functionality?
  • OSGI Best Practises
  • Which client-side technology to choose?

Dienstag, 5. August 2008

A first view at Sling

Sling is, well Yet Another Java Web Framework. But it adds some unique aspects, which might turn out to be a game changer:
  • it focuses on resources
  • it uses JCR as backend API (see jackrabbit as implementation)
  • it adds a thin layer of REST over JCR
  • it adds a dash of custom behavior by allowing dynamic languages (javascript, jruby, amongst others) to manipulate the REST request processing flow
  • it uses OSGI and its plugin-mechanism for more heavyweight and/or integration stuff
Besides being rather hype compliant (JCR, jruby, osgi, REST, thank you), the most interesting feature is that it's inspiring: it makes me think, and this in a constructive way. It kind of makes REST more approachable as an architectural style rather than a framework.

In a sense, it is like learning a new programming language: it opens your horizons, and questions some established thought routines.

Go ahead and check it out, it might trickle in...

Donnerstag, 10. Juli 2008

Grails, Flex, Soap

Today I have written a small PoC for Grails, Flex, SOAP. The initial task was (and still is) to find out which communication takes place in a Flex application.

Having no clue about Flex, a little understandig of Web Services and some minor understanding of Grails, it took me no more than 3 hours, including googling for web service usage in Flex and hunting of really stupid beginners bug.

This shows the real muscles of Grails and its really awesome plugin ecosystem.

grails create-app HelloFlex
cd HelloFlex
grails install-plugin flex
grails install-plugin xfire
grails create-service hello

Ok, everything needed is installed. 2 more things to do. in HelloFlex\services\HelloService.groovy:

class HelloService {
static expose=['xfire', 'flex-remoting']
def hello(String echo) { return echo.reverse() }

Note the use of expose: this service is both available via flex-remoting and via SOAP.

Second: create HelloFlex\web-app\test.mxml

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="">
<mx:operation name="hello" resultFormat="object"
import mx.controls.Alert;
[Bindable] private var passage:String;
private var options:Object = {"output-format": "plain-text"};
private function showResult(e:ResultEvent):void {
passage = userRequest.hello.lastResult;
private function send_data(input:String):void {

<mx:Text text="Echo Service" fontSize="16" fontWeight="bold"/>
<mx:Text text="Input" fontSize="12"/>
<mx:TextInput id="lookupPsg" textAlign="center"/>
<mx:Button label="Submit" click="send_data(lookupPsg.text)"/>
<mx:TextArea height="352" width="590" id="psg" text="{passage}" editable="false" fontSize="11"/>

(sorry for the mess, dunno how to format this better )

Hitting http://localhost:8080/HelloFlex/test.mxml displays the Flex application which uses SOAP protocol to consume the webservice.

Built on the shoulder of giants...

Update 12th Jul: Marcel Overdijk has already written a similar (well, actually better:)) example back in january.

Montag, 7. Juli 2008

Complex Swing Widgets, where art thou?

I am currently looking at creating something with a good ol' Swing interface.

A typical use case is the following scenario: a drag-and-droppable, sortable, pageable treetable with editable fields. Datatype aware editors, subtrees, master-detail views would be considered as added value. Such a treetable always

I did find the respective contributions of ext-js and jquery quite usable, albeit both need some customizing and/or (more or less) programming.

Coming back to Swing after several years, I naively expected to have a plethora of tree table implementations. Well, at the moment the only thing I have found is the SwingX Treetable. I will have a look at it in near future.

The question I ask myself is wether the HTML/js way is the way to go also for complex GUIs? I would still think that this platform has its limitations. But when I do see how sparse complex Swing widgets are, I really am unsure to use the right technology. Also things like autocompletion and other Web2.0 goodies should be easily available.

What is your opinion? Are there other Swing (or SWT, whatever) widgets collections with advanced components available? Does the Flex ecosystem provide more components?

update 9th Jul
Well, I guess I was right with not finding a Swing TreeTable: others have been waiting for it, too...

Sonntag, 29. Juni 2008

Comments on an interesting Wired Article

Chris Anderson has written an interesting article. While the title is rather placative ("The End of Thery") there are some thoughts worth beeing mentioned.

First "All models are wrong, and increasingly you can succeed without them". True, so true: models are just that: models. Also nothing against succeeding without them: data mining can be made without models.

But: is the Peta-Age really the end of theories? Interestingly, the article mentioned Craig Venters huge task to "sequence the air". This creates vast amounts data, and makes it almost ridiculously simple to find new species, or make correlations between species. To analyse this, to explain and understand it, there needs to be a model. Or doesn't it?

There is absolute nothing against the idea to look for unexpected correlations in huge datasets. But to make it really scientific, results or rather conclusions out of those results need to be falsificable. This falsification cannot be done in the dataset beeing used, but in a larger context. In a model, extrapolated from the dataset.

All mho...

Sonntag, 22. Juni 2008

ocmgroovy: Design Considerations

I have put some design consideration thoughts on the ocmgroovy site.
Feel free to comment on it, feedback is appreciated :).

Donnerstag, 12. Juni 2008

JCR Builder and JCR Query code now hosted on googlecode

The source code mentioned on this blog and on the Day dev-site is now hosted by the octopus. The project ist named "ocmgroovy" and you may expect more from that department in the near future.

Freitag, 6. Juni 2008

Groovy in Tapestry

Good news on the Tapestry front: Using groovy seems to be trivial in T5, according to H.L. Ship. Also the hint regarding Groovy becoming a first choice for Tapestry development is good to hear, and makes perfect sense!

This opens up a loads of options: Tapestry Builders (Tapestry is all about components ...), Usage of GORM as ORM layer, and all the goodness of the Groovy language at your fingertips. And a rock solid foundation like T5 to build applications upon. Wow.

No excuse to not try it out now, aaah so much to do, so little time ....

Montag, 26. Mai 2008

Groovy Builders, JCR (and MigLayout to the rescue)

I still am struggling with the JCR Query functionality. The whole idea of supporting both XPath and/or SQL-like syntax with some additions is, for me personally, rather challenging.

What to do? Either read docu, source code, create tests against the API or create a little GUI to test it with.

So, finally a good excuse to use the SwingBuilder. Beeing in dire need of a refresh on Swing (remember Java 1.2? Sheesh...) I stumbled upon MigLayout, which, kind of ironically, plays to my (meager) CSS know-how.

In order to have some test data available, I make use of a JCR Builder, which is described here. Groovy builders are a nice way to create hierarchical structures.

And this is what the GUI looks like:

import groovy.swing.SwingBuilder
import net.miginfocom.swing.MigLayout
import javax.swing.WindowConstants as WC
import javax.jcr.Repository
import org.apache.jackrabbit.core.TransientRepository
import javax.jcr.Session
import javax.jcr.SimpleCredentials
import ch.bluepenguin.jcr.groovy.builder.JcrBuilder
import javax.jcr.Workspace
import javax.jcr.query.QueryManager
import javax.jcr.query.Query
import javax.jcr.query.QueryResult
import javax.jcr.NodeIterator
import javax.jcr.ValueFormatException

class JCRGroovy implements Runnable {
def swing
def builder
Session session

public void run() {
swing = new SwingBuilder()

def queryTextField = swing.textArea(rows: 5, columns: 20)
queryTextField.text = "/jcr:root/blueprint/element(*,nt:unstructured)"
def valueTextField = swing.textArea(rows: 5, columns: 20)
def deleteTextField = swing.textField()
valueTextField.text =
"""blueprint() {
'type':'String']) {

deleteTextField.text ="/blueprint"
def resultTextField = swing.textArea(rows: 20, columns: 20)
Repository repository = new TransientRepository();
session = repository.login(new SimpleCredentials("username", "password".toCharArray()))
builder = new JcrBuilder()
builder.session = session
def gui = swing.frame(title: 'JCRQuery', defaultCloseOperation: WC.EXIT_ON_CLOSE) {
panel(layout: new MigLayout("fill")) {
widget(queryTextField, constraints: 'grow')
button(text: 'Query', constraints: 'span, aligny bottom', actionPerformed: {
resultTextField.text = queryAction(queryTextField.text, valueTextField.text)

widget(valueTextField, constraints: 'grow')
button(text: 'Create', constraints: 'span, aligny bottom', actionPerformed: {
resultTextField.text = createAction(valueTextField.text)
widget(deleteTextField, constraints: 'grow')

button(text: 'Delete', constraints: 'span, aligny bottom', actionPerformed: {
resultTextField.text = deleteAction(deleteTextField.text)
//label(text: 'Result')
scrollPane(constraints: 'wrap, grow') {{

def deleteAction(path) {
def results = ""
try {
def relPath = path.charAt(0) == '/' ? path.substring(1) : path
} catch (Exception e) {
results = e.toString()
return results

def queryAction(query, model) {
return executeQuery(query, printClosure)

def createAction(model) {
return buildModel(model)

def executeQuery(queryString, clos) {
def results = ""
try {
Workspace workspace = session.getWorkspace();
QueryManager qm = workspace.getQueryManager();
Query query = qm.createQuery(queryString, Query.XPATH);
QueryResult queryResult = query.execute();
NodeIterator nodeIterator = queryResult.nodes
for (n in nodeIterator) {
results +=
} catch (Exception e) {
results = e.toString()
return results

def printClosure = {node ->
def filler = " "
def results = ""
def to = node.depth
for (i in 0..(to-1)) filler += " "
results += filler + node.path + '\n' {property ->
try {
results += filler + " " + + ": " + property.string + '\n'
} catch(ValueFormatException wft) {
results += filler + " " + + ": (multiple values) \n"
return results

def removeClosure = {node ->
try {
if (node.path == "/" || node.path.startWith("/jcr:system")) {
println "wont remove root node"
} else {
} catch (Exception e) {}

def buildModel(model) {
GroovyShell groovyShell = new GroovyShell(new Binding([builder: builder]))
def modelScript = "builder." + model + "\{})"
return groovyShell.evaluate(modelScript)

So with some fumbling and trial & error a quick testing GUI to check for those JCR Query result. Of course, many things are open:
  • XPath queries support
  • use of a JTree instead of a dump message
  • "remember me" functionality
But it does the trick and demonstrates (once again) the real power of Groovy: while beeing a real cool language in itself, the usage of such powerfull tools as Jackrabbit and MigLayout are a breeze.

Dienstag, 20. Mai 2008

Nice one, indeed!

This made me smile: an entry on the ubuntu forums where someone asks for help with a webcam. Running under Windows Vista!

Now instead of "get the fuck out of here" someone mentioned a blog entry describing the problem. No bitching, no "read the fucking url", just beeing helpful. Of course, next entry hits back, but anyways... nice one!

Samstag, 26. April 2008

Canonical Form for Content Hierarchies

I am still pondering the question how exactly a content hierarchy should be modeled.

In a previous post I mention the possibility to declare authorization facts in a hierarchy. Something is still bugging me. Similar to programming, I think that some informations should be considered as cross-cutting concerns (or aspects). David's Model also has an example where authorization decisions have an impact on the model. This bugs me.

Somewhere there lurks the definition of a canonical representation of a content hierarchy:

basic, canonic, canonical: reduced to the simplest and most significant form possible without loss of generality, e.g. "a basic story line"; "a canonical syllable pattern"

This does sound right, doesn't it? A basic form of a content hierarchy should
  1. have the ideal relation of breadth vs. depth (ideal for the content model)
  2. only have the necessary node hierarchies/attributes
  3. still make sense
Those are non-mathematical requirements. The definition of a "Canonical Form" is interesting: while defining a canonical form via equivalency of a range of objects, it remains unspecific about how and when to define a canonical form:

A canonical form may simply be a convention, or a deep theorem.

The most important part is that other content hierarchies which are equivalent to this normal form are all connectible via an equivalence relation.

So the task at hand is to define a model which can act as a natural representation of the solution domain. As soon as this model is found, enhancements can be defined, while still being equivalent to the canonical form.

Well, still lots of questions open:
  • is it possible to define a canonical form for a specific use case (e.g. a blog)? Or would it be on an ad-hoc base?
  • what would the added benefit of such a canonical form be? The answer might be that extensions would be made vs. the canonical form. If the canonical form itself changes, it should trigger the changes to the other forms. Or at least depict the consequences the change in the canonical form has to equivalent representations
There might be another alternative to attack the problem of "hierarchy purpose overloading": as in programming, cross-cutting concerns might best be attacked by Orthogonalization. But this is another story ...

Samstag, 19. April 2008

RESTful Authorization Model Considerations

Considering the fact that URIs map to resources in a RESTful design, an authorization model almost automatically means a URI authorization model:
  • URIs are subject to authorization decisions
  • URIs offer a hierarchical authorization scheme
  • additionally, the limited list of allowed actions (verbs) leads way to a simple definition of ACLs (Access Control List), more or less the same as for file systems (read,write etc etc)
All in all this design is quite a non-event since it all fits together quite obviously.

One thing to consider is the old question of attribute based security decisions. A real world example is a blog where the author first checks the comments before publishing them. The attribute would be whether the comment already has been reviewed or not.

There are 2 possibilities to do do the authorization check in a declarative manner:
  1. either the ACL is attached directly to the resource
  2. or the resources (posts to be reviewed) are stored in another place of the URL hierarchy, e.g. '/comments/review' instead of '/comments'. The ACL would be attached to the directory instead of the resource itself (directory being a resource in its on right)
Both make use of ACL which looks something like this:

  • reviewer:read/write/delete (this allows to move)
  • author: read/write
Both possibilities have got their respective advantages. The second one seems to be easier, but has an impact on the hierarchy of resources. Is it allowed to define a resource hierarchy according to a cross-cutting concern like security?

Dienstag, 15. April 2008

Grails & GWT: an uneasy match?

Currently I am looking for the holy grail for AJAX-enabled Grails development. While trying out the excellent GWT-Plugin, something occurred to me: there are 3 programming languages involved: Groovy for Grails and Java/JavaScript for GWT.

One could argue that Javascript is transparent while using GWT. I would agree to a certain point with this, because I do not know how fast you need to touch Javascript in GWT.

Still this leaves me with 2 languages, namely Groovy and Java. While those 2 languages are very close together, this situation reminds me of a brilliant comic.

So why not use Groovy and Javascript, i.e. directly use one of the excellent Javascript frameworks? It does make more sense, since both are dynamic languages and both get more and more IDE support, namely in that one that costs some (you get the idea...).

Still: 2 languages is still one too much. Since Javascript is set on the client, this means to use, well Javascript on the server too. The guys creating the Sling framework for example do exactly this: it is up to you to use the Sling API on the client or server-side. I am not sure wether the code is 100% the same, but the general direction is given...

I still go with groovy, call me old-fashioned...


Maybe the strangest thing in GWT/Grails combination is the fact that everything sent to the client has to be IsSerializable. And has to be retrieved via a Service.

Contrasting this with the direct use of a JSON builder which creates a format directly consumable by all Javascript libraries. Nothing beats

render DomainClass.list as JSON

update 2:
The last "update" is of course complete crap, see the comments! I was still in a kind of prehistoric knowledge level, GWT-wise.

Samstag, 12. April 2008

Dont puck with me, Vista!

This is a rant. Nothing hightech in it, except Vista.

Lately, while writing an email, my MS Vista did a spontaneous reboot. With no apparent reason. Well, fact is, that this doesn't happen often. First I mainly game on MS Vista and do the real work on Ubuntu and second Vista is stable on my system.

Now, perhaps I haven't read a message or just clicked away a message box, might be. After reboot it was clear that some patches had to be applied. Ok, why reboot and stuff, yeah, whatever, it's Windows. But the fact that a system has got the balls to disrupt my work in such a manner is sign of a huge arrogance and a non-willingness to listen to and care for endusers. It is my computer and you don't do reboots without an explicit ok from me, dammit!

It is kind of saddening, because Vista is imho not as bad as it is being made. And securitywise it seems to play in a complete other league than the previous OS's from Redmond. But somehow Microsoft really manages to not be liked by me, although I really try hard :).

Mittwoch, 9. April 2008

Groovy as a First Programming Language

I am sure that this question has been raised more than once with other languages:
How does Groovy fit as first language to learn?
Same question could be asked for (J)Ruby, no doubt. It's too long ago for myself (yes, I admit that I started professionally with VB 5.0, so what? :)), but I do not see any showstoppers. Let's compare Groovy to other languages (purely subjective)
  • vs. C: C is cool for a look under the surface, but, ehm, as first language?
  • vs. C++: hardcore. Sooo hardcore. But I guess for someone who wants to get (at least) his/her hands dirty, it surely is a worthy choice.
  • vs. C#: I can't say much there, I do not know the language.
  • vs. FORTRAN: hey, don't dismiss that F-word :)
  • vs. Smalltalk: Smalltalk still seems to be one of the cleanest OO-language, and using something like Squeak, why not? Problem there is imho the transition to production
  • vs. Java: well, tough call. Java has got one big beginners friend: the compiler. I think this outweights the advantage that Groovy the language has over Java. On the other hand, it might be instructive to learn how to test a program the same time as writing the program itself. Also: too much IDE-help might be wrong at the beginning
I might test it with a workmate very soon. Have to check that Fortran-Compiler ...

Freitag, 28. März 2008

Builder and DSLs

Naive Question:

If builders allow to define DSLs, and DSL are languages, what is best practise for defining the grammar of this languages?
Or even more naively: when to use verbs, when to use nouns?

startUp() {
login(username:'user', passwort:'password')
startProgram(name:'thunderbird') {


computer(action: 'goto'){
computer(action: 'startup') {
loginscreen(action: 'enter username', username: 'user')
loginscreen(action: 'enter password', username: 'password')
loginscreen(action: 'enter')
computer(action: 'startProgram') {
and so on. Of course, it is obvious that the later one is more verbose and needs a convention for the attributes (like "action attribute describes function to execute").

Maybe the best compromise is to use a way to differentiate between verbs and nouns, e.g. write nouns in uppercase.

A related question:

How should the syntax of a DSL be described?

For XML we have schemas, is there need for something like that for DSL? And if yes, how to describe it? BNF seems to be a choice, but when exactly is it needed? Is it overkill? Does it scale?

The reason for such unreflected questions: on the one hand the description of SwingBuilder, on the other hand the longish BNF description of JCR node types. With both I get the feeling that not much more is possible...

Samstag, 22. März 2008

From OR to CR modeling - Hierarchies

So in the previous post, I started to think about data models in a Content Repository and the differences between relational models and, well, what?

But first a disclaimer: I am no big content repository expert. So expect me to do some classic mistakes, and ask some rather naive questions.

Here be one:
Is a hierarchy imperative to content modeling with JCR?

My thought is that hierarchical modeling feels natural in JCR. The hierarchical structure is instrinsic to structures with nodes, parents and children. So the next question would be

How do you map the hierarchies of an existing relational model to a hierarchical one?

We have the classical example once again

class Author {
static hasMany = [ books : Book ]
String name
class Book {
static belongsTo = [author:Author]
String title
which maps naturally to

/stephen king

But what if there is another hierarchy, e.g.

class Author {
static hasMany = [ books : Book ]
String name
class Book {
static belongsTo = [author:Author, category: Category]
String title

class Category {
static hasMany = [ books : Book ]

Now the books suddenly are part of 2 hierarchies. How to model this? I currently see 2 possibilities

  1. Have one leading hierarchy
  2. Flat it out

/stephen king
/stephen king

(the * depicts a relation to a Node elsewhere)

Another solution would be to allow multiple dimensions, in which the objects can be stored (this is more or less the same as the "flat out" version, except that looking at the object always gives you the "real" one, and not the relation.

As I said, I am not an expert of data modeling.

Feel free to comment on it...

Ok, next post will be about Groovy/Grails again :) (yeah, with a dash of JCR in it)

Donnerstag, 20. März 2008

Transition from ORM to JCR modeling

I am currently thinking about using JCR as a Backend for Grails (or more generally Groovy). Graeme Rocher has made some great steps in creating a Grails plugin.

GORM is imho one of the best possibilities to define an ORM model, since it hides all technical aspects of the implementation and lets the developer describe the domain model in a clear an consistent way.

Therefore this clearness should still be around when using JCR as backend.

Take an Grails/GORM example:

class Author {
static hasMany = [ books : Book ]
String name
class Book {
static belongsTo = [author:Author]
String title

The dynamical nature of Grails adds the necessary properties, you could also write it as

class Author {
static hasMany = [ books : Book ]
String name
Set books
class Book {
static belongsTo = [author:Author]
Author author
String title
There are 2 aspects to this domain model
  1. object relations: an author has a set of books
  2. constraints: you have to make sure that a book really has an author (except when you define this property as nullable, which is also a contraint in this sense)
This simple domain model has got an interessting implication when mapping it to a repository:
  1. the one-to-many relation author vs. books would typically be mapped by a hierarchical manner, e.g.

    /stephen king

  2. the constraints, on the other hand would mean to add a structure to the repository by, e.g., defining node types. I think, that's what David means. Might be nice to have (I personally don't mind structure), but is not mandatory
Conclusion? I think what can be said is that thinking "data first" might lead to an ever more relaxed approach of defining domain models than Grails/GORM already has today ....

Montag, 17. März 2008

A Use Case for JCR

A creepy thing, this JCR stuff. Once into your head, you start to see possibilities. And the alternatives (good ol'e RDBMs, for example) start to look... bleak ... boring ... so 2004 ...

Imagine you are in responsibility of a, say, control system, with which different applications having impact on the books of your company have to answer to a catalogue of risk control questions.

So you are responsible for the move from excel sheet to web application. Ok, so you start designing your domain model, all easy, all smooth. But wait: those controls have got the tendency to change, but the respective application owner have to answer to a certain version of your control catalogue. Additional feedback for proposed changes to the controls have to be kept in a separate branch of your risk catalogue, which then will be merged with the trunk of your catalogue.

You see where it is going. This describes only one aspect of the JCR API, which simply is included. Of course you could implement it by using another repository product (e.g. svn), but this is not the point. The point is that the need for a content repository is inherent to several reappearing use cases for software systems design.

Samstag, 15. März 2008

So many things to do, so little time?

The java ecosystem has a huge selections of mainly open source web frameworks.

What I am wondering is: when does the sheer amount of options to choose from have an impact
  • on the developer
  • on the respecitve web frameworks
  • on the ecosystem itself?
I remember having read about studies where putting more than 5 (?) variations of the same product has a counterproductive impact on sales figures, at least for daily goods.

The same should be valid for the developer who has to choose a web framework for the next project. And it is not only the developer: even an advanced managment can loose patience when the 10th web framework is presented as "The Solution". So the impact might be on the ecosystem itself, insofar as that ASP.NET still does not have too many alternatives (things are changing there too)

Another point to consider is the fact that time is sparse also for potential web framework developers and community members. The abundance of high quality php-based CMS is a contradiction to this argument, so this might not be too big an issue.


Hard to say. It's hard to imagine, as example, to merge Tapestry and Wicket. Perhaps the Spring way to divide an conquer might be a solution. A good example is Grails, which allows to use Wicket as presentation framework. On the other hand this leads to even more choices: use Wicket OR Grails changes to use Wicket AND/OR Grails.

Hello World!

Yet another blogger, yet another perspective on high tech trends.

Currently on my radar:

  • JCR : Content repositories
  • Groovy/Grails: Next-Gen JVM Language/Web Framework