Re: [higgins-dev] Discovering configurable elements and theirstructure f

["Tom Doman" <TDoman@xxxxxxxxxx>]

Greg,

I'm liking where you're going so far.  Did you get a chance to look at Daniel's declarative example to see if you two are on the same page there?

Also, we have some expertise within the Bandits and more within Novell on dynamic UI creation and while I'm still advocating simplicity, I thought I should throw out a couple of items that might be good to consider, at least as extensibility items.  Some of the things we might want there could already be easily handled by what you've proposed.  For example, the item named "DrinkSize" is a choice of "Small", "Medium", and "Large".  That's easy for a UI to decide it's not a simple text entry box, it's a drop-down with 3 choices and it's clear to the end user that "Extra Large" isn't an option.

However, describing relationships between settings is one thing we've done in the past.  For example, these 3 settings are percentages expressed as integers which must total 100.  Or, if this setting is set, these other two must not be set, etc.  I'm sure our experts here could remind me of other examples but that's the general idea.

Now, I also don't want to try to push the unifying theory of quantum mechanics here but as we go through this exercise, I can't help but wonder if these same principles apply to say, the creation of Digital Subjects and other things for which we've created the Higgins OWL model?  I could dismiss that thought but I can't answer the question "What is different about configuration vs. our higgins data model?"  Maybe the answer is we need out-of-band mechanism in order to boot strap.  So, maybe it's just the principles that apply, not some unified code base.  Anyway, just wanted to put that thought out there for all to ponder.

Thanks,
Tom

>>> Greg Byrd <gbyrd@xxxxxxxx> 8/3/2007 6:55 AM >>>

My first cut at a SettingDescriptor class contains the following instance
variables:

Name (string)
Type (class)
DisplayString (string)
DocString (string)
Constraints (Map)
SubSettings (List)

The Constraints is where all that other stuff goes.  Different constraints
are relevant for different setting types.  E.g., minValue makes sense for
int/float, but not stream.  So the manager can query for a particular
constraint ‹ if null returned, then that constraint was not specified.   Or
can iterate through all constraints, etc.  Constraint is a string/value
pair.

There are some ³standard² constraint strings defined as static variables in
SettingDescriptor, but any implementation could always do more.

...Greg