Re: Discussion - /jkstatus and stylesheets
Henri Gomez wrote: No problem for me to provide the result in XML, since I've got friend aroud which could provide me some nice XSL still sheet. Second advantage, the jkstatus could be used by others apps for example for monitoring purposes. +0 for XML (lack of time to works on this ;(). -0 - if someone wants to extract data and transform the output of /jkstatus - they can do it using XHTML DTD. Inventing yet another DTD and adding yet another layer - just because we can or we like complexity - is IMO a bad choice. So we should now define a DTD. There are already far too many DTDs. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion - /jkstatus and stylesheets
Thorsten Kamann wrote: Hello, Henri Gomez schrieb: Well I didn't like very well the hardcoded way, so I'd like to have it externally. We could : Define a stylesheet property var in workers2.properties, which will contains a full URL and if this var is null, fallback to previous method. Is there a chance the jk provides the status as xml? So the status can checked programmatically. With an nice XSL-Stylesheet I can integrate the status in every monitor page . Your comments? I think the status page should be in XML, and more specifically in XHTML. We can have all the "class" and "id" attributes that you need to define either a CSS or XSL stylesheet for programatic access. However I don't think inventing another XML format and then adding all the complexity of XSL to just view the status page is the best idea. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion - /jkstatus and stylesheets
Hello Henri Henri Gomez schrieb: No problem for me to provide the result in XML, since I've got friend aroud which could provide me some nice XSL still sheet. Second advantage, the jkstatus could be used by others apps for example for monitoring purposes. +0 for XML (lack of time to works on this ;(). So we should now define a DTD. Do we need multiple XMLs and DTDs. The jkstatus provides 4 different sites. Should the content of the 4 HTML-Pages merged into one XML? Do we need really a DTD? Is the configurations entry not to complex for a dtd? If you want I can try to create a draft of a jkstatus xml. Best regards Thorsten -- Thorsten Kamann Email: [EMAIL PROTECTED] ICQ: 40746578 Yahoo: ThorQue - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion - /jkstatus and stylesheets
Good morning All. I've not looked at XML or XSL for that matter, but in either case, hopefully this still means the colour palette/style selection is still external to the JK2 program, which then still requires a 'path' of some kind to find it. As noted in my initial introduction to the thread, this could either be a fixed or (preferably) a programatic one, and if the latter, adding a variable to the [status:] object still remains, IMO, the most logical option. Norm - Original Message - From: "Henri Gomez" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Thursday, April 01, 2004 7:57 PM Subject: Re: Discussion - /jkstatus and stylesheets > Craig McClanahan wrote: > > > jean-frederic clere wrote: > > > >> Thorsten Kamann wrote: > >> > >>> Hello, > >>> > >>> Henri Gomez schrieb: > >>> > >>>> Well I didn't like very well the hardcoded way, so I'd like to have it > >>>> externally. > >>>> > >>>> We could : > >>>> > >>>> Define a stylesheet property var in workers2.properties, which will > >>>> contains a full URL and if this var is null, fallback to previous > >>>> method. > >>> > >>> > >>> > >>> > >>> Is there a chance the jk provides the status as xml? So the status can > >>> checked programmatically. With an nice XSL-Stylesheet I can integrate > >>> the status in every monitor page . > >>> > >>> Your comments? > >> > >> > >> > >> Sounds a good idea to me. > >> > > Hmm .. separating the view from the model ... now where have I heard > > that before? :-) > > > > No problem for me to provide the result in XML, since I've got friend > aroud which could provide me some nice XSL still sheet. > > Second advantage, the jkstatus could be used by others apps for example > for monitoring purposes. > > +0 for XML (lack of time to works on this ;(). > > So we should now define a DTD. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion - /jkstatus and stylesheets
Craig McClanahan wrote: jean-frederic clere wrote: Thorsten Kamann wrote: Hello, Henri Gomez schrieb: Well I didn't like very well the hardcoded way, so I'd like to have it externally. We could : Define a stylesheet property var in workers2.properties, which will contains a full URL and if this var is null, fallback to previous method. Is there a chance the jk provides the status as xml? So the status can checked programmatically. With an nice XSL-Stylesheet I can integrate the status in every monitor page . Your comments? Sounds a good idea to me. Hmm .. separating the view from the model ... now where have I heard that before? :-) No problem for me to provide the result in XML, since I've got friend aroud which could provide me some nice XSL still sheet. Second advantage, the jkstatus could be used by others apps for example for monitoring purposes. +0 for XML (lack of time to works on this ;(). So we should now define a DTD. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion - /jkstatus and stylesheets
jean-frederic clere wrote: Thorsten Kamann wrote: Hello, Henri Gomez schrieb: Well I didn't like very well the hardcoded way, so I'd like to have it externally. We could : Define a stylesheet property var in workers2.properties, which will contains a full URL and if this var is null, fallback to previous method. Is there a chance the jk provides the status as xml? So the status can checked programmatically. With an nice XSL-Stylesheet I can integrate the status in every monitor page . Your comments? Sounds a good idea to me. Hmm .. separating the view from the model ... now where have I heard that before? :-) Best regards Thorsten Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion - /jkstatus and stylesheets
Thorsten Kamann wrote: Hello, Henri Gomez schrieb: Well I didn't like very well the hardcoded way, so I'd like to have it externally. We could : Define a stylesheet property var in workers2.properties, which will contains a full URL and if this var is null, fallback to previous method. Is there a chance the jk provides the status as xml? So the status can checked programmatically. With an nice XSL-Stylesheet I can integrate the status in every monitor page . Your comments? Sounds a good idea to me. Best regards Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion - /jkstatus and stylesheets
Hello, Henri Gomez schrieb: Well I didn't like very well the hardcoded way, so I'd like to have it externally. We could : Define a stylesheet property var in workers2.properties, which will contains a full URL and if this var is null, fallback to previous method. Is there a chance the jk provides the status as xml? So the status can checked programmatically. With an nice XSL-Stylesheet I can integrate the status in every monitor page . Your comments? Best regards Thorsten -- Thorsten Kamann Email: [EMAIL PROTECTED] ICQ: 40746578 Yahoo: ThorQue - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion - /jkstatus and stylesheets
NormW wrote:
Hi from Down Under.
Hi,
As an alternative to the above method I suggest use of an 'external'
stylesheet, which has the following advantages:
[snip]
1. Implement a stylesheet that emulates the current default colour/style
scheme,
2. Have the Developers choose one obtained by any method,
3. Make a 'request for suggestions' on the TC-user list.
I would like to suggest a 4. one:
test for presense of the the style property, and if not present fallback to
the hardcoded style Henri introduced.
* I don't see this as another method to obtaining a default stylesheet but
rather what to do if one isn't defined, much like so I guess:
if( style != NULL) {
s->jkprintf(env, s, "\n", style );
}
else {
s->jkprintf(env, s, "%s\n", DEFAULT_CSS);
}
Admittedly Henri's default
Re: Discussion - /jkstatus and stylesheets
NormW wrote: Good morning All. A recent initiative by Henri Gomez added support for a block in the return headers for /jkstatus pages, s->jkprintf(env, s, "