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 [email protected], "Douglas Knudsen"
<[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 [email protected], "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: [email protected]
[mailto:[EMAIL PROTECTED] On
> > > Behalf Of grahampengelly
> > > Sent: Friday, 8 September 2006 12:24 PM
> > > To: [email protected]
> > > 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 [email protected], "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: [email protected]
[mailto:[EMAIL PROTECTED]
> > On
> > > > Behalf Of lostinrecursion
> > > > Sent: Friday, 8 September 2006 6:28 AM
> > > > To: [email protected]
> > > > 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/
