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 :D

Graham

--- In flexcoders@yahoogroups.com, "Bjorn Schultheiss" <[EMAIL PROTECTED]> 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 - ;)
> >
>
__._,_.___

--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com





SPONSORED LINKS
Software development tool Software development Software development services
Home design software Software development company


YAHOO! GROUPS LINKS




__,_._,___

Reply via email to