MVC Structure - Need a little help.

[tom_w2000]

Hi jAQUAN,

That's great advice, thanks. As always your replies are clear and to the point, and I appreciate all the time you've given to this... very hard to find people who want to help anyone these days.

Sadly I have a habit of trying to tackle the most ambitious thing first, just the way I am I guess.

I think starting small in this instance is probably the way to go, as you said... as I think what has been driving me crazy the last few weeks is trying to imagine every scenario in my head without any real practice.

I will miss you're advice jAQUAN, but thanks as always... the world need people like you and marlo... more than it realizes it does.



Tom.

[jAQUAN]

Good luck Tom. On a parting note, I've purposely not suggested using a framework because they prevent you from gaining crucial skills. If you don't understand why a framework works, you'll never be able to troubleshoot a problem should you hit a wall. Total reliance on a framework pretty much destroys your learning curve and will actually prevent you from growing as a developer.
Once you've proved an understanding of MVC to yourself, you might want to look into using robotlegs.

[marlopax]

God's Word jAQUAN

Its very true for a developer to go indepth of the every structure before entering to use framework. Playing with individual objects, interacting with each other creating different views on fly and switching their functionality is the real depth to focus on OOP's world. Not event looking patterns tightly and formatively. There are many reasons to come out new creations. Observations needed to focus on the real purposes.

Once More I will Request to Tom to jot down his most resent thoughts of making apps after all this discussion, so that people will give more ways and needful information and the right directions of their best.



marlopax

[marlopax]

Updating thoughts will take ahead the discussion into more depth.



marlopax

[tom_w2000]

Hi JAQUAN,

Thanks for your last words. One very last thing I wanted to ask was regarding how Controllers interact with their views directly when the model doesn't need to be updated.

For example, if I clicked a movieclip inside a view and wanted that movieclip to change colour and then tween across the screen, or scale.. would I pass the movieclip inside the view to the controller and let the controller do the tweening and changing of the movieclip with code, or simply instruct the view from the controller to animate and change the movieclip, and include all the code and packages to do this inside the view?

Based on what I've read on the internet and my extensive reading, there seems to be much debate about this.
I am currently putting public setters on the view to manipulate components/movieclips inside the view from the controller. I am also putting all the code needed to tween view components/movieclips inside methods in the view, and then simply calling the view methods from the controller. Is this correct?

Also, seeing as the controller is usually created before the view, I am having some difficulty in finding a way to pass a view to a controller.. do I pass the view to the controller as a target object when the view delegates events to the controller? of should I simply set up a listener to the controller in the view, and call view methods based on dispatched events from the controller..

I hope you can help a little.. this must be more simple than it appears.. and there is nothing in OREILLY's book to explain how controllers update views directly without effecting the model..

Tom.

[jAQUAN]

This discussion has deviated enough from the original topic that it warrants a new thread. Just like good code, purpose should be compartmentalized.

Anyway, I mentioned earlier that events the model doesn't care about are typically handled wholly within the view in which they happened. I also cautioned you about falling too deeply in love with patterns. They are wonderful footholds for considering your solution, but you should always ask yourself if they are the best. Coming up for air would allow you contemplate the logic of communicating with the controller (or any external entity) at all. It's perfectly harmless to allow a view to handle everything in these cases.

Take the following scenario. We have a view that contains the UI for a filtered search for cars for sale. On the left we have check boxes for various categories: make, model, color, price etc. and on the right we have a big shiny search button. Until the user actually clicks search, no body else in the program gives a hoot what's going on but each check box needs be redrawn in its checked or unchecked states. Does it really makes sense to roundtrip each checkboxes click event through the controller when there's no meaningful data to report? The view is quite capable of keeping an internal list of what's checked and unchecked and telling each checkbox to draw itself in the appropriate state. Eventually when the search button is pressed, the view is also capable of packing up the information, attaching it to an aptly named event object and dispatching it. At that point the data is meaningful and a controller would create a command object that requested a search from a service who would report the results to whomever was concerned.

This is just one solution for one scenario, you might want to save the checked filters for the user so that they can return to the page later and pick up where they left off. In that case it might make sense to dispatch an event for each click so that the work can be saved and recalled on a repeat visit. This would also require a public function on the view so that it can be initialized to look just like it did at the end of the last session. Again, its ultimately up to you to decide what makes sense for your situation. Never add functionality early, if you haven't spec'd it out, don't build it.

Now as far as connecting controllers to views, consider the implications of both options. If a view had to know exactly who it was reporting to, you'd have to write code within the view that specifically addressed it. That would tightly couple the view to the controller and as we already know, tight coupling is bad. If one day you decided you wanted to handled the events from the view in a very different way, it would be difficult to simply write a new controller class. The view would not be very "black boxed". Its much more elegant to create the views and models (in any order) and pass them to new controllers. Views and Models never speak directly to each other, but a controller (command pattern or not) communicates with both, so logically it needs them to exist first.

[tom_w2000]

Hi Jaquan,

Sorry for not replying sooner. I just wanted to say thanks for all the time you've given to this forum (and to you Raj).

I am currently going over everything you and Marlopax have said, and am starting with slightly smaller ambitions in order to aid my understanding and learning curve.

Your information has been very helpful to my understanding..

Forever indebted,

Tom.