Hello, > <stack> > <background> > <card> <!-- Card 1 --> > <card> <!-- Card 3 --> > </background> > <background> > <card> <!-- Card 2 --> > <card> <!-- Card 4 --> > </background> > </stack>
I like this schema because it maps well to the logic we are used to. Plus it simplifies msg-inheritance because the passed message ALWAYS goes to the PARENT container. > How do we handle such out of order cards? Good question! One thing that comes to mind is that we should clearly distinguish between *presentation* on the one hand, and internal *structure* on the other. IOW each card belongs in its parent bkgnd, at the structural level. FC reads this and creates a [internal] variable that contains a list of the cards sorted by number. It is this variable that FC uses for navigation from card to card. > In the XML file format I whipped up... > <stack> > <card bg="1"> <!-- Card 1 --> > <card bg="2"> <!-- Card 2 --> > <card bg="1"> <!-- Card 3 --> > <card bg="2"> <!-- Card 4 --> > > <background id="1"> > <background id="2"> > </stack> Schema-wise, this isn't how it is usually done. Instead of using nested entities to grasp the structure of the data, we would be using the one of the properties of the object (or an attribute). But attributes are messy, e.g. they clutter the code, and all our properties are CUSTOM which means that a user could inadvertently trash or set this property to something else. In both cases, the link is lost and the structure crumbles. Perhaps Swiss cheese is a better analogy here. > In other words, list the cards in the order they > appear in the stack, and the bkgnds separately and > then use the id of the background to refer to it. I > think that's the only way to achieve what we want... In that case, it has *my* vote too! ;-) > ... but am happy to hear other ideas. I don't have much to offer you except what I wrote a few paragraphs ago, e.g. FC reads the XML and creates a var that contains the sorted list of the cards, that it then uses for navigation/etc. We need such a list anyways for our scriptingLanguage, e.g. get the cards [of bg|stack]. Your idea is acceptable though. I see why it necessary, and we certainly want to support mixing cards/bgs inside the stack. So either way is okay.. whatever works well! > It's amazing what you discover when you move > into implementation phase. :) Indeed! :)) That's why the "Big-Design-Up-Front" approach of most projects is sub-optimal and often a waste of time. The best approach is an "Agile" one : some planning is done, focused mainly on what adds the most genuine value for the target/customer, but then *implementation* quicks in rather quickly and performs its magic on the design that evolves. People don't really know what they want, ever, until they actually SEE it in front of them. Touch it. Plans are nice and comforting, but they don't evoke much for those you have planned for. But you know this of course, Adrian. I'm just preaching the Agile-gospel to those who may not have seen the XP-light yet. PS: XP= Extreme Programming = popular Agile methodology. Argumentatively yours, Alain __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Freecard-general mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freecard-general
