(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
-
