RE: [Rails-devel] Re: First test case

[Brett L. <wak...@ea...>]

>> >Other included files are:
>> >* 1830market.xml - an XML file that defines the StockChart, 
>> which reads it at instantiation time.
>> >Format is provisional, of course, but it's a start.
>> 
>> I really like this. Here's some modifications that I think 
>> would be good:
>> 
>> 1. using a string for the color rather than an int. I don't 
>> think there's any advantages to doing color=3D"1" over color=3D"white"
>
>Yeah, right. "1" is in fact the internal representation (see StockPrice).

I saw that.  My point being, I'd prefer to have a string in the XML file=
 rather than 
having ruleset designers needing to look up which values relate to which=
 constants just 
to create a ruleset.

If it makes development easier, when we parse the XML, we can establish the=
 relationship between 
the int and the string.


>> 2. define within the XML where the ledges are. here we can 
>> simply do ledge=3D1 if the square is below a ledge, and make 
>> the assumption that if the tag is undefined, the square is 
>> not below a ledge. We can also make the assumption that if 
>> there are no ledge tags at all within the XML, then all chart 
>> boundaries are "hard" boundaries (i.e. the chits can't go 
>> beyond the boundary).
>
>You'll see that StockPrice already has booleans for the ledge
>and a few other things. I'm not yet sure if the ledge boolean
>should be true in the square above or below the ledge, 
>but that will flesh out when the code is written.

Right.  We'll need code to handle the conditions.

My point was that whether the ledges exist, and where they are, should=
 defined in the ruleset, and the boolean's value set based on what's read=
 in the XML.


>> I think this is probably a good way of breaking down the 
>> components into more managable pieces without cluttering the 
>> filesystem with too many files.
>
>OK, but then still we need a mechanism to populate different classes
>from the same XML file, so we don't gain that much. 
>Anyway, I suppose we can work out some way to do that.
>

My idea is that the game class handles setup and execution of the whole=
 game. 

In this way, we build the hierarchy from the top-down. This also means=
 that, the game class is managing, and has access to, all of the objects=
 we're creating. So, for example, game creates the Bank object, gets the=
 necessary value from the XML files, and passes it to the Bank constructor.

I'm expecting that we'll need to create a parser class to handle reading=
 and interpretting the XML, then the game class can populate the values=
 from the parser object into their respective game objects.

I hope I'm not over-simplifying things and doing too much hand-waving over=
 the complexities. If you think we need new classes to further break up the=
 tasks, feel free to create or suggest them. I don't expect that the=
 handful of classes I've layed out are all we'll need.

For the UI, I'm expecting we'll want to create a separate namespace and=
 delegate all the drawing tasks to that namespace so that we can avoid=
 cluttering up the game logic with UI-specific stuff.


---Brett.