Hi,
I'm new to the Struts source code, and looking through the sources, I
got some questions, mainly about ModuleConfig...
(sorry if this mail sounds pedantic, it is not my intention, my english
is not good, and it is very difficult to discuss about object design in
a foreign language... so thanks in advance for the patience).
What do I want to do?
My intention is to create a patch to:
- Provide a way to create the ModuleConfig easily without the need
of a struts-config.xml (yes you can use the factoryClass init parameter,
but the ActionServlet still uses Digester to parse the configuration
file, and... I am starting to hate the "XML oriented programming").
- Allow the use of custom factories for FormBeans. I found some
cases where the possibility of a custom factory is convenient, for
example:
* a factory that creates adapters between "Data Transfer
Objects" and Struts FormBeans.
* a factory that uses Javassist to create dynamic form beans
instead of DynaBeans
and, What are my questions?
- Why ModuleConfigFactory has a setFactoryClass static method? What is
the need for a global variable there? ModuleConfigFactory is not used as
a singleton (the only reference that I found to
ModuleConfigFactory.createFactory is in the ActionServlet).
The difference that I see between:
ActionServlet:
initModuleConfigFactory:
...
ModuleConfigFactory.setFactoryClass(....)
initModuleConfig:
...
ModuleConfigFactory.createFactory() --->
RequestUtils.applicationClass(factoryClass)
And to simply create the instance of DefaultModuleConfigFactory is that
in the first case, ModuleConfigFactory knows where the default
implementation is, and I think that this is not a responsibility of
ModuleConfigFactory, I think that this is a responsibility of the
ActionServlet or some other ("high level") class.
- The responsibility of ModuleConfigFactory is to provide concrete
instances of ModuleConfig. But making new ModuleConfig implementations
is not very useful (at least I can't find a useful new implementation of
ModuleConfig).
Because these instances are "configured" (in other words the instance is
un-persisted from some repository) in the ActionServlet, and I can't
control this "configuration" process (yes, unless I provide my own
ActionServlet, but I see this approach as too much work, the
ActionServlet is in some way the core of the Struts framework) :
- I can't add new configuration options because these options are
defined by ConfigRuleSet and controlled by Digester
- I can't use a different repository for the configuration, I'm
stuck with struts-config.xml or some other XML.
So if "configuration" is the only a way to persist object instances, why
does the ActionServlet have all the responsibility of the
"un-persistence" of ModuleConfig instances? Is it not more "natural" to
delegate the responsibility to the concrete ModuleConfigFactory?
I think that the ActionServlet has too much responsibilities that need
to be factored out into other objects (for example we can use a "Method
Object" in the servlet "init" method, maybe an
ActionServletInitializer).
- There is no need for a ModuleConfig.freeze(), this state checking is
very bug-prone, why not use a "Builder"? Instead of config.freeze(), we
can use configBuilder.build() and remove all the methods that allow
instance changes in ModuleConfig.
(Sorry this was a very long mail... thanks again for the patience)
Regards,
Diego
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
