From: Stefan F. <ste...@we...> - 2012-03-26 12:47:00
|
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 |