Menu
▾
▴
Re: [Springframework-rcp-dev] Threading and Progress
|
From: Amad F. <ama...@ya...> - 2005-07-07 17:07:01
|
Sounds great. But we are no quite ready to upgrade our
project to Java 1.5. So I hope we stay with Pre 1.5
java for little longer.
Amad
--- Andy Depue <an...@ma...> wrote:
> In a few weeks we will be starting work on several
> long running processes
> (from a UI perspective) and will need to implement
> progress bars and other
> related functionality. I'd like to develop this at
> the Spring-rich level and
> contribute it to the Spring-rich project. I figured
> I'd start discussion on
> this topic while things are still a few weeks away
> to gather ideas on
> implementation.
> Here is what I'm thinking so far. There has been
> talk lately of "container
> managed Swing" (see link at bottom of e-mail), so
> why not head down that
> path? I'd love it if my ActionCommands and
> ActionCommandExecutors would
> (optionally) automatically be pushed to a worker
> thread when executed from
> the event thread. By optionally, I'm thinking that
> a command could run in
> one of three modes:
> 1. Block the event thread if executed from the event
> thread. This is how
> commands act now.
> 2. Execute concurrently. The command will be
> executed from a work thread and
> the UI will continue in the forground.
> 3. Cause the UI to "wait" for the command. This
> means: execute the command in
> a worker thread, but block the UI while it executes
> (we would utilize Spin or
> Foxtrot to continue to pump events even while
> "blocking" the UI). If the
> task executes in less than a certain time limit
> (say, 250 ms), then this will
> have acted no differently than mode #1. However, if
> the command takes longer
> than that time limit, pop up a progress dialog (or
> any other wait indicator
> you could desire). For example, if it takes longer
> than 250 ms to execute,
> then you could pop up Romain's cool spinning wait
> screen. :) You could even
> put a "Cancel" button on this progress dialog, since
> the event loop is now
> free to handle user input.
>
> For options #2 and #3 we could borrow an idea from
> the latest SwingWorker and
> cause any property change events fired from the
> command to be properly
> relayed to the event thread. So, I could add a
> progress property to my
> command (or we could add to AbstractCommand itself):
>
> public void setProgress(final double progress)
> {
> final double old = this.progress;
> this.progress = progress;
> firePropertyChange("progress", old, progress);
> }
>
> In this simple example, progress would always go
> from 0.0 to 1.0 (1.0 being
> 100% completed). Then, a progress indicator has
> only to register a
> PropertyChangeListener for the "progress" property,
> knowing that it will
> receive any property change event safely within the
> event loop. The progress
> indicator could react to the PropertyChangeEvent by
> updating the progress
> status/bar (of course). We would probably want to
> define some standard event
> or property that commands could use to transmit a
> status message as well
> ("Connecting to server...", etc).
> DefaultMessageAreaModel uses the "message"
> property, which sounds good to me.
>
> The other part of the picture is the worker thread
> itself. What would be
> ideal, in my mind, is if we could fully utilize all
> the really cool new
> constructs in Java 1.5's concurrent library.
> However, I'm not sure if
> Spring-rich is ready to make the jump to requiring
> Java 1.5 for certain
> functionality (this is something to be decided by
> consensus) - so a good
> alternative would be to create Spring-rich specific
> interfaces that then
> integrate with various 3rd party options (in typical
> Spring fashion), such as
> Foxtrot, Spin, SwingWorker, Java 1.5, Doug Lea's
> concurrency libraries, etc.
> Come to think of it, we will probably end up
> utilizing Foxtrot or Spin anyway
> (for mode #3).
> The important requirement for us in regard to the
> worker thread is that we
> will need several different "scheduling" options.
> In parts of the UI we will
> want a single thread queue, where each command
> submitted to the worker thread
> is executed in the order it is received from a
> single background thread. In
> other parts of the UI will need a concurrent thread
> pool based scheme:
> whenever a command is submitted, the next available
> thread is pulled from the
> pool and execution is begun immediately - unless the
> pool is empty (all
> threads are busy), and only then are commands
> queued.
> If there are multiple executors (worker thread
> managers or whatever you want
> to call them) and thus multiple commands executing
> (sometimes in parallel),
> then we will need to think about how a single
> progress dialog or wait
> indicator could both register with all background
> commands and unify their
> various states and progress in its display to the
> user (note, in some cases
> the developer will not provide progress or status
> messages to the user -
> using only a simple wait spinner or whatever). A
> developer will also need
> some way to indicate to the system how a particular
> command should be
> executed/enqueued.
> Finally, most SwingWorker type solutions provide
> several "stages" of execution
> where the long running process is run in one method
> which gets executed in
> the background thread, and then a "finish" method of
> some sort gets called
> from the event thread, which is where the developer
> places code that
> interacts with the UI. We would probably want to
> consider how to approach
> this - maybe as simple as causing
> ActionCommandInterceptor's preExecution and
> postExecution methods to be invoked from the event
> thread. The developer
> would then need to register a custom
> ActionCommandInterceptor with the
> command if he wanted to perform UI related activity
> before or after the long
> running execute() method is called.
>
> I'm open to any thoughts, suggestions, or
> criticisms. If I hear nothing, then
> I will assume that everyone thinks this is a good
> idea and go ahead with
> it. :)
>
> - Andy
>
> PS Here is one of the first mentions of container
> managed Swing that I know
> of:
>
http://www.clientjava.com/blog/2005/04/11/1113230427399.html
>
>
>
-------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux
> Migration Strategies
> from IBM. Find simple to follow Roadmaps,
> straightforward articles,
> informative Webcasts and more! Get everything you
> need to get up to
> speed, fast.
>
http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
>
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>
____________________________________________________
Sell on Yahoo! Auctions no fees. Bid on great items.
http://auctions.yahoo.com/
|