MVP Night School
Locked
12
12
 
|
Eric Langjahr wrote:
> [snipped] Just to add to Ian and everybodys' suggestions (which seemed to reach my Demon account OK, BTW). There's another approach which *might* suit you needs better. It depends on whether the history list is an inherent part of your model. If your model is maintaining its history just in order to support your "progress" presenter, then I'd suggest moving the history out of the model altogether. If the model is, say, performing a sequence of transactions, where you want to see each as it is completed, then you could make it broadcast a #transactionCompleted: notification for each one. It would then be the responsibility of the observer to maintain the list of completed transactions (if it was interested). Thus the presenter would do something like: onTransactionCompleted: aTransactionRecord self historyPresenter model addLast: aTransactionRecord. self historyPresenter selection: aTransactionRecord. which would -- as a side effect -- also eliminate the flickering which used to happen when the list presenter's list was completely replaced for each new transaction. If the history *is* an inherent part of the model, for whatever reason, then you can still use the same approach. It means that you would be maintaining two lists, one in the model, and an independent one in the presenter/view, but that's what you have to do anyway (as in Ian's code) unless you want to use and expose a ListModel within your model (which I don't think is a particularly good idea). Actually, if the history is an independently important collection of data, then I'd be tempted to make it a separate object which the "model" adds to, and which is observed by the progress presenter. -- chris |
|
|
In reply to this post by Eric Langjahr
Well thanks to everyone for their suggestions.
I decided after consideration that the model should not keep this history log at all. In fact the model handles an atomic unit of work. I move the loop that drives the model into the presenter. It does the logging as to what unit of work the model is handling at any given time. The invocation of the run method for this loop is done with the forkAt: approach just as Ian suggested. This is all working quite nicely. As long as the logging is happening steadily the UI seems to remain responsive. However.... Still came up with some MVP questions. 1. I have a Button in the Shell window. Lets call this a RUN button. Once clicked this button needs to be disabled. Just before forking the process I set a variable indicating the process is active. In the command query method for the button I check this var and disable the button or enable it according to its status. The process sets this variable back to inactive state just prior to completion. The problem I am having is that the button does NOT seem to enable or disable VISUALLY until I move a mouse pointer or do something else UI related. If I just click on the button to run, and DO NOT move the mouse, the button still appears active. At process end, if I have have not touched the mouse the button appears disabled until the instant I move the mouse pointer. There appears to be some other thing I need to do. I did try invalidateUserInterface but that did't seem to really do the trick either. And I notice that if the forked process goes into any tight loops for long periods of time, without updating any subviews, the UI can still become non-responsive. The UI becomes non responsive if I am obtaining a really large listing of files contained in a root and many subdirs. Do each of these long processes need to be forked as well? And if I want to wait on them should I use Semaphores? Not sure how that would help but... How can I keep this UI going in all cases where it appears to be more responsive? 2. I noticed that the EnhancedListView appears to support the isChecked state for the list. When choosing this, space appears to be made for the check mark to be indicated or not as needed. However I could find no implemented protocol to allow the setting of the check status for a list. It seems like Single Selection Lists were implemented first. Then multiple selection lists were put in on top and perhaps not originally planed for. And that this particular notion of a list item that is checked or not is not reflected at this time. However, being an MVP newbie, I simply may have missed it completely<g>. Any thoughts or suggestions will be appreciated. On Sat, 20 Jan 2001 00:31:12 -0800, Eric Langjahr <[hidden email]> wrote: >More MVP questions<g>. > >I have a long running process. This process has a ListModel which is >the model for a ListPresenter. > >What I want is for the main windows (which is a Shell containing a >List Presenter to be updated as the long running process runs. > >The long running process simply adds periodically to the list. > >The idea is to have a history log in the list where the process >updates what is happening. In essence the model provided by this >process is a constantly updated collection of messages. This is >basically a variation of a standard progress indicator type situation. > >When I override the viewOpened method in my ShellPresenter subclass >to run this process, the window does NOT open until the process is >over. > >I then tried [self model run] fork > >in the viewOpened method and that got the desired result. > >Here are my questions. > >1. Is the fork approach in the viewOpened method a reasonable one? >Almost all the MPD examples I have seen tend to be examples where the >user causes things to happen. Not where the window opens and some >processing immediately starts. > >2. The normal ListPresenter keeps the selection at the top as items >are added. I want to scroll this list as the items are added so that >the bottom is always in view. > >There seem to be two ways to do this without breaking MPD separation > > (1) Bring some aspect of the loop that takes place in the process >into the presenter so that on each iteration we can send the sub >presenter the appropriate messages to scroll the list as needed. > > (2) If I feel strongly, that the iteration in the process is really >part of the model in some intrinsic way and does NOT belong in the >root presenter, then I need to create a different view on >ListPresenter (instead of the default) that will automatically scroll >the list as needed. > > (3) break MPD separation by passing the presenter into the model to >allow the model to handle scrolling. This seems clearly bad. > > At any rate I was just wondering if these seem reasonable to people >who have more experience with MPD than I do. I have used >WindowBuilder and while there is some similarity it is also quite >different<g>. > > I just want to make sure, as it were, that I am not missing some >obviously simpler way to do this. > > As usual, thanks to everyone for their help. And to Object Arts for >Dolphin. Dolphin is going to be handling some mission critical stuff >for me. The core classes are done. Now I have to get some kind of >simple UI on them<g> > > >On Fri, 15 Dec 2000 13:39:02 -0000, "Ian Bartholomew" ><[hidden email]> wrote: > >>Costas, >> >>> 1) What do you do in the presenter in case you have data from multiple >>> models? Do you have to create a supermodel (like a Cindy Crawford :) >>> to add to presenter? >> |
«
Return to Dolphin Smalltalk
|
1 view|%1 views
| Free forum by Nabble | Edit this page |