Thomas DeWeese wrote:
<snip/>
Ok so I took some time and I really don't like this model.
This is exactly the sort of thing that belongs at the application
layer not at the library layer. The idea of 'passing data' around
the application through a config file seems really bad to me.
(it's an excellent example of a programmers hack, look at all the
cool stuff I can do, so I can also break things in really odd
unpredictable ways - that's a small price to pay for tweakability).
I don't understand why passing a configuration object around an
application should be considered a programmer hack. It's common and well
accepted practise. Can you elaborate a bit on why you think it's a hack?
The problem is that I'm sure this is exactly the sort of
thing that sparked the flame wars. I also am not going to even
come close to have the time or interest to provide a replacement.
Your reason why a flame war should result is not clear to me. If you
can't/won't suggest an alternative then you seem to be on weak ground
when arguing against something.
If anything, those who have a problem
with A-F should propose a viable alternative (I haven't seen one, yet)
or work with the Excalibur guys to extract the configuration subpackage
into a stand-alone lib.
Since I have no idea what the library is and/or what you
plan to use it for I can't really provide alternatives.
This should be done the old fashioned way, the library should export
interfaces to support configuration and the _application_ should
provide the configuration data to the library as appropriate for
the application. I think this is really trying to do an end run
around this. There is no clear description of the data that passes
across this interface - that's really ugly IMO.
Agreed that the application may need to provide implementations of
anything specific - but the classes we are talking about are deemed to
be generic.
But A-F contains a configuration subpackage [2] which is very small,
very easy to use and provides exactly what is necessary to load a
configuration tree from an XML file and to access values in a type-safe
and fail-safe manner while not having to deal with the deficiencies of a
DOM.
The problem is that I don't care how big or small a dependency is
once the dependency is there it causes problems.
I understand the concern about adding a new dependency and agree size is
somewhat irrelevant. The alternative is to rewrite everything yourself
which isn't very good either.
<snip/>
I don't see how logging disturbs operation in interactive contexts.
It doesn't necessarily disturb it but it doesn't help either.
Not true. Logging is extremely helpful when debugging problems raised by
a remote user. And since all our users are remote and supported by the
mailing list logging is vital to supporting our users.
Do you prefer logging by System.out? Or can you do without logging?
I add/uncomment system.err messages (and often make use
of 'new Error("blah").printStackTrace()') as needed to track problems.
In the past I've developed elaborate logging systems (mostly C/C++)
and they can be useful for situations where build times are long
or you need to support remote clients. But Java build times are tiny
and end users can access our source.
Well thats fine for development, but no help for supporting remote
users. To tell a user where the source code is and they should figure it
out themselves is not acceptable. A small percentage of users may be
happy to do this, but most will not be java savy and will expect help
from the developers.
I learned that I can't. Logging is a very powerful means while
debugging (dev- and deployment-time).
As I said logging can be useful in non-interactive circumstances,
but in interactive situations you need to provide feedback through
the GUI. In my experience logging is useless for this - the type
and style of messages that goes into logs is very different from
the GUI. Now there are potentially non-interactive applications
for Batik components (the transcoders mostly) but right now they
handle logging/notification through the UserAgent classes.
FOP doesn't have a GUI and whilst Batik may have a GUI in some
circumstances - there are other use cases - such as transcoders (that
you already mentioned) and embedded use of Batik where logging is
necessary to provide feedback of what Batik is doing.
<snip/>
I'm happy to split out independent pieces but in my opinion they
are either completely separate project (independent releases possible)
or they should be one code base. I think the 1/2 way solution is
just annoying for everyone.
You may be right here, but your earlier arguments are not related IMO.
Is that plausible?
The current system seems like a lot of extra build nonsense
since each jar has to be built in turn so it can be used to
compile the next project, right?
Not necessarily. I don't think a separate build for each package is
necessary. I think it's simply helpful to more clearly show to
interested people what the individual parts are.
Isn't this better done in the documentation? I fail to see how
introducing a bunch of extra empty directories does anything to
help comprehension. And as long as you have one big build you
don't even get enforcement of unidirectional dependencies.
Who said anything about creating empty directories? Empty ones won't be
helpful, but breaking up big packages into smaller ones makes the code
easier to get to grips with.
This also favors a cleaner design which is an additional benefit. I
think Victor Mote could tell you a good tale how he alone already
profited from dividing FOray (a FOP fork) into digestable chunks.
My point is that it doesn't do anything for good design. There
is no advantage to this split from a design point of view.
I guess you have a point here. Splitting up large packages into small
ones helps understanding not the design.
Chris
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
