[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: pagestyles branch
From:       Thomas Zander <zander () kde ! org>
Date:       2008-08-17 10:20:37
Message-ID: 200808171220.41824.zander () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Saturday 16. August 2008 23:59:01 Sebastian Sauer wrote:
> > I don't see a problem with that scripting code calling relayout after it
> > has altered the data that requires a relayout.
> > This is a common way that other APis do this too.
>
> hmmm... relayout() should be done implicit if required like now cause else
> it's to easy to miss that and deal with all kind of weird/expired things
> that can lead to crashes then.
> means; model should take care of updating it's data if needed. view should
> not have to deal with that like at each mv(c) (even interview does it that
> way and provides hooks to react then on the changes and/or manipulate
> them).

The KWView usage is a bit confusing here; its not the view in our example 
because it also contains the controller code. (very strictly adhering to the 
MVC model tends to be impossible in practice[1] ;)
So the relayout is done from the controller code in my suggestion, which 
naturally makes a lot more sense then the request coming from the view.

Typically the actual data model does not emit signals on change, the 
controller code does this for the simple reason that it can know the context 
in which it is called.
What you see for example is that the QTextCursor has a beginEditBlock() and 
and endEditBlock().  If in the mean time the cursor did things that require 
relayout it will do that all in one go. My point here is that the controller 
code in the textCursor is the one that forces the relayout.

I currently see that we emit the relout signal at various times during loading 
(KWDLoader), not sure if something is connected, but I think we should just 
relayout once. So it surely is a sign in my eyes we should have the 
controller code initiate the action for changed data.

Hope that explains my train of thought a bit better :)


1) Its always funny to explain how flake works in terms of MVC since you can 
draw a picture of the framework in terms of MVC and then if you take another 
component into account (like the tools) you can draw a different picture 
where the pieces that were view before are the model now. :)
This is why I like the GoF design patterns having the introduction that 
patterns crystallize from design and refactoring, you see them everywhere and 
its useful to give them a name.
-- 
Thomas Zander

["signature.asc" (application/pgp-signature)]

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel


[prev in list] [next in list] [prev in thread] [next in thread]