thank you robert, for your attention.
robert burrell donkin wrote:
> i don't know whether this sounds like genius or madness. certainly, it's a
> novel idea. it'd be really cool if you'd be willing to open source the code.
Hey, it's ok to call it madness. But if some find it useful ...
And I already have the feedback, that others find it useful.
Of cause I'm willing to open the code. I not, I would not write here for
comments.
> ... but the question is where...
May be, I should clarify a bit.
I startet with struts/tiles where I was working on skin-support without having
java-code in jsp-files. To test/debug the definition-factory I build a
dummy-application, which now has evolved to the config-manager. But that's
nothing to integrate in commons-digester.
I already had the meta-model of an application in the database.
My first step was, to build XML-files, that reflect the meta-model and process
this stuff with standard-digester (also to learn usage of the digester).
From the struts-user-list I know, that I'm not the only, thinking about
config-data in database.
I looked around, but found no support for processing content from database
based upon rules, like the digester does.
So I worked on that.
Another plan was, keep the application independant from the config-source.
Now, what I did was to have the manager read the config-source from file.
Currently there are 3 levels of sources:
1. XML-files
2. XML-data put into database
3. standard database content
The first 2 sources use the standard digester.
The last is processed with my new created digester.
Ok, it's not a big thing, cause I don't have lots of XML-problems with
database, but ... it works.
My digester is similar to the original:
<snip type="application-code">
public void loadDefinitions(AbstractSourceDefinition source,
String moduleName,
Locale locale,
DefinitionRoot root)
throws DefinitionException, IOException {
try {
DefinitionRuleset rs = source.getRuleset();
Connection conn = getConnection(source);
Digester digester = new Digester();
digester.push(root);
rs.addRules(digester);
digester.read(conn);
conn.close();
} catch(SQLException sx) {
...
</snip>
Both digesters create and fill the same objects.
The (application-specific) ObjectCreationFactories vary and for that I created
subpackages under the logical definition-packages i.e.:
...definition
...definition.xml
...definiton.db
Naturally both digester need their own rulesets. To achive it, I created a
Ruleset having the digester-parameter of type Object. To abstract classes
convert the Object to the right Digester-Type and so the subclasses don't
have to care about the digester-path.
I don't think, that this part is right-placed at the database-section. It's
the same abstraction level like digester and as I created some of the same
rules like CallMethodRule, CallParamRule, ObjectCreateRule, ...
having all the same interface for usage.
One vision is change i.e. CallParamRule to a facade which uses
xml.CallParamRule or db.CallParamRule depending on the context.
Ok, may be, you still call me madness. I'm some kind of special ;-)
But that's a small part the visions I'm working on.
The ConfigManager becomes part of a bigger chain, where I'm working on a
special dynabean. But that's not ready at all.
Any comment and/or criticism is appreciated.
regards Reinhard
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
