| Re: [higgins-dev] Discovering configurable elements and theirstructure for a configurable component |
|
Here's an initial strawman proposal for schema configuration - obviously incomplete, but a place to start:
<Setting Name="name of configuration element" Type = "htf:map">
<Setting Name="Type" Type="xsd:string">xsd:string</Setting>
<Setting Name="Required" Type="xsd:boolean">true</Setting>
<!-- If min/max isn't one, name will be generated -->
<Setting Name="MinInstances" Type="xsd:string">minimum number of these</Setting>
<Setting Name="MaxInstances" Type="xsd:string">maximum number of these</Setting>
<!-- These are UI helps - perhaps not really needed -->
<Setting Name="DisplayName" Type="xsd:string">display name</Setting>
<Setting Name="DisplayOrder" Type="xsd:integer">display order</Setting>
<!-- For a map or list, the <default value> would be nested XML, for other types
it is just a simple value --!
<Setting Name="DefaultValue" Type="type specified"><default value></Setting>
<Setting Name="EditSize" Type="xsd:integer">edit size</Setting>
<!-- Validator class could specify legal values -->
<Setting Name="Validator" Type="htf:instance">class name</Setting>
<Setting Name="LegalValues" Type="htf:list">
<!-- list of elements -->
<Setting Name="SubElements" Type="htf:list">
<!-- list of sub-elements - only applies if type of this element is
htf:map or htf:list -->
>>> "Tom Doman" <TDoman@xxxxxxxxxx> 8/2/2007 11:51 AM >>> > And I'm not trying to specify one standard syntax for the above -- one could create > any number of schema classes and helper functions, so as long as the class is complex > enough to create the configuration for the types of objects that it represents. In > other words, if a certain type of components only has simple configurations, then the > specification language can be very simple. Yeah, okay, cool, I like it! Though we have to pick one syntax to start with an implementation. Daniel, do you have any comments on Greg's direction with this? Tom >>> Greg Byrd <gbyrd@xxxxxxxx> 8/1/2007 9:40 PM >>> Could be anything, I guess. Could look like XML. Since I'm an old Lisp hacker, I might do this: (name="ContextFactorySettings" type="htf:map" (name="ContextType" type="xsd:string" display="Context Type" docstring="Type of context supported by the factory." defaultWidth=30 required=true) (name="InitialContexts" type="htf:list" display="Pre-loaded Contexts" docstring="List of contexts preloaded when the factory is created." minElements=0 elementType="htf:instance" required=false) ) Could include this as a static string variable for a class (e.g., ContextFactoryConfigSchema) and write a method to parse this string into a SettingDescriptor object. That's what I mean by "declarative" -- someone who wants to change the schema just changes the string, not the code. Plenty of room for critique here. Certainly anything proposed should be able to describe the existing configuration files that we have (e.g., yours and Mike's). And I'm not trying to specify one standard syntax for the above -- one could create any number of schema classes and helper functions, so as long as the class is complex enough to create the configuration for the types of objects that it represents. In other words, if a certain type of components only has simple configurations, then the specification language can be very simple. The standardized part is that the "schema" is given to the management application as a SettingDescriptor. How that gets created can be specialized. ...Greg Tom Doman wrote: This all sounds promising to me. Any thoughts on what the "declarative way to describe a configuration schema" would be/look like? Tom Greg Byrd <gbyrd@xxxxxxxx> ( mailto:gbyrd@xxxxxxxx ) 8/1/2007 9:24 AM >>> Here's what I'm thinking about how to describe a configuration. (1) Create a class called SettingDescriptor that holds parameters about a setting: name, type, display string, doc string, constraints. The class will either be general enough to describe map, list, and simple setting types, or we can specialize the class. A map descriptor will contain descriptors for its subsettings, etc. (2) Add a getConfigurationSchema() method to IConfigurableComponent. It returns a SettingDescriptor. The descriptor can be built by reading a configuration file (as Daniel suggests), or just be having a static method of the class (or some descriptor class) that knows how to create it. (3) We can invent a declarative way to describe a configuration schema, and a helper class that knows how to convert it into a SettingDescriptor, if that seems more maintainable/user friendly than specifying it in code. The schema string could be kept in a file, or in a static string variable, etc. This is totally up to the class that is responsible for creating the SettingDescriptor. I think it would be better to have a standard class that represents the schema, rather than than having the format hardcoded into a management application. ...Greg Daniel Sanders wrote: Someone might be tempted to suggest XML Schema. However, I think that approach would be clumsy and burdensome at best. There is an XML Schema that describes legal use of <Setting> elements to create configuration documents, but it is limited to describing configuration documents in a very general sense. It does not describe what constitutes valid combinations of <Setting> elements for specific kinds of configuration (e.g., JNDI configuration, STS configuration, etc.). Although I could envision XML Schemas that did describe specific valid configuration schemas, I think it would be extremely ugly. I would propose that we describe the schema of a particular kind of configuration using another "schema configuration." Such a "schema configuration" is simply a special kind of configuration whose legal structure and constraints are well understood by the management utility. In other words, the schema configuration would itself have a well-known schema. Obviously, it could be used to describe its own schema (just as XML Schema can be used to describe the proper syntax for XML Schema). However, other than perhaps for documentation, there is no practical need for it to describe itself. The knowledge of the schema of a "schema configuration" has to be hardcoded in whatever application needs it (such as management utilities) in order for it to be put to practical use. (XML Schema parsers do not rely on the XML schema that describes XML schema to parse an XML schema. The knowledge of XML schema is hardcoded in them.) The advantage of this approach is that we already have libraries for accessing configuration objects, so the management utility doesn't have to use a separate set of libraries to access and process a configuration schema. It can use configuration objects to both understand a configuration schema and then create a valid instance of the configuration schema. Daniel "Tom Doman" <TDoman@xxxxxxxxxx> ( mailto:TDoman@xxxxxxxxxx ) ( mailto:TDoman@xxxxxxxxxx ) 7/16/2007 9:54 AM >>> While we have to document every available setting and how to structure it for all our configurable components, we also need a way for management utilities to dynamically provide an interface to allow configuration of each setting. In other words, we need another schema to describe this stuff and I was pondering whether we could reuse concepts and code we've already created here or whether we'd end up with "chicken and egg" problems. I also don't know how what Markus is doing might play into this as well as we modify XRDS documents with our configuration data inside. Does anyone else have any thoughts or comments on this issue? Thanks, Tom _______________________________________________ higgins-dev mailing listhiggins-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/higgins-dev _______________________________________________ higgins-dev mailing listhiggins-dev@eclipse.orghttps://dev.eclipse.org/mailman/listinfo/higgins-dev _______________________________________________ higgins-dev mailing listhiggins-dev@eclipse.orghttps://dev.eclipse.org/mailman/listinfo/higgins-dev _______________________________________________ higgins-dev mailing list higgins-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/higgins-dev |