| Re: [higgins-dev] Discovering configurable elements and their structure for a configurable component |
|
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? TomGreg Byrd <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 ) 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 list higgins-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 list higgins-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/higgins-dev |