On 01/10/2003 12:02 PM, "Alain Farmer" <[EMAIL PROTECTED]> wrote:
> 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. This structure doesn't really follow the exact logic we're used to - it follows the message passing hierarchy we're used to. The order and abilities are not correct. >> 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. This would be possible but would require loading and processing every card before we could show any of them. Currently, we have to load the entire stack but don't actually process cards until they're required which reduces load time fairly significantly. >> 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. You're correct that this isn't ideal, but it is something that's well catered for in w3c schema since it has the ID and IDREF types. Generally speaking it's not an ideal solution if nesting is suitable, however in our case I feel that having the order correct in the XML instead of the hierarchy is more important. The reason for this is that to handle out of order backgrounds, you have to use a model where a stack is a pile of cards and each card has a background which may be shared among multiple cards. > 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. You're missing the subtle distinction between properties and XML attributes. Properties are a concept within FreeCard whereby FreeCard Objects have a set of arbitrary name value pairs. It is properties that are all custom. XML attributes however are not a FreeCard concept and do not appear anywhere in the freecard runtime. They do however exist in the XML file format and can be used as part of a method to store the conceptual FreeCard Objects and their properties. Attributes are not custom, but are definied clearly in the schema and cannot be modified directly by the user at all. In essence, the user can change the name of a card which changes the (custom) property "name". They can't however change the "bg" attribute directly because FreeCard has no knowledge that it exists outside of the module that reads and writes the XML (and the user can't deal with that directly as it has no UI). The user could cut and paste the card into a different background which would cause the "bg" attribute to change, but it could only possibly change to another valid value and couldn't just be deleted. > In both cases, the link is lost and > the structure crumbles. Perhaps Swiss cheese is a > better analogy here. Which is why we make sure neither case can happen. :) It would be akin to saying that the user could move the card element to somewhere invalid - they could do it with a text editor, but they couldn't do it through FreeCard. > 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]. Depending on the final performance of the attribute approach we may look to use this approach instead, though I don't believe that it will be any faster. The list of cards will already exist in the XML format when using the attribute approach so we can just request it straight from there without having to build our own. > 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! Well I'll run with this for now and see how it winds up. I know this approach will work and I believe it's as good as any other if not better. > >> 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. I'd have to pull you up on this. In our case agile methodologies work well, when developing life support systems and satalite guidance systems, it doesn't work so well. You need to formally account for all the possibilities which requires extensive prior planning and verification. The best stuff up I've seen was on a satelite guidance system I reviewed which had the requirement: Satalite must include a manual override function which when activated disables the automatic operation and switches to manual control. Unfortunately, nowhere in the requirements was there anything about being able to operate the satalite using manual controls, so the requirement wound up being "satalite must have a big red switch that causes it to fall out of the sky". :) Not something you want to discover once you've put the satalite into space. Generally though I agree with you. :) > Alain Gotta run. Adrian Sutton. ---------------------------------------------- Intencha "tomorrow's technology today" Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.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
