(4) sounds good, maybe another option to avoid getting configHelper too crowded is to create subclasses of ConfigHelper to handle more commonly used scenarios, and users would use those specialized classes for specific scenarios... but, as mentioned by Kevin, (4) is fine for now, and we can always revisit this on the future.
- Luciano On 7/28/06, Kevin Williams <[EMAIL PROTECTED]> wrote:
I like #4 also. We can add additional convenience methods down the road when we get a better feel for how clients are using it. ant elder wrote: > (4) sounds good to me. I may even have a use for this soon for some > JavaScript support for DAS I've been thinking about. > > ...ant > > On 7/27/06, Brent Daniel <[EMAIL PROTECTED]> wrote: > >> >> 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] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- ----------------------------------------------------- Luciano Resende SOA Opensource - Apache Tuscany -----------------------------------------------------
