Struts config design questions

[Diego Fernandez <df...@datatransfer.com.ar>]

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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org

Re: Struts config design questions

[Joe Germuska <Jo...@Germuska.com>]

>    - I can't add new configuration options because these options are
>defined by ConfigRuleSet and controlled by Digester

This is not entirely true.  You can use the servlet init param 
"rulesets" to specify additional Digester rulesets.

See http://jakarta.apache.org/struts/userGuide/configuration.html#dd_config

That is not to say that you don't raise some good points.  I have 
been interested in the idea of a FormBean factory myself.  I don't 
have a ton of time at this minute, but we always appreciate 
thoughtful discussions and critiques of Struts, so thanks for taking 
the trouble to post.

Joe

-- 
Joe Germuska            
Joe@Germuska.com  
http://blog.germuska.com    
       "Imagine if every Thursday your shoes exploded if you tied them 
the usual way.  This happens to us all the time with computers, and 
nobody thinks of complaining."
             -- Jef Raskin

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org