[
https://issues.apache.org/struts/browse/WW-1770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=43498#action_43498
]
Sami Dalouche commented on WW-1770:
-----------------------------------
I was thinking about this.. and actually, the idea should maybe be pushed even
further to really be able to bind data directly to rich domain objects.
If you consider a rich domain, what happens is that some objects are immutable,
others have more intelligent methods than plain setters, etc..
So, what happens after a while is that it is necessary to create Builder
objects that mirror the fields of the real objects and which are used to bind
the web forms.
The builders provide some kind of build() method that creates the real domain
object and the action can then process the data.
So, something smarter than providing better exception handling for setters
which throw exceptions would be to provide a kind of integrated Struts 2
'builder' framework that users can use to bind directly to their domain.
A completly fictional example to express my thoughts :
// in my action
@WebObjectBuilder(WebRichDomainObjectBuilder.class) // or whatever struts2 IoC
reference
setRichDomainObject(ComplexRichObject o) {..}
where WebRichDomainObjectBuilder could have to implement a build() method,
could be integrated to Struts2 validation mechanism, (pretty much like
VisitorFieldValidator already provides, but in an easier to use,
self-contained, component-oriented approach).
What do you think ?
> Better control over field conversion errors than invalid.fieldvalue.xxx
> -----------------------------------------------------------------------
>
> Key: WW-1770
> URL: https://issues.apache.org/struts/browse/WW-1770
> Project: Struts 2
> Issue Type: Improvement
> Affects Versions: 2.0.6
> Reporter: Sami Dalouche
> Priority: Minor
> Fix For: 2.1.x
>
>
> Any Application Design that follows a rich-domain paradigm (e.g. Domain
> Driven Design) will necessarily implement business validation rules in domain
> entities. Some Integrity-checking rules can be implemented as "throw new
> WhateverBusinessException()" right in the object mutators (aka setters) to
> avoid having an undefined object state.
> Since Struts2/XWork/OGNL is supposed to help binding data directly to domain
> entities, it seems natural to help the application report the correct errors
> to the user. However, if a setter throws an exception, the only customizable
> message is invalid.fieldvalue.xxx, which means that if the setter can throw
> 10 exceptions, only one generic message can be displayed to the user.
> As a result, it would be useful to be able to customize the error message
> using the exception thrown, and not just the field name Something such as :
> invalid.path.to.Exception.xxx
> where path.to.Exception is the FQ class name, and xxx is the field name.
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
