Aha. I actually had one of those links in my "to read" list -- probably should have done that a long time ago.
On first look this seems the way to go to finally rid myself of a variety of custom, home brew (aka ugly!) frameworks. Much appreciated, scott From: [email protected] [mailto:[email protected]] On Behalf Of Wim Jongman Sent: Friday, March 30, 2012 11:50 AM To: Nebula Dev Subject: Re: [nebula-dev] Control design discussion (CDateTime, FormattedText) Hi Scott, Interesting case.. I think you want to take a look at the databinding framework [1][2]. Best regards, Wim Jongman [1] http://www.vogella.de/articles/EclipseDataBinding/article.html#swtdatabinding_validation [2] http://wiki.eclipse.org/index.php/JFace_Data_Binding On Fri, Mar 30, 2012 at 8:09 PM, Scott Klein <[email protected]<mailto:[email protected]>> wrote: Data Validation/Integrity - Proper design Overview: My application requires, what I term, "Data Validation" which will not allow a user to enter data which does not fit specific parameters based on its application context. For example, a CDateTime that is asking for a Date of Birth may not want to allow future dates nor dates prior to, say, 1900. Or a FormattedText control asking for a body temperature may only be allowed to accept numeric entries in a given range ( 32 to 110 step by 0.5 -> which means 98.5 is fine, but 98.6 is not) In addition, my application must have, what I call, "Data Integrity" -- that is the data in the control (view) must always match the data in the model, and vise versa. The rule we currently live by is that the control must not "accept" data that is improper for that control in a given context - the "change" must not be accepted and the event must not be triggered by the control for invalid data, rather it should alert the user (somehow) and revert to the last valid value. Design Options: Obviously, there are several options to do this a few of which are: 1. Extend the control for yourself to include validation -- this can be tricky because you have to override very complicated methods in the parent and also you rely on the protected methods exposed 2. Have your listener validate the data before accepting it to your model -- this can be tricky because you do not always have access to the "interior" controls for things like "blinking" the control or setting alert colored backgrounds 3. Have the control itself accept "validation" rules, and only when these all pass will a data change be accepted and a "change" event triggered - this is a pretty big task as well given the complexity of some of these controls Given all of this, what is the recommended way to implement this, or other similar functionality for a Nebula control? I am open to changing my mindset on having the control do this for me, but if that were the case I would want a standard interface to utilize across multiple controls which allow the developer to perform specific "validate" and "invalidate" display functionality. Feedback is much appreciated!! scott __________ Information from ESET NOD32 Antivirus, version of virus signature database 7014 (20120330) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com _______________________________________________ nebula-dev mailing list [email protected]<mailto:[email protected]> https://dev.eclipse.org/mailman/listinfo/nebula-dev __________ Information from ESET NOD32 Antivirus, version of virus signature database 7014 (20120330) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
_______________________________________________ nebula-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/nebula-dev
