[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-16 21:59:01
Message-ID: 200808162359.01885.mail () dipe ! org
[Download RAW message or body]

On Saturday 16 August 2008, Thomas Zander wrote:
> On Saturday 16. August 2008 17:51:52 Sebastian Sauer wrote:
> > On Friday 15 August 2008, Pierre wrote:
> > > > As an added bonus, this makes unit testing the pagemanager a LOT
> > > > easier.
> > >
> > > Can't agree more, I'll look at this.
> >
> > hmmm... for what exactly is the pagemanager if not to outsource
> > everything related to pages from the doc?
>
> It is there to modularize page *data* and the related methods.  The page
> data is in the page manager (it managed the KWPage instances, see API doc).

ah, guess I got confused by the naming (*manager) then compared to the other 
DAO's (*data). Anyway, atm it's somewhat ugly since it's neither of them. 
Parts of the functionality are in the manager while others are in the 
document. Anyway, imho not that important atm.

> This makes it possible to instantiate a KWPageManager instance and unit
> test it without having a document instance.

that's where I am not sure about. Most of our unittests do test only parts of 
the functionality. E.g. the unittests in kotext to test mainly scribe what is 
just not enough / to limited. Same with the pagemanager-tests. I would rather 
like to have the whole stack from kwdocument down tested. But probably not 
that important atm too (though I remember that in the past year a lot of 
times the clear view-model split got broken by e.g. assuming there is always 
a statusbar or accessing the view's without checking if any are there, etc.).

> So, maybe my view of how to design is biased by me having designed for many
> years with unit testing in mind and thus you have a different way of doing
> it.  I'm certainly not going to say there is one correct way, just that
> this is how I designed it and this is how I'd like to see it in KWord for
> practical reasons.

y, makes sense.

> > Re view; the view's are *optional* what means, we can trust in them being
> > there and doing important things like forcing the relayout for us. We
> > should really try to keep the model (kwdocument) and the view (kwview)
> > separated here cause else we will break any possibility to run kword from
> > within the commandline and automate things using e.g. kross or other apps
> > that utilize kwdocument but don't provide a kwview.
>
> 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).
_______________________________________________
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]