Not really so stupid. The default way would be to set the
errorString of the control:
myTextInput.errorString = "Enter something here dummy!";
This will automatically add the red border and display the red error
message when the cursor is over the control. To remove the border
and the message, simply clear the errorString.
myTextInput.errorString = "";
Bjorn, why so harsh? We all have to start somewhere.
-TH
--- In flexcoders@yahoogroups.com, "bjorn.schultheiss"
<[EMAIL PROTECTED]> wrote:
>
> You are correct,
>
> It is a bit of a stupid question.
>
> TextField.setStyle('borderColor', 0xFF0000);
>
> TextField.setStyle('borderThickness', 2);
>
> Alert.show('FIX THIS FORM');
>
> TextField.toolTip
>
> There are a heap of different ways....
>
> Personal Implementation
>
> --- In flexcoders@yahoogroups.com, "Douglas Knudsen"
> <douglasknudsen@> wrote:
> >
> > ok, stupid question, this is a great example, but how do you get
this to
> > utilise all those fancy vaildation messages in the Flex SDK. I'm
> talking
> > about the ones that change the control to red borders and the
> fly-out error
> > message.
> >
> > DK
> >
> > On 9/8/06, grahampengelly <graham@> wrote:
> > >
> > > Hi Bjorn
> > >
> > > Thanks for taking the time to throw some code into the
discussion. The
> > > solution I ended up implementing was similar to the one you
> suggest. In my
> > > case the validation was simple, the user either supplies a
number
> of answers
> > > to a question that is between the minimum and maximum allowed
or
> they don't.
> > > My point here is that the validation message to the user is
more
> or less
> > > predefined.
> > >
> > > In a more complicated scenario, say a name and address form,
it would
> > > appear the model would get messy. Just the name field might
have
> required,
> > > min max length and [a-z][A-Z] validation rules. Which of these
> rules is
> > > broken and on what field would need to be passed back to the
view
> if you
> > > say, wanted to display an instruction to the user or color the
> appropriate
> > > textfield. Having engaged in this discussion I think I have now
> come to a
> > > solution for scenarios like this that would maintain the
intent of
> the MVC
> > > pattern.
> > >
> > > On the model you would maintain a collection of objects such
as this:
> > >
> > > public class ValidationFailedInfo
> > > {
> > > private var _propertyName:String;
> > > private var _message:String;
> > >
> > > public function get propertyName():String
> > > {
> > > return _propertyName;
> > > }
> > >
> > > public function get message():String
> > > {
> > > return _message;
> > > }
> > >
> > > public function ValidationFailedInfo(message:String,
> > > propertyName:String)
> > > {
> > > _message = message;
> > > _propertyName = propertyName;
> > > }
> > > }
> > >
> > > That would be populated/cleared by a validate() function (not
> shown but it
> > > just applies your rules to the properties of the model). You
would
> also have
> > > a method such as:
> > >
> > > public function
> GetValidationMessages(propertyName:String):Array
> > > {
> > > validate();
> > > var messageArr:Array = new Array();
> > > var currValInfo:ValidationFailedInfo = null;
> > > for(var x:int = 0; x<_validationInfoList.length;
x++)
> > > {
> > > curValInfo =
> ValidationFailedInfo(_validationInfoList[x]);
> > > if(currValInfo.propertyName == propertyName)
> > > {
> > > messageArr.push(currValInfo.message);
> > > }
> > > }
> > > return messageArr;
> > > }
> > >
> > > You could use this to determine whether each field is valid
and if
> not why
> > > not. All of the validation rules would remain in the model as
> would the
> > > message strings that you return. If for example your
application
> supports 10
> > > languages, storing all of the language logic in the view would
be a
> > > maintenance nightmare wheras this would allow all of that to
stay
> in the
> > > model.
> > >
> > > Thanks for all of your contributions. Can I also take the
> opportunity to
> > > say that this is the most welcoming and active group that I
have
> > > participated in... Keep it up [image: :D]
> > >
> > > Graham
> > >
> > > --- In flexcoders@yahoogroups.com, "Bjorn Schultheiss"
> <bjorn.schultheiss@>
> > > wrote:
> > > >
> > > > Gladly,
> > > >
> > > > simple example.
> > > >
> > > > // view
> > > > <mx:Button label="submit" enabled="{model.formValidated}" />
> > > >
> > > > // model data Object
> > > > public function set username(value:String):void
> > > > {
> > > > _username = value;
> > > > validateForm()
> > > > }
> > > >
> > > > private function validateForm():void
> > > > {
> > > > if (_username != undefined)
> > > > formValidated = true;
> > > > }
> > > >
> > > > This is code i've just typed, but the principle remains the
same.
> > > > Data drives the view via dataBinding. There are alternatives
to
> the way
> > > you
> > > > would structure your models and views but the principle
remains the
> > > same.
> > > >
> > > >
> > > > Regards,
> > > >
> > > > Bjorn Schultheiss
> > > > Senior Flash Developer
> > > > QDC Technologies
> > > >
> > > >
> > > > _____
> > > >
> > > > From: flexcoders@yahoogroups.com
> [mailto:[EMAIL PROTECTED] On
> > > > Behalf Of grahampengelly
> > > > Sent: Friday, 8 September 2006 12:24 PM
> > > > To: flexcoders@yahoogroups.com
> > > > Subject: [flexcoders] Re: Cairngorm... Where should this go?
> > > >
> > > >
> > > >
> > > > Thanks all for the discussion...
> > > >
> > > > So it seems the consensus is the validation, from a pattern
> purist point
> > > of
> > > > view should sit in the model. Someone suggested a
model.isDataValid
> > > > property... This gives us an indication but how should we be
> > > communicating
> > > > back to the view which data it is that is invalid and what
is it
> that is
> > > > invalid about it? Should the model dispatch a data invalid
event
> that
> > > the
> > > > view acts upon or a checkValid function that returns the data
> required
> > > to
> > > > act?
> > > >
> > > > I know this is very much academic, particularly as since
posting
> > > originally,
> > > > I have implemented my validation that works perfectly well. I
> would be
> > > > interested to hear Bjorn how you get your validation
information
> back
> > > out of
> > > > the model to display it in the view.
> > > >
> > > > Cheers...
> > > >
> > > > Graham
> > > > Blog <http://goingspare.wordpress.com>
> > > >
> > > > --- In flexcoders@yahoogroups.com, "Bjorn Schultheiss"
> > > > bjorn.schultheiss@ wrote:
> > > > >
> > > > > I'm going to fly kick this thread quickly.
> > > > > Validation relates to model, quite simply.
> > > > >
> > > > >
> > > > > Regards,
> > > > >
> > > > > Bjorn Schultheiss
> > > > > Senior Flash Developer
> > > > > QDC Technologies
> > > > >
> > > > >
> > > > > _____
> > > > >
> > > > > From: flexcoders@yahoogroups.com
> [mailto:[EMAIL PROTECTED]
> > > On
> > > > > Behalf Of lostinrecursion
> > > > > Sent: Friday, 8 September 2006 6:28 AM
> > > > > To: flexcoders@yahoogroups.com
> > > > > Subject: [flexcoders] Re: Cairngorm... Where should this
go?
> > > > >
> > > > >
> > > > >
> > > > > Sorry but I have to interject on this. Intsrestingly
enough I
> asked a
> > > > > similar question some days ago and did not receive a
response
> from a
> > > > > design pettern perspective, but from a "what works"
> perspective. I am
> > > > > actually 85% of the tim all about what works, so not there
is
> anything
> > > > > wrong with it. But, I would like to hear some other
rhoughts on it
> > > > > since Validation is integral to just about every RIA that
> accepts data
> > > > > on the planet.
> > > > >
> > > > > In MVC, the Validators seem to be more of a middle ground
> issue. Since
> > > > > the Model contains the business logic and is fed data to
> process and
> > > > > the controller merely acts as waystation back and forth
from
> view to
> > > > > model, it would seem to me that there should almost be
another
> letter
> > > > > in MVC since validation doesn't really fit anywhere.
> > > > >
> > > > > However, it would seem to me that a Validation function
would be
> > > > > placed in the model itself. Since the view should only
query
> the model
> > > > > to get its current state and accept the user input, it
seems
> it should
> > > > > not be in the View to promote modularity.
{myModel.dataIsValid ==
> > > true}
> > > > >
> > > > > Because what if you wanted to add another View to the
> application??
> > > > > (As the OP mentioned) Seems to me like it would be
malformed
> in the
> > > View.
> > > > >
> > > > > Hmmmm... Perhaps MVCV - ;)
> > > > >
> > > >
> > >
> > >
> >
> >
> >
> > --
> > Douglas Knudsen
> > http://www.cubicleman.com
> > this is my signature, like it?
> >
>
--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/flexcoders/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/flexcoders/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
