First of all, my ‘views’ exist of various classes, not one as in the
example. Some of them are only instantiated once (on initiation; the
Notebook for example), other are created on user interaction
(NotebookPage for example). So should I add all these classes to my
‘main view’ class, and have methods for NotebookPage
instantiation/creation? Or is there another way?
make triads for each reasonably complex component (a model view and presenter for each component)
encapsulate as much as possible, expose only the minimum, only what you need too.
Secondly, in the example the presenter.isListening variable is never
set to False, so I don’t understand why he tests against it?
actually it is set to False immediately after it passes the testing… this is done to prevent recursive calling.
Furthermore, should creation of the toolbar and the menubar happen in
the init of the view, or in the initView method of the presenter?
I think that if you have static menus you could create them in the init BUT if you change them (i18n or contextual menus) you should put them in a separate method.
thanks in advance. I am sure I’ll bump into more questions while I try
to restructure my app.
some more food for the thought:
-
never put wx code in the presenter, NEVER! (isolate the presenter as much as possible)
-
have your objects communicate via simple objects, the simpler the better.
-
split the code as much as you can and NEVER let a method run more than a screen size (trust me… it’s easier to start like this than to have to refactor the code like I HAVE to now 
)
Peter
···
There is NO FATE, we are the creators.
First of all, my ‘views’ exist of various classes, not one as in the
example. Some of them are only instantiated once (on initiation; the
Notebook for example), other are created on user interaction
(NotebookPage for example). So should I add all these classes to my
‘main view’ class, and have methods for NotebookPage
instantiation/creation? Or is there another way?
make triads for each reasonably complex component (a model view and
presenter for each component)
encapsulate as much as possible, expose only the minimum, only what you need
too.
So to get back to my example, I make a main model view and presenter
for the main frame and menubar etc., and a Notebook model view and
presenter for stuff happening in the notebook? Then how do connect one
view to the other (the Notebook to the MainFrame). And then in the
interpreter I use 2 (or more) views?
you could use a MVP triad for the general behavior of the app (starting, closing, accessing the menu, etc) and delegate the complex working of a NotebookPage (let’s assume it is a complex page) to another triad.
Create a “Component” based on your Page View, Presenter, Interactor and Model… something like this:
class NotebookPageComponent(PageView):
def init(self, parent):
PageView.init(self, parent)
self.presenter = PagePresenter(PageModel(), self, PageInteractor())
Now you can use this just like a regular widget. You might want to add few parameters to the component to pass to its model or its presenter or maybe create some delegators to access some of the Presenter’s functionality.
- split the code as much as you can and NEVER let a method run more than a
screen size (trust me… it’s easier to start like this than to have to
refactor the code like I HAVE to now )
“let a method run more than a screen size”? Do you mean: never let a
method handle more than something simple like sizing the screen?
no, actually I was referring to the lines of code, never let the LOC of a method be larger than what you can see on one screen. I know it is tough but… it is one of the wisest advices I found… It took a large project to understand it but… I saw the light and now I’m preaching it too :o)
Peter
···
On 11/22/06, TiNo tinodb@gmail.com wrote:
2006/11/22, Peter Damoc pdamoc@gmail.com:
On 11/22/06, TiNo tinodb@gmail.com wrote:
–
There is NO FATE, we are the creators.