Re: [Rails-devel] PlayerOrderState (was: BugFix Release ...)

[Erik V. <eri...@xs...>]

Actually, on further investigation it seems to me that ArrayListState is not
really suitable.

In the first place, the updates that ModelObject sends to its related
ViewObject(s) are strings, produced by getText(). By default, this is the
stored object toString() result, and that is not something we can use here.
I'm not sure if defining getText() in ArrayListState as to produce the
concatenated toString() values of its elements would be a good idea.
And in the second place, ArrayListState is maintained by add and remove
methods, but using these methods would be forbidden in this case: the array
must be replaced as a whole, so that only one update is sent to the UI.
That is critical.

GenericState<String[]> does not help either: it also sends the array's
toString() result.

So I think I'm left with two options:

1. a new State subclass for this specific purpose (e.g. PlayerOrderState),
in which we can define getText() the way we want. 
That looks a bit like overkill, but if defined as a GameManager inner class
it wouldn't pollute the generic state package.  

2. the StringState solution (after all).

The more I think about it, the more solution 1 appeals to me.

Erik.


> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Monday, March 26, 2012 2:47 PM
> To: rai...@li...
> Subject: Re: [Rails-devel] BugFix Release for Rails 1880 Alpha5 available
- still
> buggy?
> 
> Erik:
> yes sorry for not subclassing the State/ModelObject/Observable stack using
> ArrayListState at the time of creation.
> I thought and still think that this class hierachy has some flaws (however
the
> main one was the duality of the state approach). Anyway it is easy to
correct
> by having ArrayListState extend from one of the classes above if you like
to
> do so.
>  From my knowledge there will be no negative side-effects.
> 
>  From my point of view I strongly recommend the approach above over
> wrapping an array inside a StringState and then parsing that.
> But I have to admit that neither solution will be merged automatically
into
> Rails2.0 as the State/Model/Observer code has seen the most changes.
> 
> In fact ArrayListState will inherit from State in Rails 2.0, even if State
and
> Model behave a little different between Rails 1.x and Rails 2.0. The
design of
> state and model is finished in the Rails2.0 branch, but there is still a
lot of tidy
> up to on the upstream.
> 
> Stefan
> 
> 
> >
> > Martin,
> >
> > I'm currently looking for a solution. What I need is a new ViewObject
> (Observer) object that represents the player order, and whose updates will
> trigger the complete player columns to be reordered.  The object itself
will
> be invisible.
> >
> > In the game engine, I cannot use the player order ArrayList itself,
because
> Stefan has chosen to define ArrayListState not to extend
> State/ModelObject/Observable.
> > I knew that would hurt me someday.
> > A perhaps simpler but not so neat solution would involve a StringState,
> containing the concatenated player names in SR order, separated by some
> special character.
> >
> > More later.
> >
> > Erik.
> >
> >
> >
> >
> >
> > ----------------------------------------------------------------------
> > --------
> > This SF email is sponsosred by:
> > Try Windows Azure free for 90 days Click Here
> > http://p.sf.net/sfu/sfd2d-msazure
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 
>
----------------------------------------------------------------------------
--
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-
> msazure _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel