Home » Modeling » EMF » [DataBinding] Default validation in EMFUpdateValueStrategy
|
| Re: [DataBinding] Default validation in EMFUpdateValueStrategy [message #419195 is a reply to message #419190] |
Mon, 12 May 2008 14:18   |
 Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Ovidio,
Comments below.
Ovidio Mallo wrote:
> Hi all,
>
> I have noticed that when using an EMFUpdateValueStrategy the validation
> of standard Java types (String, int, Date, ...) is not automatically
> provided as is the case with the standard UpdateValueStrategy. This is
> because observable values for EMF EAttributes use the EMF feature as
> the value type instead of the actual attribute's Java type.
Yes. The feature encoding information that's very important, such as
the multiplicity. If the upper bound of the feature is > 1, then the
value must be a list of values where each item in the list is a value of
the feature's type.
>
> While I totally agree in using the EMF feature as the observable's value
> type, I would still like having the validation of standard Java types
> working out of the box.
I've not used data binding enough myself to know what's missing.
> One possible solution would be to overwrite
> UpdateValueStrategy#createValidator(Object fromType, Object toType)
> and if either fromType or toType is an EAttribute, extract its actual
> Java type and invoke super.createValidator(...) with the real Java types
> instead of the EMF features.
That sounds reasonable, but I was hoping that the failed attempt to
create an instance from a string using the data type's factory would
provide sufficient information. It's a bit tricky just to delegate to
super in general, because imagine I could have three different data
types for int: for hex, octal, and decimal representations.
>
> Would something like that make sense? Thanks for any feedback!
I can see it might make sense for specific cases, like EInt, and
EInteger, but it's obviously not okay to ignore the multiplicity and if
the data type is designed to do something other than the default string
encoding for the value, things would go astray.
What specifically is not working so nicely?
>
> Best regards,
> Ovidio
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [DataBinding] Default validation in EMFUpdateValueStrategy [message #419198 is a reply to message #419190] |
Mon, 12 May 2008 14:19 |
Eric Rizzo
Messages: 3070
Registered: July 2009 |
Senior Member |
|
|
Ovidio Mallo wrote:
> Hi all,
>
> I have noticed that when using an EMFUpdateValueStrategy the validation
> of standard Java types (String, int, Date, ...) is not automatically
> provided as is the case with the standard UpdateValueStrategy. This is
> because observable values for EMF EAttributes use the EMF feature as
> the value type instead of the actual attribute's Java type.
>
> While I totally agree in using the EMF feature as the observable's value
> type, I would still like having the validation of standard Java types
> working out of the box. One possible solution would be to overwrite
> UpdateValueStrategy#createValidator(Object fromType, Object toType)
> and if either fromType or toType is an EAttribute, extract its actual
> Java type and invoke super.createValidator(...) with the real Java types
> instead of the EMF features.
>
> Would something like that make sense? Thanks for any feedback!
That is exactly what I had to do to get around this problem in
conversion (which I think data binding handles similarly to validation).
I don't really agree with EMF's choice to not return the actual class to
getType() (I understand the reason, just don't agree that the potential
benefit [is there really any benefit?] should outweigh what seems to be
the by-far most common usage).
Anyway, you might be interested in this bug report I raised with a
lengthy discussion about how it is too difficult to override the default
conversions (it applies to validations, also):
https://bugs.eclipse.org/bugs/show_bug.cgi?id=203492
Hope this helps,
Eric
|
|
|
| Re: [DataBinding] Default validation in EMFUpdateValueStrategy [message #419199 is a reply to message #419198] |
Mon, 12 May 2008 14:21 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Eric,
Comments below.
Eric Rizzo wrote:
> Ovidio Mallo wrote:
>> Hi all,
>>
>> I have noticed that when using an EMFUpdateValueStrategy the validation
>> of standard Java types (String, int, Date, ...) is not automatically
>> provided as is the case with the standard UpdateValueStrategy. This is
>> because observable values for EMF EAttributes use the EMF feature as
>> the value type instead of the actual attribute's Java type.
>>
>> While I totally agree in using the EMF feature as the observable's value
>> type, I would still like having the validation of standard Java types
>> working out of the box. One possible solution would be to overwrite
>> UpdateValueStrategy#createValidator(Object fromType, Object toType)
>> and if either fromType or toType is an EAttribute, extract its actual
>> Java type and invoke super.createValidator(...) with the real Java types
>> instead of the EMF features.
>>
>> Would something like that make sense? Thanks for any feedback!
>
> That is exactly what I had to do to get around this problem in
> conversion (which I think data binding handles similarly to validation).
> I don't really agree with EMF's choice to not return the actual class
> to getType() (I understand the reason, just don't agree that the
> potential benefit [is there really any benefit?] should outweigh what
> seems to be the by-far most common usage).
As I explain in the other note, features have a multiplicity that must
be taken into account (is the value a list of integers, or just one?)
and the data type itself decides how the value is encoded (is it hex,
octal, or decimal?).
> Anyway, you might be interested in this bug report I raised with a
> lengthy discussion about how it is too difficult to override the
> default conversions (it applies to validations, also):
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=203492
>
> Hope this helps,
> Eric
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: [DataBinding] Default validation in EMFUpdateValueStrategy [message #419201 is a reply to message #419200] |
Mon, 12 May 2008 15:00 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Tom,
That's because I'm confusing the two things. :-P Probably that's
because of the "validators by converter" thing in findValidator blurs
the line a little too.
We probably should be hooking up EMF's validators here since data types
have very specific constraints that apply. For example, a simple type
in a schema with facets will have such constraints so the EDataType for
it can check them.
After a quick look, I must say I don't really understand the
fromType/toType thing. Given that I can validator whether a given int
value is actually valid according to the data type (the facet constraint
might indicate it's out of range say), how would I hook that up?
Do you have suggestions for how I could best make this more complete?
Tom Schindl wrote:
> [...]
>>> That is exactly what I had to do to get around this problem in
>>> conversion (which I think data binding handles similarly to
>>> validation).
>>> I don't really agree with EMF's choice to not return the actual
>>> class to getType() (I understand the reason, just don't agree that
>>> the potential benefit [is there really any benefit?] should outweigh
>>> what seems to be the by-far most common usage).
>> As I explain in the other note, features have a multiplicity that
>> must be taken into account (is the value a list of integers, or just
>> one?) and the data type itself decides how the value is encoded (is
>> it hex, octal, or decimal?).
>
> I don't know if I understand this correct but an integer internally is
> always an integer and how to present this to the user is defined by
> the converter. If you want to present it as a Hex-Value the converter
> transforms it to a Hex-String, ... .
>
> Tom
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: [DataBinding] Default validation in EMFUpdateValueStrategy [message #419218 is a reply to message #419195] |
Tue, 13 May 2008 12:39 |
Ovidio Mallo
Messages: 35
Registered: July 2009 |
Member |
|
|
Hi Ed,
thanks for your feedback. Some specific comments follow below.
Ed Merks wrote:
> Ovidio,
>
> Comments below.
>
> Ovidio Mallo wrote:
>> Hi all,
>>
>> I have noticed that when using an EMFUpdateValueStrategy the validation
>> of standard Java types (String, int, Date, ...) is not automatically
>> provided as is the case with the standard UpdateValueStrategy. This is
>> because observable values for EMF EAttributes use the EMF feature as
>> the value type instead of the actual attribute's Java type.
> Yes. The feature encoding information that's very important, such as
> the multiplicity. If the upper bound of the feature is > 1, then the
> value must be a list of values where each item in the list is a value of
> the feature's type.
>>
>> While I totally agree in using the EMF feature as the observable's value
>> type, I would still like having the validation of standard Java types
>> working out of the box.
> I've not used data binding enough myself to know what's missing.
>> One possible solution would be to overwrite
>> UpdateValueStrategy#createValidator(Object fromType, Object toType)
>> and if either fromType or toType is an EAttribute, extract its actual
>> Java type and invoke super.createValidator(...) with the real Java types
>> instead of the EMF features.
> That sounds reasonable, but I was hoping that the failed attempt to
> create an instance from a string using the data type's factory would
> provide sufficient information. It's a bit tricky just to delegate to
> super in general, because imagine I could have three different data
> types for int: for hex, octal, and decimal representations.
OK, you're totally right that, in general, it does not make sense to extract
the instance class of an EAttribute and use that to default a validator
as EDataTypes may contain much more information regarding the conversion than
the corresponding instance class (a Java class) does. I hadn't realized that as
I am rather new to EMF but now it seems pretty clear to me.
However, I still don't like the fact that an EMFUpdateValueStrategy does only
default a converter and not a validator since this means that the converter
will eventually be passed a wrong input. IMHO, this should never happen as an
appropriate validator should always avoid that.
Right now, if the converter is given a wrong input, it will fail by throwing
an Exception and the only reason why the whole thing still works is that the
ValueBinding class of the databinding framework catches the exception and
turns it into a "normal" error status (IStatus).
Essentially, I think it would be somewhat nicer and cleaner if the
EMFUpdateValueStrategy would also default a validator (which would probably
just delegate to the data type's conversion factory) as this would avoid
the actual converter failing by throwing an exception. Ideally, the validator
should also return a reasonable error status message which can directly
be displayed to the user (instead of the message of some Exception thrown
by the converter as is done right now).
>>
>> Would something like that make sense? Thanks for any feedback!
> I can see it might make sense for specific cases, like EInt, and
> EInteger, but it's obviously not okay to ignore the multiplicity and if
> the data type is designed to do something other than the default string
> encoding for the value, things would go astray.
Now, I totally agree, so sorry for my misleading comments and thanks again
for your helpful feedback!
>
> What specifically is not working so nicely?
>>
>> Best regards,
>> Ovidio
Best regards,
Ovidio
|
|
|
| Re: [DataBinding] Default validation in EMFUpdateValueStrategy [message #419219 is a reply to message #419198] |
Tue, 13 May 2008 12:44 |
Ovidio Mallo
Messages: 35
Registered: July 2009 |
Member |
|
|
Hi Eric,
thanks for the link to the bug report below. I had already come across it
and found it very interesting as I'm also not always happy with having the
default validation/conversion happening inside the UpdateValueStrategy
class.
Best regards,
Ovidio
Eric Rizzo wrote:
> Ovidio Mallo wrote:
>> Hi all,
>>
>> I have noticed that when using an EMFUpdateValueStrategy the validation
>> of standard Java types (String, int, Date, ...) is not automatically
>> provided as is the case with the standard UpdateValueStrategy. This is
>> because observable values for EMF EAttributes use the EMF feature as
>> the value type instead of the actual attribute's Java type.
>>
>> While I totally agree in using the EMF feature as the observable's value
>> type, I would still like having the validation of standard Java types
>> working out of the box. One possible solution would be to overwrite
>> UpdateValueStrategy#createValidator(Object fromType, Object toType)
>> and if either fromType or toType is an EAttribute, extract its actual
>> Java type and invoke super.createValidator(...) with the real Java types
>> instead of the EMF features.
>>
>> Would something like that make sense? Thanks for any feedback!
>
> That is exactly what I had to do to get around this problem in
> conversion (which I think data binding handles similarly to validation).
> I don't really agree with EMF's choice to not return the actual class to
> getType() (I understand the reason, just don't agree that the potential
> benefit [is there really any benefit?] should outweigh what seems to be
> the by-far most common usage).
> Anyway, you might be interested in this bug report I raised with a
> lengthy discussion about how it is too difficult to override the default
> conversions (it applies to validations, also):
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=203492
>
> Hope this helps,
> Eric
|
|
|
| Re: [DataBinding] Default validation in EMFUpdateValueStrategy [message #419223 is a reply to message #419218] |
Tue, 13 May 2008 14:55 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Ovidio,
Comments below.
Ovidio Mallo wrote:
> Hi Ed,
>
> thanks for your feedback. Some specific comments follow below.
>
> Ed Merks wrote:
>> Ovidio,
>>
>> Comments below.
>>
>> Ovidio Mallo wrote:
>>> Hi all,
>>>
>>> I have noticed that when using an EMFUpdateValueStrategy the validation
>>> of standard Java types (String, int, Date, ...) is not automatically
>>> provided as is the case with the standard UpdateValueStrategy. This is
>>> because observable values for EMF EAttributes use the EMF feature as
>>> the value type instead of the actual attribute's Java type.
>> Yes. The feature encoding information that's very important, such as
>> the multiplicity. If the upper bound of the feature is > 1, then the
>> value must be a list of values where each item in the list is a value
>> of the feature's type.
>>>
>>> While I totally agree in using the EMF feature as the observable's
>>> value
>>> type, I would still like having the validation of standard Java types
>>> working out of the box.
>> I've not used data binding enough myself to know what's missing.
>>> One possible solution would be to overwrite
>>> UpdateValueStrategy#createValidator(Object fromType, Object toType)
>>> and if either fromType or toType is an EAttribute, extract its actual
>>> Java type and invoke super.createValidator(...) with the real Java
>>> types
>>> instead of the EMF features.
>> That sounds reasonable, but I was hoping that the failed attempt to
>> create an instance from a string using the data type's factory would
>> provide sufficient information. It's a bit tricky just to delegate
>> to super in general, because imagine I could have three different
>> data types for int: for hex, octal, and decimal representations.
> OK, you're totally right that, in general, it does not make sense to
> extract
> the instance class of an EAttribute and use that to default a validator
> as EDataTypes may contain much more information regarding the
> conversion than
> the corresponding instance class (a Java class) does. I hadn't
> realized that as
> I am rather new to EMF but now it seems pretty clear to me.
>
> However, I still don't like the fact that an EMFUpdateValueStrategy
> does only
> default a converter and not a validator since this means that the
> converter
> will eventually be passed a wrong input. IMHO, this should never
> happen as an
> appropriate validator should always avoid that.
> Right now, if the converter is given a wrong input, it will fail by
> throwing
> an Exception and the only reason why the whole thing still works is
> that the
> ValueBinding class of the databinding framework catches the exception and
> turns it into a "normal" error status (IStatus).
That's kind of the intent though... I suppose the error message isn't
always ideal...
>
> Essentially, I think it would be somewhat nicer and cleaner if the
> EMFUpdateValueStrategy would also default a validator (which would
> probably
> just delegate to the data type's conversion factory) as this would avoid
> the actual converter failing by throwing an exception.
I see. I don't really understand the from/to thing in the validator
though...
> Ideally, the validator
> should also return a reasonable error status message which can directly
> be displayed to the user (instead of the message of some Exception thrown
> by the converter as is done right now).
It seems to me there are two aspects, at least from an EMF point of
view. One is problems with converting the string to a value of the
type, and the other validating that the value of that type conforms to
any constraints that might apply for that value.
>
>>>
>>> Would something like that make sense? Thanks for any feedback!
>> I can see it might make sense for specific cases, like EInt, and
>> EInteger, but it's obviously not okay to ignore the multiplicity and
>> if the data type is designed to do something other than the default
>> string encoding for the value, things would go astray.
> Now, I totally agree, so sorry for my misleading comments and thanks
> again
> for your helpful feedback!
I don't think your comments were misleading. I think some of the design
is a little confusing and not so well described...
>
>>
>> What specifically is not working so nicely?
>>>
>>> Best regards,
>>> Ovidio
>
> Best regards,
> Ovidio
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Fri Apr 19 06:01:20 GMT 2024
Powered by FUDForum. Page generated in 0.02404 seconds |
] 
Search
Help
Register
Login
Home
