Hi Jens,
yes, there are many options, but as I wrote, there are always some annoying
things that make the code unattractive somehow.
The options 2) and 3) require an additional member variable to hold the
inviter's value until the server call returns, and finally you end up in
redundancy: The same information about the inviter is hold in the member
variable as well in the list widget itsef. The same holds for the invited
user. In addition, this would simply move the synchronization task to
another place.
The options 1) and 4) require an external intervention into the inner
details of the class. A form object should accept and deliver the
identities of the two players to its encapsulating context, but it should
not reveal whether the users are selected from a list or if their names (or
numbers) are entered in a text field.
The option 5) seems to result from a misunderstanding: The inviter and
invited are identified by integers and independend from the list. But to
display them in a list widget, it must be filled first.
However, there is not really a problem, but I would have appreciated if
there were an option like this (inspired by
Scheduler.get().scheduleDeferred):
public void setInviter (final int inviter)
{
// we have access to the AsyncCallback<List<User>> object here
Scheduler.get().scheduleDeferredWhenServerCallReturned
(
new Command()
{
public void execute ()
{
lst_Inviter.select(inviter);
}
}
}
The main benefit would be that we could pass the value to the schedule
command and immediately forget it after that.
Magnus
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.
