You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Steve Mactaggart <st...@golftime.com.au> on 2004/05/18 03:34:31 UTC
EnhancedHTMLAppender
I have got an initial version of the updated HTMLAppender created.
I have called it the EnhancedHTMLAppender at the moment, so you can run both
and see the differences, but I hope to replace the existing one once this is
completed.
This Appender requires a change to some other classes, and these changes are
included in the patch.
I have added a "public String getParseName()" to the PatternConverter to
enable the header of the HTMLAppender to title each column. For this method
to return valid information, each subclass needs an implementation of this
method and those changes are also supplied.
The new HTMLAppender can be configured in the same way as the existing one,
but the default layout is pretty basic.
I'd suggest a format like:
<layout class="org.apache.log4j.EnhancedHTMLLayout">
<param name="ConversionPattern" value="%d{dd MMM yy
H:mm:ss}%t%-20.20c{1}%-5.5p%m"/>
</layout>
This is just a initial version, to get out to people for feedback, it works
fine for me and has been tested, but doesn't have all the bells that I
eventually want.
I have a few more additions I want to add, but really want some feedback if
people think this is a good idea or not.
--------------------------------
Steve Mactaggart
Systems Architect
Golftime International
WEB: http://www.golftime.com.au
RE: EnhancedHTMLAppender
Posted by Ceki Gülcü <ce...@qos.ch>.
At 01:26 PM 9/13/2004, Steve Mactaggart wrote:
>I agree with all of that comment, but I would refer to the previous emails
>about making and keeping the base styles very basic.
>
>I was thinking of defining styles for the default font, alternating lines,
>and styles for each level.
>
>I understand the discussion in relation to the complexity of css, but agree
>with previous statements that if we make the defaults work well, then there
>won't be a major reason to override them.
>
>My styles for the layout would be:
>
>.text {}
>.debug {}
>.debug2 {}
>.info {}
>.info2 {}
>.warn {}
>.warn2 {}
>.error {}
>.error2 {}
>.fatal {}
>.fatal2 {}
If the rows alternate between even and odd rows, we can specify an odd
debug line as <tr "class="odd debug">...</tr> and an even line as <tr
class="even debug">...</tr>. So the above list becomes:
debug {}
info {}
warn {}
error {}
fatal {}
even {}
odd {}
See http://www.w3.org/TR/REC-CSS2/selector.html for the exact details.
>I think this basic list would be simple to overwrite if the user felt the
>need to.
Given that the default rules will used in most cases, there will be
pressure to make the default rules look pretty and pleasant to the eye.
Thus, we cannot conclude that the default rules will be necessarily
simple. The point I am trying to make is that is that if the default rules are
embedded within the generated html file, then it will be hard, or at
least very confusing, for a non-expert user to override the defaults
css rules.
>Steve
--
Ceki Gülcü
For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: EnhancedHTMLAppender
Posted by Jacob Kjome <ho...@visi.com>.
Hi Ceki,
Quoting Ceki Gülcü <ce...@qos.ch>:
> At 07:46 PM 9/10/2004, Jacob Kjome wrote:
>
> >If the defaults are clearly defined, then it is simple to override those
> >properties.
>
> That is simply not true. Let me give you an example:
>
I think we have a different idea of the definition of "simplicity" and how one
would normally use CSS. Normally, default rules provide base minimum defaults
and are applied widely. Customizing is generally done within the context (and
with knowledge) of the inherited CSS rules.
Keep in mind what I've said: If we define rules in a way that one has to
override each and every last one of them to get things looking their own way,
then we've written the rules poorly, in which case we'd want to make sure the
defaults are reasonable.
Either way, if one has knowledge of the defaults, one can always override them.
In your case below, one could very well make a copy of that and modify/extend
as needed. Again, the fact that one would need to do this means the defaults
were written poorly. However, there is nothing complex here if you have half
an understanding of CSS. Anyone that would bother to take the time to override
defaults would probably understand this anyway. Otherwise, the idea is for the
defaults to be sane and general enough to stand on their own with only a need
to override, say..., colors or font.
If you disagree with this then you disagree with the CSS spec authors and I
won't continue an argument of this point. We'll have to agree to disagree and
a decision will have to be made about who's point of view is going to work best
for the EnhancedHTMLAppender. Obviously I think mine will work better, but the
final decision isn't up to me. I leave it to you and the community.
Jake
> Assume that the following CSS rule is *embedded* in the output of
> EnhancedHTMLAppender. The embedded rules are what you would call the
> default rules.
>
> H1.someclass {
> text-decoration: none;
> font-family: Helvetica, sans-serif;
> font-weight: bold;
> background: #DDD;
> color: #0066CC;
> border: 3px solid green;
> padding-left: 1em;
> padding-right: 1em;
> padding-top: 3px;
> padding-bottom: 0px;
> }
>
> Let the user include a CSS file (with the intent of overriding the
> default rules). Let that CSS file contain the following rule:
>
>
> H1.someclass {
> background: black;
> color: white;
> border-bottom: 1px solid red;
> }
>
> The actual applicable rule will be a combination of the embedded rule
> *and* the rule from the CSS file. If the embedded rule is mentioned
> before the CSS file, then the output will have a black back ground,
> white font and a red border-border but it will also rendered in bold,
> Helvetica font, with 3px green border at the top, left and right, in
> addition to the padding rules from the embedded CSS.
>
> CSS rules do not combine simply, far from it.
>
>
> --
> Ceki Gülcü
>
> For log4j documentation consider "The complete log4j manual"
> ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: EnhancedHTMLAppender
Posted by Steve Mactaggart <st...@golftime.com.au>.
>
> >If the defaults are clearly defined, then it is simple to
> override those
> >properties.
>
> That is simply not true. Let me give you an example:
>
> Assume that the following CSS rule is *embedded* in the output of
> EnhancedHTMLAppender. The embedded rules are what you would call the
> default rules.
>
> H1.someclass {
> text-decoration: none;
> font-family: Helvetica, sans-serif;
> font-weight: bold;
> background: #DDD;
> color: #0066CC;
> border: 3px solid green;
> padding-left: 1em;
> padding-right: 1em;
> padding-top: 3px;
> padding-bottom: 0px;
> }
>
> Let the user include a CSS file (with the intent of overriding the
> default rules). Let that CSS file contain the following rule:
>
>
> H1.someclass {
> background: black;
> color: white;
> border-bottom: 1px solid red;
> }
>
> The actual applicable rule will be a combination of the embedded rule
> *and* the rule from the CSS file. If the embedded rule is mentioned
> before the CSS file, then the output will have a black back ground,
> white font and a red border-border but it will also rendered in bold,
> Helvetica font, with 3px green border at the top, left and right, in
> addition to the padding rules from the embedded CSS.
>
> CSS rules do not combine simply, far from it.
>
I agree with all of that comment, but I would refer to the previous emails
about making and keeping the base styles very basic.
I was thinking of defining styles for the default font, alternating lines,
and styles for each level.
I understand the discussion in relation to the complexity of css, but agree
with previous statements that if we make the defaults work well, then there
won't be a major reason to override them.
My styles for the layout would be:
.text {}
.debug {}
.debug2 {}
.info {}
.info2 {}
.warn {}
.warn2 {}
.error {}
.error2 {}
.fatal {}
.fatal2 {}
I think this basic list would be simple to overwrite if the user felt the
need to.
Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: EnhancedHTMLAppender
Posted by Ceki Gülcü <ce...@qos.ch>.
At 07:46 PM 9/10/2004, Jacob Kjome wrote:
>If the defaults are clearly defined, then it is simple to override those
>properties.
That is simply not true. Let me give you an example:
Assume that the following CSS rule is *embedded* in the output of
EnhancedHTMLAppender. The embedded rules are what you would call the
default rules.
H1.someclass {
text-decoration: none;
font-family: Helvetica, sans-serif;
font-weight: bold;
background: #DDD;
color: #0066CC;
border: 3px solid green;
padding-left: 1em;
padding-right: 1em;
padding-top: 3px;
padding-bottom: 0px;
}
Let the user include a CSS file (with the intent of overriding the
default rules). Let that CSS file contain the following rule:
H1.someclass {
background: black;
color: white;
border-bottom: 1px solid red;
}
The actual applicable rule will be a combination of the embedded rule
*and* the rule from the CSS file. If the embedded rule is mentioned
before the CSS file, then the output will have a black back ground,
white font and a red border-border but it will also rendered in bold,
Helvetica font, with 3px green border at the top, left and right, in
addition to the padding rules from the embedded CSS.
CSS rules do not combine simply, far from it.
--
Ceki Gülcü
For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: EnhancedHTMLAppender
Posted by Jacob Kjome <ho...@visi.com>.
Quoting Ceki Gülcü <ce...@qos.ch>:
> Hi Steve,
>
> At 02:31 AM 9/8/2004, you wrote:
> >Long time no speak,
> >
> >I've been very slack on this front and as it seems that 1.3 is gathering
> >steam to get released I hope to get the EnhancedHTMLAppender completed in
> >the next week.
> >
> >After leaving it so long, and having to re-read the discussion to work out
> >where we were up to I think its time to solve this CSS issue.
> >
> >My suggestion is to hard-code styles into the top of the style sheet and
> >provide the user a property to change a link to override the default styles,
> >as suggested here:
> >
> > > ><HEAD>
> > > > <STYLE TYPE="text/css">
> > > > <!--
> > > > BODY { background-color: white }
> > > > -->
> > > > </STYLE>
> > > > <LINK REL=StyleSheet HREF="http://apache.org/~ceki/yellow.css"
> > > > TITLE="Basic"/>
> > > ></HEAD>
>
> Well, the above probably not such a good idea because the rules for style
> cascades are not that simple. Later rules add up on earlier rules except if
> they contain already existing properties in which case they mask older
> properties. In short, if there are more than one source for styles most
> users are likely to get very confused. We don't want to mislead or confuse
> users whenever we can help it.
>
If the defaults are clearly defined, then it is simple to override those
properties. The defaults don't have to be overly complex, but there ought to
be some defaults. Users creating custom stylesheets would simply read the docs
to see what the default styles are. Even then, if sane defaults are used,
there shouldn't be any reason for the user to override most of them. But if
they really wanted to, it would be simple to do so. Logging configuration is,
by far, more complex than this.
> The best solution I can think of consist of linking to a style located at a
> well-known URL by default but allow the user to override that default by
> specifying an alternative URL if need be. This approach will work out of
> the box in 95% of the cases and still allow developers to handle
> exceptional cases when necessary.
>
...except in the case where you are offline, then you won't have any styling
whatsoever unless you configured a custom local location for the css file.
Seriously, the defaults shouldn't be confusing. If they are, then the styles
weren't written properly. That's a development issue, not a user issue. The
linked stylesheet should only be for overriding defaults. The HTML file ought
to be able to be used in standalone mode rather than counting on an external
resource for any formatting.
>
> --
> Ceki Gülcü
Jake
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: EnhancedHTMLAppender
Posted by Ceki Gülcü <ce...@qos.ch>.
Hi Steve,
At 02:31 AM 9/8/2004, you wrote:
>Long time no speak,
>
>I've been very slack on this front and as it seems that 1.3 is gathering
>steam to get released I hope to get the EnhancedHTMLAppender completed in
>the next week.
>
>After leaving it so long, and having to re-read the discussion to work out
>where we were up to I think its time to solve this CSS issue.
>
>My suggestion is to hard-code styles into the top of the style sheet and
>provide the user a property to change a link to override the default styles,
>as suggested here:
>
> > ><HEAD>
> > > <STYLE TYPE="text/css">
> > > <!--
> > > BODY { background-color: white }
> > > -->
> > > </STYLE>
> > > <LINK REL=StyleSheet HREF="http://apache.org/~ceki/yellow.css"
> > > TITLE="Basic"/>
> > ></HEAD>
Well, the above probably not such a good idea because the rules for style
cascades are not that simple. Later rules add up on earlier rules except if
they contain already existing properties in which case they mask older
properties. In short, if there are more than one source for styles most
users are likely to get very confused. We don't want to mislead or confuse
users whenever we can help it.
The best solution I can think of consist of linking to a style located at a
well-known URL by default but allow the user to override that default by
specifying an alternative URL if need be. This approach will work out of
the box in 95% of the cases and still allow developers to handle
exceptional cases when necessary.
>I'll update the code over the next few days to support this and get an
>update file posted back to the list.
>
>Sorry for the HUGE delay,
>
>Steve
--
Ceki Gülcü
For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: EnhancedHTMLAppender
Posted by Steve Mactaggart <st...@golftime.com.au>.
Long time no speak,
I've been very slack on this front and as it seems that 1.3 is gathering
steam to get released I hope to get the EnhancedHTMLAppender completed in
the next week.
After leaving it so long, and having to re-read the discussion to work out
where we were up to I think its time to solve this CSS issue.
My suggestion is to hard-code styles into the top of the style sheet and
provide the user a property to change a link to override the default styles,
as suggested here:
> ><HEAD>
> > <STYLE TYPE="text/css">
> > <!--
> > BODY { background-color: white }
> > -->
> > </STYLE>
> > <LINK REL=StyleSheet HREF="http://apache.org/~ceki/yellow.css"
> > TITLE="Basic"/>
> ></HEAD>
I'll update the code over the next few days to support this and get an
update file posted back to the list.
Sorry for the HUGE delay,
Steve
> -----Original Message-----
> From: Jacob Kjome [mailto:hoju@visi.com]
> Sent: Saturday, 5 June 2004 9:51 AM
> To: Log4J Developers List
> Subject: RE: EnhancedHTMLAppender
>
> At 02:51 PM 6/4/2004 +0200, you wrote:
> >Hi Jacob,
> >
> >I very much like the solution you outlined.
>
> Happy to hear :-)
>
> >As you mentioned, my observation also show that the order in which
> >styles are listed has its importance.
> >
> >For example, in the following sample, the output will be white as the
> >embedded style listed last overrides the external style sheet listed
> >first
> >
> ><HEAD>
> > <LINK REL=StyleSheet HREF="http://apache.org/~ceki/yellow.css"
> > TITLE="Basic"/>
> >
> > <STYLE TYPE="text/css">
> > <!--
> > BODY { background-color: white }
> > -->
> > </STYLE>
> ></HEAD>
> >
> >Similarly, in the following sample, the output will be yellow as the
> >external style listed last overrides the embedded style sheet listed
> >first
> >
> ><HEAD>
> > <STYLE TYPE="text/css">
> > <!--
> > BODY { background-color: white }
> > -->
> > </STYLE>
> > <LINK REL=StyleSheet HREF="http://apache.org/~ceki/yellow.css"
> > TITLE="Basic"/>
> ></HEAD>
>
> Yep
>
> >Is this precedence rule documented somewhere?
>
> Actually, this is the definition of the cascade.
> http://www.w3.org/TR/CSS21/cascade.html#cascade
>
> Here's a more clear order of the cascade presented by Ian
> Hixson, one of
> the CSS spec authors
> http://bugzilla.mozilla.org/show_bug.cgi?id=43220#c105
>
> For our purposes, the main thing we need to remember is rule
> #4 of the spec:
>
> "Finally, sort by order specified: if two rules have the same weight,
> origin and specificity, the latter specified wins. Rules in
> imported style
> sheets are considered to be before any rules in the style
> sheet itself. "
>
> As long as the user specified style sheet writes rules with
> at least the
> same weight and specificity of the default style sheet, the
> user specified
> style sheet will successfully override the default if it
> comes last in the
> cascading order.
>
>
> Jake
>
>
> >If take the precedence rule for granted, then as you suggested, we
> >could embed a default style in the HTML and override it with a custom
> >style specified by the user.
> >
> >We could even have:
> >
> ><HEAD>
> > <STYLE TYPE="text/css">
> > <!--
> > default style here
> > -->
> > </STYLE>
> > <LINK REL=StyleSheet
> HREF="http://logging.apache.org/css/default.css"
> > TITLE="Default style"/>
> > <LINK REL=StyleSheet HREF="user specified css"
> TITLE="User defined"/>
> ></HEAD>
> >
> >In summary, we should be able to provide robust solutions as long as
> >the precedence rules are clearly understood.
>
> Yep, and they certainly are well understood. This is a good
> solution. BTW, what "default style" would you provide in the
> default.css
> that the inline <style> wouldn't already have? I see that as
> redundant. However, having a style sheet with media="print" defining
> styles to be used only when printing might be valuable to link from
> logging.apache.org.
>
>
> Jake
>
>
>
> >At 06:07 AM 6/4/2004, Jacob Kjome wrote:
> >
> >>I have to imagine that the style stuff for
> EnhancedHTMLLayout would be
> >>pretty sparse. The structure of the document will be pretty
> >>standard. In-lining styles (meaning <sometag style="">) in
> this case
> >>would be tantamount to using <font> tags given the sheer
> amount of markup
> >>written. However, one can add a style for the whole
> document in the head
> >>without having to import it which solves both the redundant
> style="" and
> >>non-existent external file issues. In fact, that can be
> the default
> >>stylesheet and a linked one can be added later in the
> cascade to provide
> >>an override for anyone to utilize. If the linked one
> doesn't exist, only
> >>the default applies. If the linked one exists, then that
> linked css file
> >>has the ability to override and extend the styles. For instance...
> >>
> >><style type="text/css">
> >>html, body { ... }
> >>a { .... }
> >>...
> >>...
> >>...
> >></style>
> >><link rel="Stylesheet" type="text/css" href="[user defined
> path set via
> >>some property of layout]/log4jhtmllayout.css" title="Custom Style">
> >>
> >>One can also provide alternate style sheets or even ones
> specifically for
> >>printing. These can be either always provided with
> standard css file
> >>names and only used in the cascade if they exist (as is
> shown above) or
> >><link> tags can be written as they are set via some property of the
> >>Layout class.
> >>
> >>Thoughts?
> >>
> >>Jake
> >
> >--
> >Ceki Gülcü
> >
> > For log4j documentation consider "The complete log4j manual"
> > ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> >For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: EnhancedHTMLAppender
Posted by Jacob Kjome <ho...@visi.com>.
At 02:51 PM 6/4/2004 +0200, you wrote:
>Hi Jacob,
>
>I very much like the solution you outlined.
Happy to hear :-)
>As you mentioned, my observation also show that the order in which
>styles are listed has its importance.
>
>For example, in the following sample, the output will be white as the
>embedded style listed last overrides the external style sheet listed
>first
>
><HEAD>
> <LINK REL=StyleSheet HREF="http://apache.org/~ceki/yellow.css"
> TITLE="Basic"/>
>
> <STYLE TYPE="text/css">
> <!--
> BODY { background-color: white }
> -->
> </STYLE>
></HEAD>
>
>Similarly, in the following sample, the output will be yellow as the
>external style listed last overrides the embedded style sheet listed
>first
>
><HEAD>
> <STYLE TYPE="text/css">
> <!--
> BODY { background-color: white }
> -->
> </STYLE>
> <LINK REL=StyleSheet HREF="http://apache.org/~ceki/yellow.css"
> TITLE="Basic"/>
></HEAD>
Yep
>Is this precedence rule documented somewhere?
Actually, this is the definition of the cascade.
http://www.w3.org/TR/CSS21/cascade.html#cascade
Here's a more clear order of the cascade presented by Ian Hixson, one of
the CSS spec authors
http://bugzilla.mozilla.org/show_bug.cgi?id=43220#c105
For our purposes, the main thing we need to remember is rule #4 of the spec:
"Finally, sort by order specified: if two rules have the same weight,
origin and specificity, the latter specified wins. Rules in imported style
sheets are considered to be before any rules in the style sheet itself. "
As long as the user specified style sheet writes rules with at least the
same weight and specificity of the default style sheet, the user specified
style sheet will successfully override the default if it comes last in the
cascading order.
Jake
>If take the precedence rule for granted, then as you suggested, we
>could embed a default style in the HTML and override it with a custom
>style specified by the user.
>
>We could even have:
>
><HEAD>
> <STYLE TYPE="text/css">
> <!--
> default style here
> -->
> </STYLE>
> <LINK REL=StyleSheet HREF="http://logging.apache.org/css/default.css"
> TITLE="Default style"/>
> <LINK REL=StyleSheet HREF="user specified css" TITLE="User defined"/>
></HEAD>
>
>In summary, we should be able to provide robust solutions as long as
>the precedence rules are clearly understood.
Yep, and they certainly are well understood. This is a good
solution. BTW, what "default style" would you provide in the default.css
that the inline <style> wouldn't already have? I see that as
redundant. However, having a style sheet with media="print" defining
styles to be used only when printing might be valuable to link from
logging.apache.org.
Jake
>At 06:07 AM 6/4/2004, Jacob Kjome wrote:
>
>>I have to imagine that the style stuff for EnhancedHTMLLayout would be
>>pretty sparse. The structure of the document will be pretty
>>standard. In-lining styles (meaning <sometag style="">) in this case
>>would be tantamount to using <font> tags given the sheer amount of markup
>>written. However, one can add a style for the whole document in the head
>>without having to import it which solves both the redundant style="" and
>>non-existent external file issues. In fact, that can be the default
>>stylesheet and a linked one can be added later in the cascade to provide
>>an override for anyone to utilize. If the linked one doesn't exist, only
>>the default applies. If the linked one exists, then that linked css file
>>has the ability to override and extend the styles. For instance...
>>
>><style type="text/css">
>>html, body { ... }
>>a { .... }
>>...
>>...
>>...
>></style>
>><link rel="Stylesheet" type="text/css" href="[user defined path set via
>>some property of layout]/log4jhtmllayout.css" title="Custom Style">
>>
>>One can also provide alternate style sheets or even ones specifically for
>>printing. These can be either always provided with standard css file
>>names and only used in the cascade if they exist (as is shown above) or
>><link> tags can be written as they are set via some property of the
>>Layout class.
>>
>>Thoughts?
>>
>>Jake
>
>--
>Ceki Gülcü
>
> For log4j documentation consider "The complete log4j manual"
> ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>For additional commands, e-mail: log4j-dev-help@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: EnhancedHTMLAppender
Posted by Ceki Gülcü <ce...@qos.ch>.
Hi Jacob,
I very much like the solution you outlined.
As you mentioned, my observation also show that the order in which
styles are listed has its importance.
For example, in the following sample, the output will be white as the
embedded style listed last overrides the external style sheet listed
first
<HEAD>
<LINK REL=StyleSheet HREF="http://apache.org/~ceki/yellow.css"
TITLE="Basic"/>
<STYLE TYPE="text/css">
<!--
BODY { background-color: white }
-->
</STYLE>
</HEAD>
Similarly, in the following sample, the output will be yellow as the
external style listed last overrides the embedded style sheet listed
first
<HEAD>
<STYLE TYPE="text/css">
<!--
BODY { background-color: white }
-->
</STYLE>
<LINK REL=StyleSheet HREF="http://apache.org/~ceki/yellow.css"
TITLE="Basic"/>
</HEAD>
Is this precedence rule documented somewhere?
If take the precedence rule for granted, then as you suggested, we
could embed a default style in the HTML and override it with a custom
style specified by the user.
We could even have:
<HEAD>
<STYLE TYPE="text/css">
<!--
default style here
-->
</STYLE>
<LINK REL=StyleSheet HREF="http://logging.apache.org/css/default.css"
TITLE="Default style"/>
<LINK REL=StyleSheet HREF="user specified css" TITLE="User defined"/>
</HEAD>
In summary, we should be able to provide robust solutions as long as
the precedence rules are clearly understood.
At 06:07 AM 6/4/2004, Jacob Kjome wrote:
>I have to imagine that the style stuff for EnhancedHTMLLayout would be
>pretty sparse. The structure of the document will be pretty
>standard. In-lining styles (meaning <sometag style="">) in this case
>would be tantamount to using <font> tags given the sheer amount of markup
>written. However, one can add a style for the whole document in the head
>without having to import it which solves both the redundant style="" and
>non-existent external file issues. In fact, that can be the default
>stylesheet and a linked one can be added later in the cascade to provide
>an override for anyone to utilize. If the linked one doesn't exist, only
>the default applies. If the linked one exists, then that linked css file
>has the ability to override and extend the styles. For instance...
>
><style type="text/css">
>html, body { ... }
>a { .... }
>...
>...
>...
></style>
><link rel="Stylesheet" type="text/css" href="[user defined path set via
>some property of layout]/log4jhtmllayout.css" title="Custom Style">
>
>One can also provide alternate style sheets or even ones specifically for
>printing. These can be either always provided with standard css file
>names and only used in the cascade if they exist (as is shown above) or
><link> tags can be written as they are set via some property of the Layout
>class.
>
>Thoughts?
>
>Jake
--
Ceki Gülcü
For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: EnhancedHTMLAppender
Posted by Jacob Kjome <ho...@visi.com>.
I have to imagine that the style stuff for EnhancedHTMLLayout would be
pretty sparse. The structure of the document will be pretty
standard. In-lining styles (meaning <sometag style="">) in this case would
be tantamount to using <font> tags given the sheer amount of markup
written. However, one can add a style for the whole document in the head
without having to import it which solves both the redundant style="" and
non-existent external file issues. In fact, that can be the default
stylesheet and a linked one can be added later in the cascade to provide an
override for anyone to utilize. If the linked one doesn't exist, only the
default applies. If the linked one exists, then that linked css file has
the ability to override and extend the styles. For instance...
<style type="text/css">
html, body { ... }
a { .... }
...
...
...
</style>
<link rel="Stylesheet" type="text/css" href="[user defined path set via
some property of layout]/log4jhtmllayout.css" title="Custom Style">
One can also provide alternate style sheets or even ones specifically for
printing. These can be either always provided with standard css file names
and only used in the cascade if they exist (as is shown above) or <link>
tags can be written as they are set via some property of the Layout class.
Thoughts?
Jake
At 10:18 AM 6/4/2004 +1000, you wrote:
> >
> > You probably know it already but it may be useful to mention it here.
> > An external style sheet can be specified using the <link> tag.
> >
> > <head>
> > <link rel="stylesheet" type="text/css" href="mystyle.css" />
> > </head>
> >
> > http://www.w3schools.com/css/css_howto.asp
> > The user can specify the location of the external CSS file as an
> > argument to EnhancedHTMLLayout. The output of EnhancedHTMLLayout would
> > contain a link to this location. We could also place a default CSS
> > file on our Apache server. So if no style sheet were specified, the
> > default one would be used. Note that the link can point to a local CSS
> > file allowing the user to have complete control over the output style.
>
>I like the idea, but what about when reading the logs off line, it would
>loose all formatting and possibly be hard to read. It also means that if we
>change the central css then all existing files would be changed too.
>
>I was possibly thinking of loading the css data into memory and copy it as a
>set of inline styles, then the system could load the styles from the users
>local file, or the apache servers or if neither are accessible, a default
>set of hard coded styles. This allows the styles to be externally
>configurable, but still keep them contained within the html generated by the
>HTMLLayout.
>
> >
> >
> > >I also want to do things like highlighting rows based on
> > basic filters too,
> > >not sure how much overkill that is, but a basic way to show
> > DEBUG, INFO,
> > >WARN, ERROR lines in different colors would be nice.
> >
> > That could be easily achieved by marking DEBUG event in a special
> > "debug" class. Similarly, event of level INFO would be making as
> > belonging to the "info" class and so forth.
> >
>
>That's what I was thinking, but also looking at whether an option for some
>regexps <--> classes could exist.
>
>They could then define a style called "important-line" and set up a rexexp
>to match a certain condition and then we apply this "important-line" style
>to that line. This would extend to support LEVEL.DEBUG <--> "debug" style,
>etc...
>
>Steve
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>For additional commands, e-mail: log4j-dev-help@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: EnhancedHTMLAppender
Posted by Ceki Gülcü <ce...@qos.ch>.
At 02:18 AM 6/4/2004, Steve Mactaggart wrote:
>I like the idea, but what about when reading the logs off line, it would
>loose all formatting and possibly be hard to read.
That is a very important observation. The output should be readable
when the user is off line. More on this later.
>It also means that if we change the central css then all existing files
>would be changed too.
I really don't see anything wrong with that. Assuming the changes in
the central CSS are for the better, no one should complain if they can
benefit from the improved style, that without lifting an elbow.
>I was possibly thinking of loading the css data into memory and copy it as a
>set of inline styles, then the system could load the styles from the users
>local file, or the apache servers or if neither are accessible, a default
>set of hard coded styles. This allows the styles to be externally
>configurable, but still keep them contained within the html generated by the
>HTMLLayout.
OK, I see. You are proposing that the style be embedded into the HTML
at the time it is generated. However, what happens when the specified
style sheet is not available in the environment generating the HTML
but available in the environment where the HTML is read? For example,
the CSS could be a file local to the user reading the HTML unavailable
on the server generating the logs.
Assuming we can come up with a robust solution to the offline case you
mentioned, it does not seem wise to forgo the dynamic capabilities of
CSS.
> >
> >
> > >I also want to do things like highlighting rows based on
> > basic filters too,
> > >not sure how much overkill that is, but a basic way to show
> > DEBUG, INFO,
> > >WARN, ERROR lines in different colors would be nice.
> >
> > That could be easily achieved by marking DEBUG event in a special
> > "debug" class. Similarly, event of level INFO would be making as
> > belonging to the "info" class and so forth.
> >
>
>That's what I was thinking, but also looking at whether an option for some
>regexps <--> classes could exist.
>
>They could then define a style called "important-line" and set up a rexexp
>to match a certain condition and then we apply this "important-line" style
>to that line. This would extend to support LEVEL.DEBUG <--> "debug" style,
>etc...
That's already quite advanced. I'd prefer to get the basic CSS right
before tackling more advanced problems. But all said and done, its
the developer doing the work who gets to decide.
>Steve
--
Ceki Gülcü
For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: EnhancedHTMLAppender
Posted by Steve Mactaggart <st...@golftime.com.au>.
>
> You probably know it already but it may be useful to mention it here.
> An external style sheet can be specified using the <link> tag.
>
> <head>
> <link rel="stylesheet" type="text/css" href="mystyle.css" />
> </head>
>
> http://www.w3schools.com/css/css_howto.asp
> The user can specify the location of the external CSS file as an
> argument to EnhancedHTMLLayout. The output of EnhancedHTMLLayout would
> contain a link to this location. We could also place a default CSS
> file on our Apache server. So if no style sheet were specified, the
> default one would be used. Note that the link can point to a local CSS
> file allowing the user to have complete control over the output style.
I like the idea, but what about when reading the logs off line, it would
loose all formatting and possibly be hard to read. It also means that if we
change the central css then all existing files would be changed too.
I was possibly thinking of loading the css data into memory and copy it as a
set of inline styles, then the system could load the styles from the users
local file, or the apache servers or if neither are accessible, a default
set of hard coded styles. This allows the styles to be externally
configurable, but still keep them contained within the html generated by the
HTMLLayout.
>
>
> >I also want to do things like highlighting rows based on
> basic filters too,
> >not sure how much overkill that is, but a basic way to show
> DEBUG, INFO,
> >WARN, ERROR lines in different colors would be nice.
>
> That could be easily achieved by marking DEBUG event in a special
> "debug" class. Similarly, event of level INFO would be making as
> belonging to the "info" class and so forth.
>
That's what I was thinking, but also looking at whether an option for some
regexps <--> classes could exist.
They could then define a style called "important-line" and set up a rexexp
to match a certain condition and then we apply this "important-line" style
to that line. This would extend to support LEVEL.DEBUG <--> "debug" style,
etc...
Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: EnhancedHTMLAppender
Posted by Ceki Gülcü <ce...@qos.ch>.
At 04:48 AM 5/29/2004, you wrote:
>Ceki,
>
> >
> > Is the diff file against CVS head or was it against log4j 1.2.8?
>
>It should be against the CVS head.
Indeed, the patch worked without a hitch.
> >
> > I think instead of manually setting colors, font and what
> > have you, we
> > could use a CSS file. A default version could be placed on
> > the Logging
> > Services project's web-site. The user should be able to
> > specify a CSS file
> > of her own as an option. What do you think?
>
>I like the idea, but how would the generated html page find the css to use
>it? I use this layout in conjunction with the SMTPAppender, and so I'm not
>sure how u could send it along?
You probably know it already but it may be useful to mention it here.
An external style sheet can be specified using the <link> tag.
<head>
<link rel="stylesheet" type="text/css" href="mystyle.css" />
</head>
http://www.w3schools.com/css/css_howto.asp
The user can specify the location of the external CSS file as an
argument to EnhancedHTMLLayout. The output of EnhancedHTMLLayout would
contain a link to this location. We could also place a default CSS
file on our Apache server. So if no style sheet were specified, the
default one would be used. Note that the link can point to a local CSS
file allowing the user to have complete control over the output style.
>I also want to do things like highlighting rows based on basic filters too,
>not sure how much overkill that is, but a basic way to show DEBUG, INFO,
>WARN, ERROR lines in different colors would be nice.
That could be easily achieved by marking DEBUG event in a special
"debug" class. Similarly, event of level INFO would be making as
belonging to the "info" class and so forth.
--
Ceki Gülcü
For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: EnhancedHTMLAppender
Posted by Steve Mactaggart <st...@golftime.com.au>.
Ceki,
>
> Is the diff file against CVS head or was it against log4j 1.2.8?
It should be against the CVS head.
>
> I think instead of manually setting colors, font and what
> have you, we
> could use a CSS file. A default version could be placed on
> the Logging
> Services project's web-site. The user should be able to
> specify a CSS file
> of her own as an option. What do you think?
I like the idea, but how would the generated html page find the css to use
it? I use this layout in conjunction with the SMTPAppender, and so I'm not
sure how u could send it along?
I also want to do things like highlighting rows based on basic filters too,
not sure how much overkill that is, but a basic way to show DEBUG, INFO,
WARN, ERROR lines in different colors would be nice.
>
> In PatternConverter.java, I find the name of the new
> getParseName method a
> little confusing. How about just getName()?
getName() is perfectly fine, some times the obvious is easiest.
>
> Again, kudos for this very neat contribution. Thank you and
> sorry for the
> delay in responding.
That's fine, I can see its been busy around there.
Re: EnhancedHTMLAppender
Posted by Ceki Gülcü <ce...@qos.ch>.
Steve,
This is a wonderful nice solution. Let me you ask you a few questions.
Is the diff file against CVS head or was it against log4j 1.2.8?
I think instead of manually setting colors, font and what have you, we
could use a CSS file. A default version could be placed on the Logging
Services project's web-site. The user should be able to specify a CSS file
of her own as an option. What do you think?
In PatternConverter.java, I find the name of the new getParseName method a
little confusing. How about just getName()?
Again, kudos for this very neat contribution. Thank you and sorry for the
delay in responding.
At 03:34 AM 5/18/2004, Steve Mactaggart wrote:
>I have got an initial version of the updated HTMLAppender created.
>I have called it the EnhancedHTMLAppender at the moment, so you can run both
>and see the differences, but I hope to replace the existing one once this is
>completed.
>
>This Appender requires a change to some other classes, and these changes are
>included in the patch.
>
>I have added a "public String getParseName()" to the PatternConverter to
>enable the header of the HTMLAppender to title each column. For this method
>to return valid information, each subclass needs an implementation of this
>method and those changes are also supplied.
>
>The new HTMLAppender can be configured in the same way as the existing one,
>but the default layout is pretty basic.
>
>I'd suggest a format like:
> <layout class="org.apache.log4j.EnhancedHTMLLayout">
> <param name="ConversionPattern" value="%d{dd MMM yy
>H:mm:ss}%t%-20.20c{1}%-5.5p%m"/>
> </layout>
>
>This is just a initial version, to get out to people for feedback, it works
>fine for me and has been tested, but doesn't have all the bells that I
>eventually want.
>I have a few more additions I want to add, but really want some feedback if
>people think this is a good idea or not.
>
>--------------------------------
>Steve Mactaggart
>Systems Architect
>Golftime International
>WEB: http://www.golftime.com.au
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>For additional commands, e-mail: log4j-dev-help@logging.apache.org
--
Ceki Gülcü
For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org