Using mediators polymorphically on interface implementation
Woohoo! Learning opportunity! In other words, how the F$@*# do you do this?
I have a parent container of various components that house forms. I want to be able to have these components implement a IValidatable interface. Ideally, I would want to the mediator to implement the interface to keep my views fresh and clean as a whistle. So how would I operate on a view's mediator from its parent?
If it helps, the parent container represents a "viewstack" and I don't want to allow changing of the "viewstack's" index without validating the form on the current index/view.
Let me know if you need me to confuse you even further. ;-)
Comments are currently closed for this discussion. You can start a new one.
Support Staff 2 Posted by Stray on 02 Apr, 2011 11:44 AM
Check out 'injectViewAs' - the 3rd parameter in mediatorMap.mapView.
Does that do what you wanted?
Stray
3 Posted by Tony Smith on 04 Apr, 2011 10:35 PM
I don't think so. I check that out when I was researching and it didn't seem to fit. Here is the real situation: I have a views with forms. From another place in the application, I have a "next" button. However, I need to validate the from before letting the user continue. Say the view has two forms, each with an array of validators. I was looking for a way to validate any "active" forms before dispatching a context event for the "next" button click. So I thought I would loop over the views and cast them as something like IValidatable. But instead of having the view be IValidatable, in order to keep my view code clean, I wanted to cast the view's mediator as IValidatable.
Overall, I went another direction to solve the problem but I am still failing to find a solid solution. Managing navigation based on form validation results is proving to be very difficult. :-(
Thanks for your input though.
4 Posted by creynders on 05 Apr, 2011 07:15 AM
Sounds to me as a problem of architecture. You need to add a wrapping/decorating class (using composition or inheritance, whatever rocks your boat, but I'd definitely choose composition) to your forms and map the mediators to them, instead of the forms.
Something like this:
SomeForm
ValidatableSomeForm implements IValidator
ValidatableSomeFormMediator mapped to ValidatableSomeForm or you could map a mediator to the interface. Depends on whether you need to mediate all forms separately or individually.
You can go a few directions with this, but you understand where I'm going to with this, I hope.
5 Posted by Tony Smith on 05 Apr, 2011 02:10 PM
Architecture is not my strongest skill :-(. I think i understand what you are saying though. But it still looks like the code that implements the interface (properties, methods) would be in the view instead of the view's mediator. I guess I was really looking for a way to access a view's mediator from another mediator but as an interface. I know, not best practice. It is just that this form validation thing is driving fricken nuts. Every time I think I have a solution, I hit a brick wall. Part of the problem is determining what forms would be eligible for validation. Added or removed from stage? Shown or hidden? Existence? I know, this is a bigger question that can be answered here. Such a pain! So now I am working on the idea that a form must "register" it's validators with the model. I hate it but it might work.
Thanks
6 Posted by creynders on 05 Apr, 2011 05:37 PM
It's best practice to let the mediator be a middle man between the view and the framework. Ie. it shouldn't DO anything, but just pass data and events.
And it's certainly not best practice to have a direct dependency between mediators.
Obviously you do as you see fit, but it will muddle the framework and make things harder down the road.
It's a bit hard to define a better architecture w/o knowing the use case, but you should ask yourself the following question:
Is it necessary that your entire framework is dragged into the validation of these forms? In other words is it model-dependent validation? Because if it's simple data format validation (making sure a field contains a valid e-mail address, that all required fields are answered, ...) then it has no dependency on the framework and consequently should be left out of it entirely.
It's a typical mistake (one I make in every each project) to drag the framework into stuff it has no business in whatsoever.
For instance many times people handle the entire page navigation through the framework, while in many cases it's a strict view-thing and the framework should not be involved at all.
Tony Smith closed this discussion on 27 Apr, 2011 10:15 PM.