[Rails-devel] Rails 2.0: The item hierarchy

[Stefan F. <ste...@we...>]

Another but hopefully the final update to the new Item hierarchy in 
Rails 2.0.

The current iterations is simpler and closer to what we have in Rails 
1.x, but still powerful.

An implementation is already there, but some major testing is still 
required.

So what is the core idea?
One issue (especially with having more games added) is that is not easy 
to access all objects of a Rails game from anywhere in the code. However 
this is needed especially for the specialized classes that cover the 
(more or less obscure) rules that pop up in various 18xx games: For 
those it cannot be predicted which parts of the game might interact.

To achieve this, every object (read: every Rails java object, which 
includes all game objects) is part of a tree hierarchy: To ensure this 
every (non-utility) class in Rails is derived from the Interface "Item". 
It requires the definition of a parent (Item) and an id (String).

To locate an item there can be special nodes defined by the Interface 
"Context", which extends Item. Every Item gets stored inside a lookup 
table of the closest Context up the tree.
An abstract class implementation of a Context is the "Manager".

The top node is a special class "Root" which itself an extension of 
Manager. It serves as the "Super"-Context of all Items.
(It might change its name into "GameManager" later, but this is already 
used).

A concrete example:
The 1830 Company "B&M" is an Item with the CompanyManager as parent, 
which acts as the closest Context here. So one could locate B&M
by asking companyManager.locate("B&M").
Another possibility is to ask the root.locate("companies/B&M"), if 
companies itself has the root as parent.

Relation to the State mechanisms:
The Root itself contains a StateManager which is responsible for 
handling the changes of the States (those variables which can change 
during the game progress).

An important feature of the object tree is that the
parent/id definitions are not states themselves (thus cannot change), 
however the lookup tables inside the Context are States themselves and 
can thus change without breaking the undo mechanism.

Stefan