Does IDataErrorInfo Require INotifyPropertyChanged

  • Thread starter Thread starter Jehu Galeahsa
  • Start date Start date
J

Jehu Galeahsa

Hello:

I implemented IDataErrorInfo using a simple Dictionary<string, string>
in a business object. What I noticed was that even after erroring a
"column" or setting the Error property, the ErrorProvider never
displayed the red exclamations.

So, I modified my code so that when an error was set a PropertyChanged
event was raised. This seems to be working... sorta.

Is raising PropertyChanged necessary? or should this be working
without it?

Thanks,
Travis
 
Jehu said:
Hello:

I implemented IDataErrorInfo using a simple Dictionary<string, string>
in a business object. What I noticed was that even after erroring a
"column" or setting the Error property, the ErrorProvider never
displayed the red exclamations.

So, I modified my code so that when an error was set a PropertyChanged
event was raised. This seems to be working... sorta.

Is raising PropertyChanged necessary? or should this be working
without it?

Thanks,
Travis
Click to expand...

Reading the MSDN entry on IDataErrorInfo, the interface seems to just
describe a dictionary like structure that /can/ provide extra
information regarding errors (or whatever string - string pair
information you would like, actually). It's a bit of weird framework
interface, if you ask me, especially given the documentation present.

Not being too familiar with both types, I'd say you have to implement
your own notification mechanism. Whether you do that through
implementing INotifyPropertyChanged or something else, is up to you of
course.
 
Reading the MSDN entry on IDataErrorInfo, the interface seems to just
describe a dictionary like structure that /can/ provide extra
information regarding errors (or whatever string - string pair
information you would like, actually). It's a bit of weird framework
interface, if you ask me, especially given the documentation present.

Not being too familiar with both types, I'd say you have to implement
your own notification mechanism. Whether you do that through
implementing INotifyPropertyChanged or something else, is up to you of
course.
Click to expand...

I was playing around yesterday. A lot of examples online show ways of
using this interface. Many of those examples are actually performing
validation within the indexer. I am not sure if that was the
intention, though.

Some further analysis shows that this interface is called during
validation (when a control loses focus). Needing to notify the user
interface of a change is similar to the need for
INotifyPropertyChanged - without it, the UI has no way of determining
whether it needs to update.
 
Jehu said:
I was playing around yesterday. A lot of examples online show ways of
using this interface. Many of those examples are actually performing
validation within the indexer. I am not sure if that was the
intention, though.
Click to expand...

From the samples I can find on the internet, nothing hints that
INotifyPropertyChanged is required. The samples I found just hook up the
various datasource properties, and everything just works (according to
the description on the sites that is, I didn't actually try them).

They all seem to do their business in the indexer indeed.
Some further analysis shows that this interface is called during
validation (when a control loses focus). Needing to notify the user
interface of a change is similar to the need for
INotifyPropertyChanged - without it, the UI has no way of determining
whether it needs to update.
Click to expand...

From what I found on the web, I can't say I like the concept of
IDataErrorInfo. It looks messy. Maybe it's practical in terms of use,
but I think it pollutes the model.

Whether or not to use INotifyPropertyChanged is still your own choice.
If you want an observer like pattern, then yes, INotifyPropertyChanged
(and INotifyCollectionChanged) is the way to go. But it is by no means
the only way to update a UI, nor necessarily the preferred way.

The job is to decide where the responsibility for updating the UI will
go. More likely than not, it will turn out to be a combination of
observer pattern (which could be INotifyPropertyChanged, and have part
of that responsibility in the UI through databinding), and some
controller or presenter.
 
 From the samples I can find on the internet, nothing hints that
INotifyPropertyChanged is required. The samples I found just hook up the
  various datasource properties, and everything just works (according to
the description on the sites that is, I didn't actually try them).

They all seem to do their business in the indexer indeed.


 From what I found on the web, I can't say I like the concept of
IDataErrorInfo. It looks messy. Maybe it's practical in terms of use,
but I think it pollutes the model.

Whether or not to use INotifyPropertyChanged is still your own choice.
If you want an observer like pattern, then yes, INotifyPropertyChanged
(and INotifyCollectionChanged) is the way to go. But it is by no means
the only way to update a UI, nor necessarily the preferred way.

The job is to decide where the responsibility for updating the UI will
go. More likely than not, it will turn out to be a combination of
observer pattern (which could be INotifyPropertyChanged, and have part
of that responsibility in the UI through databinding), and some
controller or presenter.
Click to expand...

Thanks for your reply. With a little sweat and luck I was able to get
this working. However, it has strange effects on the UI, such as the
ErrorProvider not blinking.

I have observed that MVC and binding don't work well together. Our
user interfaces allow a lot to be done between saves, which makes
tracking changes and validation major headaches. Oh well, I am going
to assume I have this working and move on. Next week we'll find
something else that doesn't work quite right. :-)
 
I have observed that MVC and binding don't work well together.
Click to expand...

MVC isn't a mature product.
One should carefully consider pros and cons before using MVC.
The cons are significant in the form of compromises for look and feel.
Personally, I feel the deciders in favour of MVC are IO and unit testing.
If you're expecting huge throughput for your site and you have 10 developers
of varied expertise and a procedure says you must unit test and continuous
build then you're in the land of MVC.
It is a strange land for many asp.net developers.
 
Back
Top