The JDisplay Java Applet
displays the large program listings on this web page.
JDisplay requires an up-to-date
browser and Java version
1.8+, preferably 1.8.0_131.
If you can’t see the listings, or if you just want to learn
more about JDisplay, click
Use Firefox for best results.
The CurrCon Java Applet displays prices on this
web page converted with today’s exchange rates into your local international currency,
e.g. Euros, US dollars, Canadian dollars, British Pounds, Indian Rupees…
CurrCon requires an up-to-date browser
and Java version 1.8, preferably 1.8.0_131.
If you can’t see the prices in your local currency,
Troubleshoot. Use Firefox for best results.
JDisplay is an Applet and back end to create the
various colourised listings you see all over my website. I released the source. It consists of parsers for
Java, HTML (Hypertext Markup Language),
SQL (Standard Query Language), XML (extensible Markup Language) and
BAT (Batch)
files that decide the colours and an Applet to display
and scroll the listings and a macro preprocessor to either expand small listings as
HTML inline
or generate an <applet invocation to an Applet to display it. If you can’t see the listings, here are
things to check:
To use JDisplay to display listings on this website, you must have
Java version 1.5
or later, preferably 1.8.0_131,
installed on your machine.
If you are using Microsoft Internet Explorer, try another browser. Seriously. Microsoft has taken great pains,
over and over, to screw up Java and every other multi-platform standardisation.
If you are using Internet Explorer 7, you must allow blocked content
permission for Active X to run. This also gives permission to Java to run.
Click the Information bar and then click Allow blocked content. Unfortunately, this also allows dangerous
ActiveX code to run. However, you must do this in order to get access to
perfectly-safe Java Applets running in a sandbox. This is part of Microsoft’s
war on Java. Don’t put up with it! Use a different browser.
Check the Java console for error
messages. If you don’t know how to interpret that message, feel free to email
me at
for help.
If you still can’t get the program working click HELP for more
detail.
If you don’t see anything, check out first that you can see Applets in general by looking at sample Applets and my Applet Collection, especially Wassup which will tell you which Java
version you have installed. If no Applets work, try
tracking down the problem with the help under JRE.
Advantages of Various Rendering Techniques
The inline approach is used for small snippets. The colourised snippets are
fully integrated into the web page. The user can copy/paste either the
HTML or the
rendered text. This approach does not require Java to work. Google will spider the
listings.
The iframe approach is used for mid-sized snippets. They appear in a scrolling
window. This lets the user skip over the entire listing quickly even if it is many
pages long. It does not require Java to work. It does require the browser to
support iframes. Google will spider the listings.
The Applet approach is used for large snippets. They appear in a scrolling
Applet window. Large snippets download quickly since they are compressed binary and
free of bulky HTML
style markup. The rendering is handled by the same code for all platforms.
HTML
is rendered slightly differently by every browser. You can download the raw source
code to a file by clicking a single button. Google will not spider the
listings.
Under the Hood
The JDisplay program is
more complicated that you would imagine, so you probably don’t want to be
bothered with it just to display a few listings. I use static macros to generate the
HTML, but you
could generate it by hand.
One project on my plate is offering a free webservice to convert your listings to
colourised HTML.
JDisplay, Firewalls and MIME (Multipurpose Internet Mail Extensions)
Types
If the problem is only with JDisplay, then
likely the problem is with your firewall interfering the JDisplay getting its listing files. The files have the following mime
types and extensions:
JDisplay file extensions and MIME
types
JDisplay file extensions and MIME
types
Extension
MIME
type
ser
application/x-java-serialized-object
bat
text/plain
batfrag
text/plain
java
text/x-java-source
javafrag
text/x-java-source
html
text/html
htmlfrag
text/html
sql
text/plain
sqlfrag
text/plain
xml
application/xml
xmlfrag
application/xml
If *.ser files are blocked, you will not see
anything. If any of the others are blocked, the download
button will fail.
While you are at it, you might as well check the complete list of MIME types to make sure you are not blocking any other
critical kinds of file downloads.
Improving the Look
JDisplay and my website in general were
designed with certain fonts in mind. If you don’t have them installed Java and
your browser will substitute others, which won’t have the same metrics which
means it might not look right. I suggest you install the following fonts:
If the fonts or the displays look flea-bitten, make sure you have anti-aliasing turned on.
Why Use JDisplay?
People have often asked me why I don’t just
embed listings directly in my web pages, perhaps decorated with
CSS (Cascading Style Sheets) style tags instead of fooling around with the JDisplay
Applet. I do, I generate decorated HTML,
but only for short listings. I use <iframes for medium sized ones and an Applet
renderer for long ones. For long ones, the data that the JDisplay Applet uses are
much more compact than the equivalent HTML.
With JDisplay, a long listing takes up only a small window on your screen. You an
ignore it if you are not interested. Inline listings would create a huge long
document to scroll through.
If you don’t have Java at all, you should see a button to download the
listing to view in place of the listing. The problem comes when you have a
malfunctioning Java. Then you won’t see anything at all.
Further, I am a Java evangelist. In particular I want to see more client-side Java
computing. I think this 100% server logic talking to a
browser, all the rage these days, is so sixties. So I demonstrate it where I can on
my site with JDisplay, the CurrCon currency displays and the many amanuenses Applets.
Extending JDisplay
You can add your own parsers to tokenize and colourise other languages or types of
structured text documents. Here are suggested steps to write your own parser:
Find a Tokenizer that for a language similar to
what you want to do. There currently exist ones for bat, C, http (headers), html,
ini, java, mft, properties, sql and plain text. Some tokenizer handle multiple
extensions. On my todo list are tokenizers for CSS
(partially complete), C source and ASM (Assembler)
source.
Look in com.mindprod.jprep where the XXXTokeniser decides which file extensions to handle, XXXState is the finite state machine for parsing the code. It does
not have the luxury of giving up if the text is malformed.
Look in com.mindprod.jtoken for the tokens. Each
token represents a chunk of text that is displayed with a single
CSS classes,
i.e. it has the same font, size and colour, though you can get fancy displaying
within token if you really want. It is a logical chunk of text that is considered a
fundamental unit.
Glance at com.mindprod.jdisplay where you will
find the code that renders your lists of token. It will not need changing.
You can ignore com.mindprod.htmlmacros.JDisplay,
the macro generator that will expand and render your tokens three ways and insert
them into HTML.
It will not need any changes either.
Write your XXXTokeniser decides which file
extensions to handle.
Hook up your XXXTokeniser code into
com.mindprod.jprep.JPrep.prepareAllSnippetsForOneDirectory()
so it will invoke your tokeniser when it encounters a file of one of the extensions
it handles.
Write your XXXCharCategory class to categorise which
characters have special meaning in the text you will process.
Compose new CSS styles in the style sheet, possibly separate from
your main one, so it only need be include on pages that use Display. This requires you to make up your mind about fonts, colours
and sizes of each token.
Do a mockup colourising some text in your language with your new styles. This
will help you notice if you have forgotten something, or if the results are ugly or
the contrasts are to garish or too subtle. The CSS
classes you create will define the tokens and token names you use in your Java
Token classes. It is a lot easier to play with your
mockup and style sheet to experiment with colour and font schemes than with Java
code.
Include the new colours in the Java source code for
com.mindprod.jtoken.TokenPalette
following the established naming convention. It would probably be safer to put your
colour purpose names in a private file, or to factor them out later.
Associate your tokens with colour names in the Java source code for
com.mindprod.jtoken.TokenColourScheme
following the established naming convention, by defining colour purpose names. This
sounds complicated, but if you look at the existing code, you will see this is easy
but tedious. It would probably be safer to put your colour purpose names in a
private file, or to factor them out later.
Write you various Token classes to control on the fonts, sizes colours and
CSS styles of
various chunks of text in your rendered text. You can use ones in the common
section, but don’t use tokens from other parsers. Just clone them.
Work out what your finite states will be, or work them out for a subset of the
entire problem. Build a giant nested case, for what you do when each character
category comes in when you are in each state. Just get the framework complete,
with all states and character category cases in alpha order. You could use a
parser generator like JavaCC, ANTLR (Another Tool for Language Recognition)
or YACC (Yet Another Compiler Compiler)
to create your parser and then traverse the parse tree emitting JDisplay-style
tokens to a *.ser file. I avoided that approach for
thrree reasons:
For some reason, I find writing state machines profoundly relaxing and
satisfying. I derive immense joy from watching them work right off the bat as a
whole, even when I created them thinking only about minute fraction of the
problem at a time.
Generated parsers tend to freak at imperfect code. They can’t even
complain coherently. A lowly colouriser has no business complaining. It has to
parse code fragments which are necessarily grammically incorrect according the
language specs.
My hand-coded parsers are wicked fast.
But go ahead and try it that way.
Thinking only about one state and one character category at the time, work out
what to do and what state to go into next.
Cannibalise freely from other finite state machines.
Proofread and desk check your finite state machine against some printed
text.
Debug/single step your finite state machine so you can see it is behaving as
you expected.
Throw all the text you can find at it, including malformed text to see if it is
rendering as you expect.
Test out the three modes of rendering, inline, iframe and Java Applet. It is
fairly easy to get the colours, fonts and sizes of the rendering done by Java and
by CSS styles out
of sync. This does no great harm, so long as both look ok, but I like to keep them
100% consistent.
Pass your code back to me for inclusion in the JDisplay packing if you are
willing to share it.
Here in the mockup I am working on for the CSS
parser:
a.affiliate:link,a.affiliate:hover,ul>li{ background:url(image/link/affiliate.png) transparent
no-repeat scroll 100% 70%; padding-right:12px;// a comment padding-top:6px!important;/* this is also a comment */ color:#bb00bb/*! loganberry
!*/ }
Please read the feedback from other visitors,
or send your own feedback about the site. Contact Roedy.
Please feel free to link to this page without explicit permission.
Canadian
Mind
Products
IP:[65.110.21.43]
Your face IP:[18.226.166.106]