Re: [Springframework-developer] I don't like the DefaultXmlBeanDefinitionParser

[Martin K. <Mar...@St...>]

>> Thats how it is said to be thought of. But think about it, why does
>> the *.web modul doesn't contain any type/classes? Wouldn't you
>> expecting something going on here?
> 
> No, why should I? For my taste you're relying too much on principles. 
> While these principles are certainly not bad, you have to show that 
> they're pulling some weight in the cases where you suggest they be 
> applied. Put up a web page with a class diagram of an alternative 
> package structure and explain why -- in practical terms! -- it is 
> superior.

Principles are just concepts. But understanding the outcome 
(the reason), I can refer to priniples - which are only design advices/
ways to design/think - to talk about the use of these concepts.

But of cause there is an underlying reason why the concepts 
exist / where identified by the contributors. That reason is the fun.

Never the less. I am not quite familiar with the web application
(I use the package of cause, but it's only for the descriptive task).

One thing that I want you consider: You said you used the bean
package just for your stuff. The rest you were not needing. But
think of the ApplicationContext, it is the reason why the 
beans package is existing. ApplicationContext is the more abstract
level. So you would be able to do your stuff with the application
context, too. Using the ApplicationContext should be seen as the
'better' way to do things. I only used the ApplicationContext. 

The diffrence between my test cases and the product is the 
way I describe the ApplicationContext. And thats all.

So in my oppinion the ApplicationContext should be placed in
org.springframework since beans, aop and context are only
exisiting to provide the functionality the ApplicationContext
needs (or better an implementation of the interface needed).

And check out the web package. Same pattern. 
WebApplicationContext could be placed in the *.web 
package since everything else is related to it. Check
out the jsp tags - only providing to access the web 
application context.

Sure you can rip of the package and use the bean 
implementation by yourself. Thats how it is ment to be.
Part of, you know. If a part can meet your needs,
than the whole will also do. 

For example, I am currently doing refactoring of 
the DefaultXmlBeanDefinitionParser implementation.

This is part of bean.factory.xml. In my thinking this is 
wrong placement. The parser first of all should be
in a modul about parsers. But beside this you read
an application context definition file. Check out  how
the dtd of spring is defined. All about beans. To 
describe an application context you are referring to
the dtd. 

-> Spring is about defining a application context
for certain applications. That's what it makes superior.
It makes the application center (opposite are
Enterprise Java Beans).

-> The sub-modules are only existing to provide
good integration with common sub-domain specific
needs like using JMX, java mail, web etc. 

Draw the UML-Class diagramm about the current
Spring design and the way I would love it would be.
When you draw in the dependencies (who needs
who) than you will see that in a spring world you
have dependencies among modules within the
same level of structur. In my design the type 
dependencies go straight to the sub-modules
and the implementation dependencies go straight
up to the parent modul.

That's what it makes it superior (in my view).


Cheers,

Martin (Kersten)

PS: Maybe we simply should state that we disagree and
well cut it off :-).