Hi Scott,
Sure. One thing to mention is that the CDateTime widget has a databinding IObservable implementation in its jface bundle. Met vriendelijke groet,
Wim
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: nebula-dev-bounces@xxxxxxxxxxx [mailto:nebula-dev-bounces@xxxxxxxxxxx]
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].
On Fri, Mar 30, 2012 at 8:09 PM, Scott Klein <Scott.Klein@xxxxxxxxxxxxxx> wrote:
Data Validation/Integrity - Proper design
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.
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!!
__________ Information from ESET NOD32 Antivirus, version of virus signature database 7014 (20120330) __________
The message was checked by ESET NOD32 Antivirus.
_______________________________________________
nebula-dev mailing list
nebula-dev@xxxxxxxxxxx
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
__________ Information from ESET NOD32 Antivirus, version of virus signature database 7014 (20120330) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
|