You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@isis.apache.org by Dan Haywood <da...@haywood-associates.co.uk> on 2013/09/11 09:04:36 UTC
[DISCUSSION] Using a DSL as a pure object model (was: Mothballing SQL
ObjectStore, auto-inferring JDO annotations from Isis conventions)
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
On 10 September 2013 20:05, Dan Haywood <da...@haywood-associates.co.uk>wrote:
>
>
> On 10 September 2013 19:28, Kevin Meyer - KMZ <ke...@kmz.co.za> wrote:
>
>>
>> I would be interested in knowing if it is possible to use the DN meta
>> data API to allow the JDO data store to make intelligent guesses
>> (that'll generally be "right", or at least a default that is generally
>> useable).
>>
>
> Yes, I think that by and large that would be possible. Certainly, a lot
> of the Estatio entities are all very similar to each other.
>
> I could also imagine "profiles" whereby we map one way for a "typical"
> RDBMS setup, and a slightly different way to support Google App Engine.
> (Maurizio tells me off-list that this is working fine; he's in the middle
> of getting his committer perms sorted in order to do the necessary commit).
>
>
>>
>> Then, when the defaults are not good enough (some final deployment
>> tweaking would improve behaviour or performance), let the developer
>> provide JDO annotations as required.
>>
>>
> Yeah, I think that would be necessary.
>
>
>
>> Of course, some Isis annotations (e.g. @Optional) also impact on the
>> database (implicitly requiring "allowNulls = true") and there is possibly
>> no way around this (unless one of the defaults to the datastore is that
>> allowNulls is always true!)
>>
>>
> At the moment we have Isis recognizing @Column(allowsNull=true) to mean
> optional. But if we use the DN metadata API, then we could go the other
> way (ie use @Optional to setup the DN metamodel instead).
>
>
> So goal is to get the objectstore "working" as soon as possible with no
>> (or very few) data-store specific annotations on the POJOs.
>>
>>
> Very happy to support you on this Kevin. For myself, I shan't be putting
> any time into it; need to keep focussed on getting Estatio live.
>
>
>
>> So, the question is: Can the metadata API provide enough input to
>> DN that an introspector (using the Isis metamodel) can guess the
>> required DN metadata for entities and properties (single valued and
>> collections) if there are no annotations?
>>
>>
> To a large extent, yes. The main things we don't have are bidirectional
> relationships and inheritance mapping (roll-up vs table-per-type vs
> roll-down). For these I think we just recognize the JDO annotations.
>
>
>
>> I don't understand the relationship between JDO and DN, so I would
>> need to do a lot of research first.. ;)
>
>
>
> JDO is the API, DN is the implementation. (DN also supports the JPA API,
> so after we get this sorted out to our mutual satisfaction, we can go round
> the loop and look at JPA).
>
>
>
>> Perhaps a better understanding
>> would clarify why my goal is pointless (or impossible).
>>
>>
> It's doable. The question remains: do we expect our would-be users to
> learn the Isis conventions (and learn about its default mappings), or do we
> let them bring their existing JDO (and one day) JPA knowledge and then have
> Isis do "the right thing".
>
>
> Dan
>
>
>
Re: [DISCUSSION] Using a DSL as a pure object model (was: Mothballing SQL ObjectStore, auto-inferring JDO annotations from Isis conventions)
Posted by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>.
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 <da...@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 <da...@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
>>>>
>>
>>
Re: [DISCUSSION] Using a DSL as a pure object model (was: Mothballing
SQL ObjectStore, auto-inferring JDO annotations from Isis conventions)
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
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 <da...@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
> >>
>
>
Re: [DISCUSSION] Using a DSL as a pure object model (was: Mothballing SQL ObjectStore, auto-inferring JDO annotations from Isis conventions)
Posted by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>.
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 <da...@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 <da...@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
>>
Re: [DISCUSSION] Using a DSL as a pure object model (was: Mothballing SQL ObjectStore, auto-inferring JDO annotations from Isis conventions)
Posted by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>.
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 <da...@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 <da...@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
>>
Re: [DISCUSSION] Using a DSL as a pure object model (was: Mothballing
SQL ObjectStore, auto-inferring JDO annotations from Isis conventions)
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
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 <da...@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
>
Re: [DISCUSSION] Using a DSL as a pure object model (was: Mothballing
SQL ObjectStore, auto-inferring JDO annotations from Isis conventions)
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
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 <da...@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
>