On Sun, 2007-08-05 at 04:24 +0200, Milosz Derezynski wrote:
> Just FWIW, can we agree on one meaning of "transactional"?
> For me, the fact that the model shouldn't have to know about the
> number of views showing it has nothing to do with transactionality:
>
> > there may be multiple views on the model, and when changing the
> model, one
> > should not be required to know about the number of views. excellent
> > point, end of story for me. it ought to be "transactional".
>
> I think the most sensible meaning is the one we e.g. know from SQL and
> which Kris mentioned: One atomic changeset which can be "committed" to
> the model in one run. (It can probably not be rolled back, or if it
> would be possible, then it'd be quite expensive, but that's not really
> the point anyway).
For me, what is important is that MVC is that what it is supposed to be:
-> View observes Model
And not:
-> Some extra code done by the application developer observes for
the View the Model, because the View can't cope with the actual
MVC paradigm.
The simplicity of MVC is also what makes it so useful. By assuming that
the application developer will "solve" all the problems that the normal
"View observes Model" solves (he has to reset the model, he has to reset
the view's state, he has to detect changes to the model, ...) you void
the simplicity.
If the view internally actually resets its model, then that's fine.
It's a complexity that got solved by the View and didn't have to be
solved by the application developer. If it's more easy for Kris to
internally swap the Model (reloading everything and recovering the
state, like sorting --in case of a sortable -- or selection details),
then that's fine from the application developer's point of view.
> As for the model-should-be-view-ignorant issues, they have nothing to
> do with transactions, but are just as valid concerns of course.
>
>
> On 8/5/07, Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx> wrote:
> On Sun, 2007-08-05 at 00:25 +0200, Philip Van Hoof wrote:
> > On Sat, 2007-08-04 at 16:51 -0400, Paul Davis wrote:
> > > On Sat, 2007-08-04 at 17:00 +0200, Philip Van Hoof wrote:
> > >
> > > > The model itself is the source. The view is just a
> viewer for it. The
> > > > source itself doesn't change. The content of the source
> changes. The
> > > > view, being an observer of the model in the MVC
> paradigm, should adapt
> > > > to the changes. It should not require a sudden set and
> unset of its
> > > > model.
> > >
> > > I'm a big user of MVC. Although on some level I agree with
> you, I would
> > > ask what the difference is between:
> > >
> > > void gtk_treeview_freeze (GtkTreeView* tv) {
> > > /* store model in tv, then unset */
> > > }
> > > void gtk_treeview_thaw (GtkTreeView* tv) {
> > > /* reset model in tv */
> > > }
> >
> > Owk .. it's a bit lengthy and there are a lot of "personal
> opinions
> > about MVC" embedded in this one:
>
> it didn't need to be so lengthy :) thats why i noted that i
> use MVC a
> *lot* myself. the key point you raise is one that i had
> forgotten: there
> may be multiple views on the model, and when changing the
> model, one
> should not be required to know about the number of views.
> excellent
> point, end of story for me. it ought to be "transactional".
>
> --p
>
>
>
> _______________________________________________
> gtk-list mailing list
> gtk-list@xxxxxxxxx
> http://mail.gnome.org/mailman/listinfo/gtk-list
>
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list@xxxxxxxxx
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
--
Philip Van Hoof, software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://www.pvanhoof.be/blog
_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-list
