PureMVC Architects Lounge

Hi, I need to validate data (a string) which is send as notification body by several mediators. Should I do this validation in a command or in a proxy?

Doing it ina command would mean that the command has to execute other commands or send notifications depending on the validation result. Is this common practice?

Thanks,
Andreas

To paraphrase the poet Joyce Carol Oates, Where's the string coming from and where's it going?

Are you collecting it in a single view component and sending it to a service?

If so, the first place to validate is in the view component itself. Don't kick the apparatus into motion until you have a valid piece of data. If you're using Flex, you have some very good validation components and fierce regular expression handling if those aren't enough.

If the data could come from several sources, then you might want to put the validation into a command, but then you will have much more complexity involved in the handling of the validation result. As you indicated, you might need to send out several different notifications to be handled elsewhere in commands or mediators.

-=Cliff>

Thanks for your advice!

The data comes from several view components and the validation process involves sending different notifications depending on the result. If I put this into the view components, I would have to modify all of them if the validation changes - and I'm sure it will change =)

I wasn't sure if should put it into a command or if its the job of a proxy. But according to the second part of your answer, I'll put it into a command.

Here the second part of that question comes into play; where's it going?

A cardinal rule of RIA development is that you might use that domain model elsewhere. It should guide your every decision in architecture. Perhaps this is a Flex app for a browser, but later there is an accompanying AIR app for the desktop and later for mobile. All of which may use the same model, but have different business logic and use cases. 

If it's data that's going out the door to a service, and is not data 'made for the view by the view' then, you might be better off to put the data into the Proxies. This is domain logic, not business logic. Business logic (typically placed in commands) is tied to the actual application of the moment, not the (hopefully) portable domain. Business logic is not easily reused in other applications.

Regardless, when doing validation anywhere deeper in your app than on the actual view component boundary, the issue becomes updating the view with the result of validations. You don't want the user to fill in a form of rubbish, submit it then find out the first thing that's wrong with it and pop up an error box telling them what's wrong and asking them to enter it again if you can avoid it. With validators at the view, you can immediately mark the text input as invalid the second a bad character is typed.

So if your validation lives on the other boundary of the app, (or in the middle in a command), you need to set up a pathway of events flowing from the view component on each keystroke, to the mediator which plucks the necessary data for validation from the component and ships it off in a notification or passes it to a validation method on a proxy. The mediator needs to be able hear the result coming by note from a command or proxy, or perhaps from the result of the proxy validation method, and update the view component with the current validation status so that it can highlight the field in red or whatever.

-=Cliff>

Hi Cliff, thanks again for your answer.

Maybe "string" was a little bit misleading. Its not an input string from a text field. Actually the string is a path which is used for navigation inside the page. The validation checks if all pre-conditions for the requested content are met. After the validation it's not sent back to the mediator it comes from, but to other ones which are responsible for showing the content, updating SWFAddress ect.

In the scenario you described in your last post the validation should be in view component, no doubt. But in my case it rather is responsible for the page flow. Maybe I should have put more details in my earlier posts, I'm sorry.