Re. Re: Sculptor: How to implement validation in data transfer objects?

[Torsten Juergeleit]

>In trunk javax.validation api is used instead of hibernate validation. You can investigate how to use that and if it is possible to activate it for DTOs also.

Attached you can find a patch for the current trunk version of Sculptor. This patch provides the validation keywords for DTOs in Sculptors DSL, adds the corresponding DSL model transformations and activates the validation annotations for DTOs within the responsible the generator template.

/Torsten


On Wednesday, 17 August 2011 08:05:10 UTC+2, Patrik Nordwall wrote:

I guess that the reason is that hibernate validation is triggered when objects are persisted. I think it is possible to activate it in other ways also, but we haven't done that in sculptor. In trunk javax.validation api is used instead of hibernate validation. You can investigate how to use that and if it is possible to activate it for DTOs also.

/Patrik

On Tue, Aug 16, 2011 at 6:50 PM, Torsten Juergeleit <torsten.j...@gmail.com> wrote:

Sculptors declarative validation support for persistable domain objects is nice.
Unluckily this feature is not supported for data transfer objects. Btw. what's the reason for this?

Now I'm wondering how to add a similar kind of declarative validation to data transfer objects by leveraging Sculptor.

What approaches for client-side validation of sculptor-generated DTOs are you using?

/Torsten

[Patrik Nordwall]

Thanks for the contribution. Looks good. You are welcome to commit it yourself to trunk.

Ok?

Create jira ticket. The commit comment should start with the ticket number, CSC-XXX: Bla, bla.

/Patrik

[Patrik Nordwall]

Thought of one thing that must be adjusted. Since the annotations adds a dependency (javax.validation) on the client side there must be an option to not generate this for DTOs. 

Add a generator property for this:

generate.validation.annotation.dto=true

Being strict it should be false by default, but if we write about it in migration guide it's no problem to have it true by default.

Mention it in the jira ticket.

/Patrik

[Torsten Juergeleit]

>Thought of one thing that must be adjusted. Since the annotations adds a dependency (javax.validation) on the client side there must be an option to not generate this for DTOs. 

You're right. Attached you can find an updated version of the previous patch which provides this property and the corresponding helper methods.


Righ now I'm not familiar with Sculptors code base and Xtext in general yet. So I need some advice:

I'm not satisfied with my current approach of adding the DTO validation by copying the corresponding code from the existing DomainObject valdiation.
Xtext pushes the common validation attributes within the inheritance tree of the generated DSL meta model types up to DslAnyProperty.
I'm not sure if this effect is acceptable.

In Java I would refactor the common code fragments into a separate type (e.g. ValidatableProperty) and integrate it into the inheritance tree. I'm not familar with Xtext so I don't know if this approach is valid here too.


The same duplication is done with the "handleValidation()" methods in "DslTransformation.ext". I'm not satisfied with this redundant code as well.
Here would a new model type like ValidatableProperty help to eliminate the redundant code.


Refactoring the Xtext source code of Sculptors DSL needs more experience than I'm having right now.


What do you think?

/Torsten

[Patrik Nordwall]

Thanks for the contribution. I have applied the patch and committed to trunk.

http://fornax.itemis.de/jira/browse/CSC-654

It's not much to do about the duplication you mention. In the DSL the inheritance hierarchies are different for DTO and other DO. The duplication is a drawback of that. I don't wan't to manually adjust the dsl model, easier if it is completely generated by the xtext grammar.

/Patrik

2011/8/18 Torsten Juergeleit <torsten.j...@gmail.com>

[Torsten Juergeleit]

I tried this feature with the latest snapshot release (2.1.0-20110926.184716-5) and got the following exception:

[INFO] 3390 ERROR org.eclipse.xtend.XtendComponent - Error in Component  of type org.eclipse.xtend.XtendComponent:
[INFO]     EvaluationException : Couldn't find property 'assertTrue' for type sculptordsl::DslDtoAttribute
[INFO]     transformation::DslTransformation.ext[33742,20] on line 689 'attribute.assertTrue'         
[INFO]     transformation::DslTransformation.ext[24030,28] on line 514 'attribute.handleValidation()' 
[INFO]     transformation::DslTransformation.ext[15968,29] on line 337 'dslDto.attributes.transform()'
[INFO]     transformation::DslTransformation.ext[2015,32] on line 50 'module.domainObjects.transform()'
[INFO]     transformation::DslTransformation.ext[1227,25] on line 34 'allDslModules.transform()'      
[INFO]     nofile[0,47] on line 1 'transform((DslModel)model.first().eContainer)'                     


Are there any problems with the modifications for "Sculptordsl.xtext"?

/Torsten

/Patrik

2011/8/18 Torsten Juergeleit <torsten.j...@gmail.com>

/Patrik

[Patrik Nordwall]

I don't understand how that could be wrong? Are you running from maven, i.e. have you the latest snapshot of everything in classpath? I have deployed a new snapshot now. In case something was wrong with previous, due to the full disk.

/Patrik

[Torsten Juergeleit]

After deleting my local Maven repository this works now.
Thanx Patrik.
/Torsten

On Sunday, 2 October 2011 16:59:03 UTC+2, Patrik Nordwall wrote:

I don't understand how that could be wrong? Are you running from maven, i.e. have you the latest snapshot of everything in classpath? I have deployed a new snapshot now. In case something was wrong with previous, due to the full disk.

/Patrik

On Fri, Sep 30, 2011 at 6:29 PM, Torsten Juergeleit <torsten.j...@gmail.com> wrote:

I tried this feature with the latest snapshot release (2.1.0-20110926.184716-5) and got the following exception:

[INFO] 3390 ERROR org.eclipse.xtend.XtendComponent - Error in Component  of type org.eclipse.xtend.XtendComponent:
[INFO]     EvaluationException : Couldn't find property 'assertTrue' for type sculptordsl::DslDtoAttribute
[INFO]     transformation::DslTransformation.ext[33742,20] on line 689 'attribute.assertTrue'         
[INFO]     transformation::DslTransformation.ext[24030,28] on line 514 'attribute.handleValidation()' 
[INFO]     transformation::DslTransformation.ext[15968,29] on line 337 'dslDto.attributes.transform()'
[INFO]     transformation::DslTransformation.ext[2015,32] on line 50 'module.domainObjects.transform()'
[INFO]     transformation::DslTransformation.ext[1227,25] on line 34 'allDslModules.transform()'      
[INFO]     nofile[0,47] on line 1 'transform((DslModel)model.first().eContainer)'                     


Are there any problems with the modifications for "Sculptordsl.xtext"?

/Torsten

On Sunday, 21 August 2011 09:32:33 UTC+2, Patrik Nordwall wrote:

Thanks for the contribution. I have applied the patch and committed to trunk.

http://fornax.itemis.de/jira/browse/CSC-654

It's not much to do about the duplication you mention. In the DSL the inheritance hierarchies are different for DTO and other DO. The duplication is a drawback of that. I don't wan't to manually adjust the dsl model, easier if it is completely generated by the xtext grammar.

/Patrik

2011/8/18 Torsten Juergeleit <torste...@gmail.com>