Saturday, May 21, 2005
Our baby needs a type system
sipXconfig is growing up. And looks like it needs a setting type system. It's a frightening moment in the lives of proud parents. The teething problems are over (meaning we have settings), and it's time to start saving for college. The panic starts: which bank (which types we support), which tax deductible option (XML mark-up anyone?) and finally: where to take the money from (we do have so many other things to work on).
OK. Enough with the lousy metaphor...
The problem at hand: all our settings are strings. And I do not mean internal representation only. We treat them as strings across the board. Which makes it really cumbersome to implement any type of input validation or custom renderers. The natural solution would be to allow model designers to specify the type of the settings and the constraint of this type in the XML file. The problem is there is so many options to choose from. We want flexibility and extensibility: user defined enumerations that can be reused for multiple settings. But most importantly we want simplicity. We certainly do not want to roll out a new "type markup" language. One can very easily go overboard with that - just look at XML schema.
So I am thinking we start small and see where it takes us:
- number (integer) with min and max constraints
- string with regular expression constraint
- string with password constraint
- enumeration with labels and values
Every type will have a preferred renderer - in case of Tapestry widgets that would be NumericField, ValidField and PropertySelection. With time we figure out how to allow for custom renderers, user defined types etc.
This should keep us occupied for a while...