RE: [Htmlparser-developer] HTMLParserFeedback

[Claude D. <CD...@ar...>]

Great! Check out the Log class in the JavaDocs for the Apache Commons
project:=20

 <http://jakarta.apache.org/commons/logging.html>
http://jakarta.apache.org/commons/logging.html

It's intented to provide an abstraction that maps onto various logging
libraries (Log4J, JDK14 logging, etc). The API for the Log class looks
similar to the one I proposed. The main distinctions are that they've
used Object types for the message (I'd presume they count on the
toString method for logging) and they have more methods. I think there's
room for adding methods in the Feedback API, but I'd be inclided to do
it on an as-needed basis.

-----Original Message-----
From: Somik Raha [mailto:so...@ya...]=20
Sent: Monday, August 05, 2002 7:04 PM
To: htm...@li...
Subject: Re: [Htmlparser-developer] HTMLParserFeedback



Hi Claude,
    No no, I wasnt planning to use log4j for the parser :)
    Just mentioning that the model is so similar. J2SDK 1.4.x of course
has the same logging stuff in their APIs.
    I agree with your reasoning - we'll start putting in the feedback
classes down the line. Let me see if I can find some time in the weekend
to analyze this. If anyone else wants to try this integration - pls feel
free.
=20
Regards,
Somik

----- Original Message -----=20
From: Claude  <mailto:CD...@ar...> Duguay=20
To: htm...@li...=20
Sent: Monday, August 05, 2002 1:04 PM
Subject: RE: [Htmlparser-developer] HTMLParserFeedback

Please don't introduce any dependencies on other libraries. The Feedback
model is intended to allow users to redirect output to wherever they see
fit for their application. The default sends output to the console but
it's easy for implementers to make more local decisions based on their
context, by replacing the default implementation, so long as the
interface is valid. The whole idea of a library/framework is that the
input/output is controllable by the developer using it. You don't want
any coupling to other libraries. Let developers decide what's suitable
for their application. It's similar to the ErrorHandler in SAX, though
in their case, the output goes nowhere by default. It's up to users to
decide what to do.
=20
You'll notice that the Feedback classes introduce a model that library
developers can use to direct output to a place that won't interfere with
the library user/developer's notion of where things could go. I've been
meaning to write something more specific about this design pattern but
things just keep getting in the way. In any case, use the Feedback
mechanism as a way of allowing users to decide where the output should
go or whether it should be ignored. Consider it a replacement for
System.out and System.err. Users can later decide whether the output
(which falls into simple categories) should be logged, send to the
console, written to a GUI, rerouted to sockets, filtered by pipelines or
simply ignored. The beauty of this design is all in the uncoupling, ushc
that the library user decides what's relevant in their application.
=20
-----Original Message-----=20
From: Somik Raha [mailto:so...@ya...]=20
Sent: Sun 8/4/2002 12:34 AM=20
To: htm...@li...=20
Cc:=20
Subject: [Htmlparser-developer] HTMLParserFeedback



Hi Developers,
    This is to initiate a discussion on the next step, on integration
feedback into the parser. Claude had submitted HTMLParserFeedback
interface (in the util package) - which allow us to log the activity of
the parser, inform when errors occur, and show warnings.=20

    I am familiar with log4j, and this sounds pretty similar - in terms
of functionality, it sounds good. But in terms of performance, my
question is :
[1] Will this result in an unacceptable performance hit ?
[2] Should we provide alternate constructors or modify existing API ? If
we provide alternates, then what default behaviour would be best ? Are
we talking about default callback objects - if yes, the strings created
for each call would slow down the parser.

    It would be great to have some thoughts on this.

Regards,
Somik