New concept

[PaloT]

Hello,
I was thinking/dreaming about one extension to DSL. Should we make new
keyword (e.g. annotate) which will allow as to generate ANY annotation
for objects? Examples:
Entity Test extends BasicTest annotate @Role("ROLE_TEST"),
@StatusField("status, mainStatus") {
Service TestService annotate @Behaviour("InStatusEngine")...

We should introduce annotate keywork to:
Entity
Property/Attribute
Service
Service methods
Service parameters
BasicValue

Than we should introduce many concepts with AOP which are easy to
handle and allow endless extensions.

What do you think about this?

Pavel

------------------------------------------------------------------------------
_______________________________________________
Fornax-developer mailing list
Fornax-developer@...
https://lists.sourceforge.net/lists/listinfo/fornax-developer

[Patrik Nordwall]

Sounds like a good idea. It adds a lot of freedom and easy customization to be able to override the built in annotations, such as JPA annotations, for special cases.

Please add tasks in Jira.

How should it look like in the DSL?

In Java, annotations are normally written before the element with @
It is always nice to use similar syntax.
We have already used @ to define reference to another domain object in the DSL (to differentiate it from an ordinary java class). Should we rename that to # ?

@TransactionAttribute(TransactionAttributeType.NEVER)
Service FooService {
    #Foo foo(String bar);
}


Entity Foo {
    @XmlElement
    String name
    @Transient
    - #Country country
}

It must be possible to define several annotations for an element.

One tricky thing is that the DSL elements are not one-to-one to java and it is often ambiguous where to place the annotation in the generated code. Do we need some kind of additional placement hint for the annotation?

Do we add to much power to the DSL? Is it possible to solve in some other other way?

/Patrik

PaloT wrote:

Hello,
I was thinking/dreaming about one extension to DSL. Should we make new
keyword (e.g. annotate) which will allow as to generate ANY annotation
for objects? Examples:
Entity Test extends BasicTest annotate @Role("ROLE_TEST"),
@StatusField("status, mainStatus") {
Service TestService annotate @Behaviour("InStatusEngine")...

We should introduce annotate keywork to:
Entity
Property/Attribute
Service
Service methods
Service parameters
BasicValue

Than we should introduce many concepts with AOP which are easy to
handle and allow endless extensions.

What do you think about this?

Pavel

------------------------------------------------------------------------------
_______________________________________________
Fornax-developer mailing list
[e-mail]
https://lists.sourceforge.net/lists/listinfo/fornax-developer

[Patrik Nordwall]

In previous reply I raised two concerns:

Patrik Nordwall wrote:

One tricky thing is that the DSL elements are not one-to-one to java and it is often ambiguous where to place the annotation in the generated code. Do we need some kind of additional placement hint for the annotation?

Do we add to much power to the DSL? Is it possible to solve in some other other way?

I think I have a better suggestion.
I the DSL we can add hint="...any string..."
The users can define what to generate using the ordinary oAW AOP mechanism.
An example:
    Entity Foo {
        String name hint="xml"
        -@Country country hint="transient"
    }

In SpecialCases.xpt
«AROUND templates::DomainObject::jpaAnnotations FOR Attribute»
    «IF hint="xml"»
        @javax.xml.bind.annotation.XmlElement(required=true«IF nullable», nillable=true«ENDIF»)
    «ENDIF»
«ENDAROUND»

«AROUND templates::DomainObject::oneReferenceJpaAnnotations FOR Reference»
    «IF hint="transient"»
        @javax.persistence.Transient
    «ELSE»
        «targetDef.proceed()»
    «ENDIF»
«ENDAROUND»

This is not limited to annotations. It is an useful improvement of existing customization mechanism.

We will add more "hook" definitions in the templates when requested, and we can initially make sure we have good hooks for typical annotations.

What do you think?

/Patrik

[PaloT]

I see, you are also solving problems during sleeping ;-).

This way we should avoid problems with class/package mapping. However
we have to find mechanism for parameterizing hints e.g.:
hit="xml(default='', nilIsEmpty=true),transient"

If we can use parameters in templates directly than is fine. Like:
 «AROUND templates::DomainObject::jpaAnnotations FOR Attribute»
    «IF hint="xml"»
        @javax.xml.bind.annotation.XmlElement(required=true«IF
getHintParam(hints, "xml", "default") != null»,
defaultValue=getHintParam(hints, "xml", "default")«ENDIF»)
        «targetDef.proceed()»
    «ENDIF»
 «ENDAROUND»

I really like your idea because with this we can have "high order
annotations" when hint on entity can change also generation of
attributes or associated entities.
Than we need only good documentation for hints.

Pavel


On Tue, Jun 30, 2009 at 7:56 AM, Patrik
Nordwall<patrik.nordwall@...> wrote:

>
> In previous reply I raised two concerns:
>
> Patrik Nordwall wrote:
>>
>> One tricky thing is that the DSL elements are not one-to-one to java and
>> it is often ambiguous where to place the annotation in the generated code.
>> Do we need some kind of additional placement hint for the annotation?
>>
>> Do we add to much power to the DSL? Is it possible to solve in some other
>> other way?
>>
>
> I think I have a better suggestion.
> I the DSL we can add hint="...any string..."
> The users can define what to generate using the ordinary oAW AOP mechanism.
> An example:
>    Entity Foo {
>        String name hint="xml"
>        -@Country country hint="transient"
>    }
>
> In SpecialCases.xpt
> «AROUND templates::DomainObject::jpaAnnotations FOR Attribute»
>    «IF hint="xml"»
>        @javax.xml.bind.annotation.XmlElement(required=true«IF nullable»,
> nillable=true«ENDIF»)
>    «ENDIF»
> «ENDAROUND»
>
> «AROUND templates::DomainObject::oneReferenceJpaAnnotations FOR Reference»
>    «IF hint="transient"»
>        @javax.persistence.Transient
>    «ELSE»
>        «targetDef.proceed()»
>    «ENDIF»
> «ENDAROUND»
>
> This is not limited to annotations. It is an useful improvement of existing
> customization mechanism.
>
> We will add more "hook" definitions in the templates when requested, and we
> can initially make sure we have good hooks for typical annotations.
>
> What do you think?
>
> /Patrik
>
> --
> View this message in context: http://www.nabble.com/New-concept-tp24252062s17564p24266526.html
> Sent from the Fornax-Platform mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Fornax-developer mailing list
> Fornax-developer@...
> https://lists.sourceforge.net/lists/listinfo/fornax-developer
>

------------------------------------------------------------------------------
_______________________________________________
Fornax-developer mailing list
Fornax-developer@...
https://lists.sourceforge.net/lists/listinfo/fornax-developer

[Patrik Nordwall]

I thought of it as a plain string, but your idea with parameters and separators is even better.

We add convenient extension functions so it could look like this:

 «AROUND templates::DomainObject::jpaAnnotations FOR Attribute»
    «IF hasHint("xml")»
        @javax.xml.bind.annotation.XmlElement(required=true«IF
getHintParam("xml", "default") != null»,
defaultValue=getHintParam("xml", "default")«ENDIF»)
        «targetDef.proceed()»
    «ENDIF»
 «ENDAROUND»

Oliver has done parsing for the validation that we might be able to reuse.


/Patrik

[PaloT]

You are going to kill me, but I take that risk.

Aren't generator properties just Application level hints. What about:
Application myApp hint="GenerateGapClass" {...

And than of course:
Entity SomeEntity hint="NoGenerateGapClass" {...

Advantage should be to have "GenerateGapClass" for example on Module.

What about "scaffold"? Put in on Application and all Entities became scaffolded.

Isn't this same mechanism?

Should we build this extension functions some generic way that for
example when I define GenerateGapClass on Application and than I put
"NoGenerateGapClass" on Module and ask in entity template inside this
module hasHint("GenerateGapClass") it will return false?

Is it too far?

Pavel

On Tue, Jun 30, 2009 at 12:23 PM, Patrik
Nordwall<patrik.nordwall@...> wrote:

>
> I thought of it as a plain string, but your idea with parameters and
> separators is even better.
>
> We add convenient extension functions so it could look like this:
>
>  «AROUND templates::DomainObject::jpaAnnotations FOR Attribute»
>    «IF hasHint("xml")»
>        @javax.xml.bind.annotation.XmlElement(required=true«IF
> getHintParam("xml", "default") != null»,
> defaultValue=getHintParam("xml", "default")«ENDIF»)
>        «targetDef.proceed()»
>    «ENDIF»
>  «ENDAROUND»
>
> Oliver has done parsing for the validation that we might be able to reuse.
>
>
> /Patrik
> --
> View this message in context: http://www.nabble.com/New-concept-tp24252062s17564p24269489.html
> Sent from the Fornax-Platform mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Fornax-developer mailing list
> Fornax-developer@...
> https://lists.sourceforge.net/lists/listinfo/fornax-developer
>

------------------------------------------------------------------------------
_______________________________________________
Fornax-developer mailing list
Fornax-developer@...
https://lists.sourceforge.net/lists/listinfo/fornax-developer

[PaloT]

Here is some filter preventing dangerous words. I'm resending with
first sentence changed :-). Hope it get through now.
____________________________________________________________________

You are going to ki11 me, but I take that risk.

Aren't generator properties just Application level hints. What about:
Application myApp hint="GenerateGapClass" {...

And than of course:
Entity SomeEntity hint="NoGenerateGapClass" {...

Advantage should be to have "GenerateGapClass" for example on Module.

What about "scaffold"? Put in on Application and all Entities became scaffolded.

Isn't this same mechanism?

Should we build this extension functions some generic way that for
example when I define GenerateGapClass on Application and than I put
"NoGenerateGapClass" on Module and ask in entity template inside this
module hasHint("GenerateGapClass") it will return false?

Is it too far?

Pavel

On Tue, Jun 30, 2009 at 12:23 PM, Patrik
Nordwall<patrik.nordwall@...> wrote:

>
> I thought of it as a plain string, but your idea with parameters and
> separators is even better.
>
> We add convenient extension functions so it could look like this:
>
>  «AROUND templates::DomainObject::jpaAnnotations FOR Attribute»
>    «IF hasHint("xml")»
>        @javax.xml.bind.annotation.XmlElement(required=true«IF
> getHintParam("xml", "default") != null»,
> defaultValue=getHintParam("xml", "default")«ENDIF»)
>        «targetDef.proceed()»
>    «ENDIF»
>  «ENDAROUND»
>
> Oliver has done parsing for the validation that we might be able to reuse.
>
>
> /Patrik
> --
> View this message in context: http://www.nabble.com/New-concept-tp24252062s17564p24269489.html
> Sent from the Fornax-Platform mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Fornax-developer mailing list
> Fornax-developer@...
> https://lists.sourceforge.net/lists/listinfo/fornax-developer
>

------------------------------------------------------------------------------
_______________________________________________
Fornax-developer mailing list
Fornax-developer@...
https://lists.sourceforge.net/lists/listinfo/fornax-developer

[PaloT]

Hello,
aren't generator properties just Application level hints. What about:
Application myApp hint="GenerateGapClass" {...

And than of course:
Entity SomeEntity hint="NoGenerateGapClass" {...

Advantage should be to have "GenerateGapClass" for example on Module.

What about "scaffold"? Put in on Application and all Entities became scaffolded.

Isn't this same mechanism?

Should we build this extension functions some generic way that for
example when I define GenerateGapClass on Application and than I put
"NoGenerateGapClass" on Module and ask in entity template inside this
module hasHint("GenerateGapClass") it will return false?

Is it too far?

Pavel

On Tue, Jun 30, 2009 at 12:23 PM, Patrik
Nordwall<patrik.nordwall@...> wrote:

>
> I thought of it as a plain string, but your idea with parameters and
> separators is even better.
>
> We add convenient extension functions so it could look like this:
>
>  «AROUND templates::DomainObject::jpaAnnotations FOR Attribute»
>    «IF hasHint("xml")»
>        @javax.xml.bind.annotation.XmlElement(required=true«IF
> getHintParam("xml", "default") != null»,
> defaultValue=getHintParam("xml", "default")«ENDIF»)
>        «targetDef.proceed()»
>    «ENDIF»
>  «ENDAROUND»
>
> Oliver has done parsing for the validation that we might be able to reuse.
>
>
> /Patrik
> --
> View this message in context: http://www.nabble.com/New-concept-tp24252062s17564p24269489.html
> Sent from the Fornax-Platform mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Fornax-developer mailing list
> Fornax-developer@...
> https://lists.sourceforge.net/lists/listinfo/fornax-developer
>

------------------------------------------------------------------------------
_______________________________________________
Fornax-developer mailing list
Fornax-developer@...
https://lists.sourceforge.net/lists/listinfo/fornax-developer

[Patrik Nordwall]

Thanks for your ideas of improvement.

The intention of separating some customization to sculptor-generator.properties is that those properties are of global character and typically a technical design choice. They are normally not changed very often. I don't want to pollute model.btdesign with that kind of things, if I don't see a benefit in defining the property on a specific element. In best of worlds we would have even more DSLs with different responsibilities, linked together. E.g. database settings.

Your example with gap and scaffold on different levels is interesting, but I'm not sure if it is necessary to be able to define it on the Module level. It can also be confusing.

I like our previous conclusions about hint, but we should not use it for everything. It's purpose should be for customization of things that we have not been able to think of in advance (or have decided to only support through customization).

Let us implement the hint.
http://fornax.itemis.de/jira/browse/CSC-385

/Patrik

PaloT wrote:

Hello,
aren't generator properties just Application level hints. What about:
Application myApp hint="GenerateGapClass" {...

And than of course:
Entity SomeEntity hint="NoGenerateGapClass" {...

Advantage should be to have "GenerateGapClass" for example on Module.

What about "scaffold"? Put in on Application and all Entities became scaffolded.

Isn't this same mechanism?

Should we build this extension functions some generic way that for
example when I define GenerateGapClass on Application and than I put
"NoGenerateGapClass" on Module and ask in entity template inside this
module hasHint("GenerateGapClass") it will return false?

Is it too far?

Pavel