I know that no-one has replied on this (though last time we discussed it [2] there was some enthusiasm for the idea, so hopefully that still exists...), but at any rate, just wanted to talk some more about ways this could be implemented. I'm focussing here mostly on the developer experience.
~~~ Using XText [3], there are two main options. In both cases, the DSL would be as per [1], defining the structure of the entity. The difference is in where the imperative stuff (method bodies) go, and how they are written. Option 1: Customer.kemble - defines the structure CustomerLogic.java - is generated from the .kemble file, and holds all the supporting methods (validateFirstName() etc). The method bodies are written in Java. Option 2: Customer.kemble - defines the structure and also the behaviour. However, the method bodies are written not in java, but using XBase [4]. What that means in practical terms is that the method bodies would look the same as method bodies in XTend [5] (a separate general purpose language written using XBase). ~~~ Option 3, which would be Customer.kemble having only Java method bodies unfortunately isn't possible with XText. There are pros and cons to each. The benefit of option (1) is that method bodies are in Java, so no barrier there. The downside of option (1) is the difficulty of navigating between the Customer.kemble and CustomerLogic.java. Also there would be no automated refactoring of the .java file if the .kemble file is updated. The pros/cons for option (2) are the inverse. The benefit is refactoring and no navigation issues; the downside is a new expression language. Maurizio and I are currently off-list debating these options, but I'd really like to hear what others think (including option 0: don't bother...!) Cheers Dan [1] https://issues.apache.org/jira/browse/ISIS-369 [2] http://markmail.org/thread/sq2xbdkdoiaethao [3] http://www.eclipse.org/Xtext/ [4] http://wiki.eclipse.org/Xbase#Why_Xbase.3F [5] http://www.eclipse.org/xtend/documentation.html ~~~~~~~~~~~~~~~~~~ On 11 September 2013 08:04, Dan Haywood <d...@haywood-associates.co.uk>wrote: > On the "mothballing SQL OS" thread were were discussing the relative > merits or non-merits of an Isis domain model that has lots of JDO > annotations within it. One possible way forward is to use DataNucleus' > metadata API so that the DN metamodel is mostly built from the Isis > metadata. > > I'm still slightly uneasy about the > invisibility/opaqueness/difficult-to-debugness of that, but anyway... I > have a slightly different proposition: to offer instead a DSL for writing > Isis domain apps. > > In [1] we have a sketch for what such a DSL would look like. Maurizio and > I have been talking offlist about this, and doing a few little experiments. > Building this would be comparatively easy. > > [Aside: the DSL is called Kemble because Kemble is a village close to the > *source *of the River Thames/Isis. Good, huh?]. > > So, my proposition is as follows: > > - for those who want to work in a familiar environment, preserving any > existing skills in JDO (and one day JPA), then keep things as they are. > This is the "bare metal" view of an Isis domain model. > > - for those who want to work at the highest possible abstraction level, > let them work in Kemble. This would only support Isis annotations and > could use keywords to represent concepts such as bidirectional mapping. > The generated Java is easily viewable for debugging; this Java would have > the JDO annotations etc etc. > > I think that Maurizio (mostly) and I (a little) will be playing with XText > anyway, cos it's a lot of fun. But it might also be the right way to go > strategically to resolve the debate we've been having. > > Thoughts welcome > > Dan > > > > > [1] https://issues.apache.org/jira/browse/ISIS-369 >
