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?

E.g.:
goToComputer(){
startUp() {
login(username:'user', passwort:'password')
}
startProgram(name:'thunderbird') {
readMails()
}
}

vs.

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

/authors
/stephen king
/books
/Misery


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

/authors
/stephen king
/books
/Misery
/categories
/Thriller
/Misery*
vs
/authors
/stephen king
/books
/Misery*
/categories
/Thriller
/books
/Misery*
/books
/Misery

(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.

    /authors
    /stephen king
    /books
    /Misery

    etc.
  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.


Solutions?

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