isis-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>
Subject Re: [DISCUSSION] Using a DSL as a pure object model (was: Mothballing SQL ObjectStore, auto-inferring JDO annotations from Isis conventions)
Date Thu, 12 Sep 2013 12:03:49 GMT

Horses for courses.  (British & Australian)
something that you say which means that it is important to choose suitable people for particular
activities because everyone has different skills Ah well, horses for courses. Just because
a plumber can mend your washing machine, it doesn't follow that he can mend your car as well.



I'm learning so much here! ... :-))




El 12/09/2013, a las 13:37, Dan Haywood <dan@haywood-associates.co.uk> escribió:

> On 12 September 2013 09:37, GESCONSULTOR - Óscar Bou <o.bou@gesconsultor.com
>> wrote:
> 
>> 
>> I 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).
>> 
>> 
> This is a useful categorization; thanks.
> 
> 
> 
>> 
>> 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.
>> 
>> 
> Yeah, on balance I agree with this.  I guess it's "horses for courses"
> 
> 
> 
> 
>> 
>> 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?
>> 
> 
> No, that wasn't an intention.  Rather, just a way to be able to express
> domain entities at an appropriate abstraction level.
> 
> (For runtime customization, I think that the entity should delegate out to
> a service; the service implementation might provide some sort of
> dynamic/script behaviour, eg the Drools engine).
> 
> 
> 
>> - 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?
>> 
>> 
> XText DSLs are external DSLs, so can be structured however we want, whereas
> Groovy DSLs are internal DSLs - ultimately they are Groovy programs.
> Obviously Groovy is very flexible, but that is a limiting factor.  Also,
> although Groovy does now have a statically typed option, I don't know
> whether an internal DSL in Groovy would play well with that.  In contrast,
> XText DSLs are fully statically typed.
> 
> There is also the IDE support that XText provides... code completion,
> refactor, outlines views, compile markers, quick fixes.  I suspect that the
> Groovy IDE for Eclipse would provide some limited support for this, but it
> clearly couldn't ever be as sophisticated as providing a quick fix hint,
> for example.
> 
> 
> Dan
> 
> 
> 
>> 
>> 
>> 
>> 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 <dan@haywood-associates.co.uk>
>> 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 <dan@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
>>>> 
>> 
>> 


Mime
View raw message