Re: Design Question for Model and View

On May 30, 4:24 pm, r...@xxxxxxxxxxxxxxxxxx (Stefan Ram) wrote:
Jason Cavett <jason.cav...@xxxxxxxxx> writes:
The problem I run into (sort of a problem - I can easily hack around
it, but I'm wondering if there's a better way) is that it can be tough
getting information from the user when I need to accomplish a goal.

For example, a model operation might need a yes/no-information.

According to MVC, the model then would change a variable
»information_required« to be »true«. The View would be
subscribed to this as an observer and, thus, become notified
of the need. The view will create a yes/no-requester visible
to the user.

When the user decides to supply the information, the
controller will tell the model, which then will set
»information_required« to »false«, which will make the view to
close the requester.

the model notifies that view

The model must not know that there is a view, otherwise it
would be coupled to the view in a way that is not intended in
MVC.

It only knows that there are observers, so it ... (see above)

The view sets a flag in the main model notifying that it should
save.

In MVC, this would be the part of the »controller«.

But then, maybe you did not want to use MVC at all.

Is this a good way to go about it?

I can not determine, whether a strict and pure application
of MVC is advantageous in your case. I just wrote /how/ to
do it /if/ one wanted to do this.

Things might be simplified by a kind of »hierarchical MVC«,
where the confirmation-logic is contained entirely in the View
of the outer MVC, while it consists of an internal MVC
structure itself.

From a theoretical standpoint, this seems to be the best way to do
this. At the same time, it seems overly complicated. I could easily
implement something like this as the foundation for MVC is already
there. I'm just wondernig if this would be the best idea.

Also - the controller - that doesn't necessarily have to be a separate
class, does it? (I didn't think so, but I always get a bit confused
on the actual layout of the model, view and controller. It seems
other people do as well.)

Thanks

.

Relevant Pages

  • Re: GUI in C#
    ... decouple "event-driven programming" from the MVC concept. ... > the controller code sits in the U/I layer, ... even though the pattern is described that way. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: A few questions regarding MVC
    ... circa 1970 version or some modern variation? ... Using the classic MVC archticture as a guide to understanding modern ... controller can take the appropriate actions. ... views are observers <- model ...
    (comp.object)
  • Re: ttk::checkbutton - I think, its a bug
    ... If your implementation of MVC is a View that directly updates the Model, ... So you don't consider the bindings, and the code behind the bindings, ... to be considered a controller? ... what happens if you have a widget for the same data on several ...
    (comp.lang.tcl)
  • Re: MVC in C++
    ... Things are now flowing more along the classic MVC lines. ... > struct Observable ... > string version; ... In that case the Controller would trigger a model update *and it* could ...
    (comp.object)
  • Re: FrontController Design Pattern and Code Reuse
    ... If you can also include a bit of MVC at the same time you can ... "reused" more than any PHP program that exists or may ever exist. ... > the Business layer in 3 Tier) while Lister should exist as a Controller ...
    (comp.lang.php)