Currently, the DAS has a ConfigHelper to allow users to build up DAS Config without using an XML file. However, its function today is limited to adding a table, relationship, primary key, or update statement to the config. This needs to be fleshed out, but I think if we follow down the current path for this helper we will run into an API explosion if we try to have a programmatic equivalent for every construct in the XML file.
A few options here: 1) Continue down the current path, which will lead to a massive ConfigHelper with a confusing API. We would end up adding several methods for each element type to support different attribute subsets. 2) Continue down the current path, but support only a subset of Config constructs. Personally, I don't like this option because it limits the programmatic model. 3) Make ConfigHelper a simple wrapper on top of the config "create" methods. The idea here is that you would have methods on ConfigHelper to return a new instance of each element type (Table, Column, etc.)
From that point, it would be the user's responsiblity to use the
setter methods on each element type to tie things together. 4) Some combination of the above. Add convenience methods for the most frequently used config options (for example, something like "public Table addTable(String name)"). Support "create" wrappers for all constructs so that the API is able to replicate any XML scenario. This seems the most reasonable to me. Any thoughts? Brent --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
