Slightly off topic more of a design comment.

For me Job would be a better name than Command. Command reminds me of  
the command pattern while job is always a background task that might  
execute sooner or later.

It also seems like there are lots of "duplicate" add methods for lack  
of a better of description, whereby each type of Command has it's own.  
What about a central manager type class with a single add( Job,  
JobType) where JobType is Incremental, Timed, etc.

For the Timed version there would be factory to pass the when or how  
often etc, or as in the previous email from Bruce AsapJob.

I can also see a benefit of allowing developers to change the command  
(job) type by changing the JobType parameter which seems simpler /  
more flexible than the hard coded static adds and super type.

Just an idea...

On 05/09/2009, at 4:35 AM, Ray Ryan <rj...@google.com> wrote:

> I like the Finally name.
>
> Since you have a single Command object used by Incremental along  
> with everyone else, you're implying interface
>
> Command {
>   /**
>    * @return whether this command should be run again.
>    * Checked only by {...@link IncrementalCommands} and {...@link  
> TimedCommands}
>    */
>   boolean execute();
>  }
>
> That's a bit redundant with the TimerController--would it even be  
> honored by TimedCommands?
>
> Let me propose this (actually, I think steal it from Brian Brian  
> Slesinsky) , to allow every command to reschedule itself or not.
>
> rjrjr
>
> interface Command {
>   /**
>    * @param dispatcher To allow this command to requeue
>    *    itself, or add other commands. Presto, it's
>    *    all three of timed, incremental and one off
>    */
>   void execute(CommandDispatcher dispatcher);
> }
>
> interface CommandDispatcher {
>   enum When {
>     FINALLY,
>     ASAP
>   }
>
>   public static CommandDispatcher get();
>
>   public void add(Command c);
>
>   public void add(Command c, When w);
>
>   public void addDeferred(Command c, int millis);
> }
>
> That's the whole thing. For convenience, we could also offer stuff  
> like the following. Perhaps
> // better to see what evolves
>
> abstract class IncrementalCommand implements Command {
>   public void execute(CommandDispatcher dispatcher) {
>     if (doExecute()) {
>       dispatcher.add(this);
>     }
>   }
>
>   /** @return true to keep going */
>   abstract boolean doExecute();
> }
>
> and
>
> public class TimedCommand implements Command {
>   private final wrappedCommand;
>   private final interval millis;
>   private boolean stopped;
>
>   public TimedCommand(int millis, Command wrappedCommand) {
>     this.wrappedCommand = wrappedCommand;
>     this.millis = millis;
>   }
>
>   public void stop() {
>     stopped = true;
>   }
>
>   public void execute(CommandDispatcher dispatcher) {
>     if (!stopped) {
>       wrappedCommand.execute(dispatcher);
>       dispatcher.add(this, millis);
>     }
>   }
> }
>
>
> >

--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---

Reply via email to