Hi!
Aaron Mulder wrote:
> So what you seem to be saying here is that the code that parses
> the XML has a list of classes, and when it sees certain tags is matches
> that to a class and turns processing over to that class to continue. I
> really don't consider that to be a dynamic plugin architecture. It's just
> delegation - you have a big list of stuff and you hand things over to them
> according to preset criteria. It's not like I could write a new plugin
> and it would be automatically included in your process, or remove an
> existing plugin and have your process still work..
This is incorrect. You can add a new plugin by editing the properties
files for the plugin selectors (see
/resources/org/jboss/ejb/deployment/editors/containerinvoker.properties
for example). When you select a plugin ("X") the GUI tries to find a
configurator for that plugin ("XConfiguration") dynamically. So you
don't have to recompile to add new plugins, just edit the properties
files.
> Besides, I'm not necessarily convinced that splitting up the
> parsing like this is an advantage. It sure makes it harder to debug when
> your parsing is split across a number of objects, and there's no clear way
> for a particular bit of the parser to access the prior state of the
> parsing before everything was handed over to it.
Not sure what you mean by "parsing". The XML is read into a DOM-tree,
which is then handed to each part that requires it. Each plugin is
handed its piece of the subtree, but if you really really want the other
parts of the tree that is possible too (just use DOM-traversal).
> This is one of the
> "features" I intentionally removed in the new structure - I thought it was
> much clearer to handle all the parsing in one place rather than spreading
> little bits of it all over, and tying it to a bunch of objects that do a
> lot of other things as well.
That's one way to do it, yes. And my intention was to keep everything
that was related to that object in one place. This makes it a lot easier
when you want to add or remove some setting. Split it up and you have to
change several files to make it work.
> If every class does a little parsing, a little event handling, a
> little data storage, a little GUI modeling, and so on - then where do you
> look when something goes wrong?
This has not been a problem so far...
> Or where do you look if you want to
> extend some bit of functionality?
The current EJX plugin matches the XML-tree and has pretty decent
naming, so that shouldn't be too difficult either.
> Or where do you go to understand the
> *process*? I elected to use a fixed set of specialists rather than a
> potentially unbounded number of generalists. I think this is one of the
> principal tenets of MVC and similar OO design techniques.
I would say that my decisions are very OO too.
Whatever. Look, if you want to do it otherwise, and it'll work, and it
is good enough, then shoot. Go for it.
/Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
