Hi, Dan. Yesterday was impossible to respond... and I participated in the previous debate.
UI think that we are considering 3 different use cases: 1. MIGRATE AN EXISTING JDO/JPA PROJECT TO ISIS I think it's a must. So the direct use of JDO or JPA annotations to derive from there all relevant Isis Facets shall be fully supported. 2. START A NEW ISIS APP USING EXISTING JDO/JPA KNOWLEDGE I think it's a must. If the previous one is implemented, is fully supported. 3. CREATE AN ISIS APP WITH JUST ISIS ANNOTATIONS FOR BEHAVIORAL FACETS Naming tables, fields, etc. should be a responsibility of the ORM, so no Isis annotations needed. But Managed Relationships (if implemented as having the "addTo/removeFrom" Isis templates), or Required Columns change behavior, and, as must have a corresponding Facet for propagating to the viewers at least, my view is that an Isis annotation would be needed (so the current one shouldn't be deprecated). If Isis annotations are present, they could be used also for updating the DN's metadata (the Kevin's viewpoint). Here I don't find anything in conflict with points 1 and 2, so they're not mutually exclusive. And if there are Isis and JDO/JPA annotations present (in the future can also be Bean Validation annotations and others) the only thing to consider is to detect if they are in conflict (you implemented that for the @Column annotation on previous commits). Regarding the Managed Relationships cited on previous emails, it should be a "special case", as the collections would be updated at the very moment of inserting an item, the expected behavior is not exactly the same as the DN one, which ONLY updates it when doing getContainer.flush(). A new Facet would be required, and it does not correspond exactly with the DN behavior, so perhaps it should be implemented on the CGLIB module? So, basically, I advocate just for having a corresponding Isis annotation for each Facet. Other ORM responsibilities not relevant for the Isis meta-model should not be replicated by Isis, IMHO. Regarding the DSL, I like the idea of having a simple one. My expertise is "near-0", but for clarifying the use-cases where we could use it, I should ask some questions: - Could it be used for scripting? For example, we want to "extend" or customize at runtime an Isis Domain model, or perhaps expose some Isis entities and "change" the behavior of some actions. Could it be done? Or it should be used just for writing and maintaining the domain in a whole? - I nearly always read about the advantages of using Groovy for writing DSLs on Java-based applications. As an example [4], but google'ing about "groovy + dsl" brings a lot of links. What advantages could we have in our applications by using the XText vs the Groovy approach? Until now, the only one we've used is for is the one used on JBoss Drools for writing Business Rules. I don't know nearly anything about the internals. Just posting here some links in the hope that can be relevant to expert's eyes: [2] Article explaining its purpose. [3] A simple project example. [4] A link to the DSL compiler source code. Thanks, Oscar [1] http://docs.codehaus.org/display/GROOVY/Writing+Domain-Specific+Languages [2] http://java.dzone.com/articles/externalizing-application [3] https://github.com/integrallis/drools-dsl [4] https://github.com/droolsjbpm/drools/tree/master/drools-compiler/src/main/java/org/drools/compiler El 12/09/2013, a las 09:42, Dan Haywood <[email protected]> escribió: > 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 <[email protected]>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 >>
