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

List:       koffice-devel
Subject:    Re: pagestyles branch
From:       Sebastian Sauer <mail () dipe ! org>
Date:       2008-08-17 21:33:58
Message-ID: 200808172333.58311.mail () dipe ! org
[Download RAW message or body]

On Sunday 17 August 2008, Thomas Zander wrote:
> 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.

absolute :)

> 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.

may depend on if the split model-controller is needed at all but that guess we 
are moving here into philosophic areas (imho such a split makes in most cases 
not really sense but that's probably related to my personal preference to 
keep the number of classes as small as possible).

> 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.

Guess I don't know enough about the KWDLoader but can imagine that we can 
optimize there :)

> 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 :)

y, much better though I still don't see the need for a "controller" for 
relayout but then if we may like to extend that logic in the future to 
provide more control over the relayout (as in what parts to relayout compared 
to just everything every time), then it would make lot of sense to move it 
out of kodocument.

> 1) Its always funny to explain how flake works in terms of MVC

eh, that's more about kodocument (include everybody top-down) vs koview 
(include everything that's there for display and user-interaction). Flake 
does mix it a bit more but is also more complex ;)

> 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. :)

For sure it depends on where you draw the border where in the case of  
KoDocument it's pretty simple most of the time. In the case of flake together 
with tools, layers, canvas and what not, it's probably a question of what 
depends on what (e.g. switching tools to prevent crashes in relayout does mix 
concepts but it still works fine even without tools and that's what counts).

> 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.

And can provide huge disadvantages too if I remember back at those rather 
large codebase I had to deal with at work last months. Overdesigned 
spagetti-code done object-orientated :)
_______________________________________________
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]