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="http://sling.apache.org/taglibs/sling/1.0"%>
<sling:defineobjects/>
<div class="blueprint detail">
<a href="">.details.html"><%= currentNode.getName() %></a>
<h2>Properties</h2>
<h2>Controls</h2>
<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()%>
<ul><%
while(result.hasNext()) {
Node n = result.nextNode();
%><li><%
out.flush();
sling.include(n.getPath() + ".overview.html");
%> </li><%
}
%>
</ul>
</div>
<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">
</form>
</div>


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", currentNode.name)
h2("Properties")
h2("Controls") {
ul(class:"List") {
result.each { node ->
//this is necessary: need to put the outer tags explicitely
mkp.yieldUnescaped "<li>"
sling.include(node.path)
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...