David Jencks wrote:
Hi David,
I will try to coo my yesturday temper : I was a bit tired... :)
On Nov 16, 2008, at 5:14 PM, Emmanuel Lecharny wrote:
David Jencks wrote:
I can't say I regard xbean-spring as an ideal solution, but I don't
really understand why people think its any harder to use than plain
spring.
Because it is !!! Instead of having a single file where you have all
you need to get connected to the source, you have to permanently go
back and forth from conf to source, guessing what could be the class
associated with a name in the conf file, and what can be the
attributes you can configure.
I understand that figuring out what class relates to what element is
more difficult at the moment with xbean-spring.
It's always a balance : either you have a lightweight XML configuration
file, and I must admit that Spring carries a lot of dead weight with all
those packages before the class name, so having a simple name instead is
an improvement, or you have a heavy config file, but it's easier to
understand what is initialized when you start the server, as you have
all the information needed.
The problem is that ADS is about 2500 classes, and it's pretty hard to
know where you can find a class by its name (grep is not an option ;)
IIRC the default is to use the java package in the namespace and the
class name as the element name. I thought lots of namespaces would be
harder to use than a single namespace, maybe this was not a good
decision. Quite possibly it would be better to have a few packages
with the configurable objects and namespaces for each.
I'm confused about your claim that it's harder to figure out which
attributes you can configure with xbean-spring than with plain spring.
Let me explain : as we have a pretty deep inheritance tree, you have to
check for all the setXXX() in all the parent's classes, which is a bit
painfull, IMHO. What would be _way_ better is to describe the attributes
with annotation, instead of letting xbean extrapolate them using
introspection. At least, if you don't have such an annotation present,
then it will default to introspection, but otherwise, if a
@xbean.arguments( "attr1, attr2, ..." ) is present (or whatever other
solution), it will help a lot the developpers.
Without looking at the xsd or the class I don't see you have any way
of telling in either case. If you look at the class its pretty
obvious in either case. With xbean spring you also get a schema that
most editors will use to provide context-sensitive suggestions about
what elements or attributes are allowed: this is not possible with
plain spring AFAIK. If you can explain further I'd like to understand
what the problem is.
I agree that plain Spring does not help you to do that. I hope that I
explained what I had in mind in my previous comment.
<snip/>
well, I don't have any favorite XSD editor, and I don't have time to
absorb the messy XSD syntax. That's one of the reason I find it
overkilling.
Xsds are a pretty horrible language, but I admit I don't find them
that hard to understand.
I have spent a hell of time on compilers, trully, BNF is a beauty. XSD,
not so much (this is a direct reference to Borat ;)
To recall a reference to some comment you can find in Gnu preprocessor :
/* Pre-C-Preprocessor to translate ANSI trigraph idiocy in BUF
before main CCCP processing. Name `pcp' is also in honor of the
drugs the trigraph designers must have been on.
XSD must be one of the latest cool drug the guys who invented XSD must
have been on when they drafted it... I must admit that DTD was much
worst, but at least, it was so disgusting that you had no chance to
become an addict :)
Seriously, XSD is crap... Even if it's not _that_ complex :)
But with most editors (idea and I'm sure eclipse)
I didn't found a free and easy to use XSD editor on eclipse so far...
And trust me, I tried a bunch of those crappy SF drops...
if you tell the editor about the schema it will provide validation as
you type and context sensitive hints about what is allowed. I find
this a lot easier to use than having to consult the class (or the
schema) to find out what is allowed.
Well, if you can read an XSD file, sure. IMHO, XSD is only valid when
you want to validate a XML file, and only when it's handled by a
computer, not by human being. Eh, I was used to write code using direct
hexadecimal on my first Z80 or 6502 computers, but I don't think it fits
well in term of productivity :) XSD is a bit like assembly to me...
May be it's just me, but from discussions I had with other projects
as well, XBeans may be a cool techno, but certainly not something
which makes developpers life easier. IMHO.
I hope I'm not being too much of a nuisance here....
Nah, don't worry ! I'm just whining ;)
I don't think xbean is the last word in configuration, but I am
leaning towards jaxb based xml <--> configuration object solutions
which have the same basic features as xbean spring so I'd really like
to understand if there are fundamental problems with this kind of
approach of having an xml domain specific language for component
configuration.
I understand you approach, David. It makes a hell of sense, as
manipulating XML files to make them closer to the code is now necessary
because of IoC. And I also agree that those damn <package
name>+.<className> are just a PITA.
Here is what I think : Spring, and all those IoC/DI stuff are just
totally over rated. People tend to think that by defining their system
using beans is the ultimate way to go, as we weren't able to send a man
to the moon without all those craps... This is just a nonsense. Either
you have a plugable architecture (ie, JDBC drivers), or a Container
based system, or you don't. Usually, it's a mix. When it comes to ADS,
we have many plugable modules, like authentication systems,
SyntaxCheckers, etc, but I find this IoC thing far too complicated for
what we need. Either from the user POV (because it forces the user to
manipulate a pretty verbose file), but also from the developper POV, as
you simply can't anymore step into the initialization phase, unless you
put a number of BP into your code.
IMHO, Spring is one of the worst system ever, because not only it's
useless in 99,9% of the time, but also because it spreads myths like "it
makes your life easy". I may be wrong, of course, but I'm following the
Spring buzz since 2001 (or 2002, I don't remember), and I can't stop
thinking that it will die sooner or later. The simple fact that you need
to design XBean to ease the pain Spring is introducing is just another
nail in the coffin...
Thanks David !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
