You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I switched the parser in our validator demo to "Ostrich", so that we would get more errors reported from the validator (e.g. cardinality) instead from the parser. However, when I changed a date to be incorrect, an exception was caught. It turns out (and this is by design at this point) that ITypedElement.value cannot represent incorrect values (e.g. when dealing with a date, the type has to be DateTime), so PocoElementNode's internal object ToITypedElementValue() crashes, as it actually tries to read the Value property of the poco, not the ObjectValue.
This is unnecessary: the user is passing a POCO to the validator (which can represent incorrect data), but it then crashes just because we do still need to feed tha validator an ITypedElement. This proves the point that we should move forward to using POCO's rather than ITypedelement and/or make it possible to feed original unparsed data via ITypedElement to the validator. Since that would violate the contract for ITypedElement.Value, it's not clear how we should do that.
But it is clear that our trick of wrapping POCO's in ITypedElement does still have its disadvantage.
The text was updated successfully, but these errors were encountered:
I switched the parser in our validator demo to "Ostrich", so that we would get more errors reported from the validator (e.g. cardinality) instead from the parser. However, when I changed a date to be incorrect, an exception was caught. It turns out (and this is by design at this point) that ITypedElement.value cannot represent incorrect values (e.g. when dealing with a date, the type has to be DateTime), so PocoElementNode's
internal object ToITypedElementValue()
crashes, as it actually tries to read theValue
property of the poco, not theObjectValue
.This is unnecessary: the user is passing a POCO to the validator (which can represent incorrect data), but it then crashes just because we do still need to feed tha validator an ITypedElement. This proves the point that we should move forward to using POCO's rather than ITypedelement and/or make it possible to feed original unparsed data via ITypedElement to the validator. Since that would violate the contract for ITypedElement.Value, it's not clear how we should do that.
But it is clear that our trick of wrapping POCO's in ITypedElement does still have its disadvantage.
The text was updated successfully, but these errors were encountered: