The following is some tester notes on what needs to be done to the entire
system. Currently this is just vaguely test related stuff copied from the
coders TODO.
In case it's not mentioned elsewhere, dropping a file called "TESTING" into the
matrix-RAD directory will turn on a boolean called "isTesting", which can be used
to enable or disable things during testing. Redirection of STDOUT and STDERR to
the bottom widgets is one thing that is disabled during TESTING.
Make matrix-DFS RFC 3271 compliant (The Internet is for everyone). RFC 1958
compliant (Architectural principles of the Internet).
Latest generic RFC's to conform to - 3365, 3339, 3272?, 3254, 3238, 3237, 3235,
3234?, 3184 (probably broken it already), 2223, 2119, 3157?, 3150:4.0, 3148?,
2026, 2306, 2434, 2277, 2506?, 2611, 2717, 2964.
Other RFC's of interest - 3205, 3156, 3135, 3117, 3081, 3080, 3040, 3143, 2659,
2616?, 2648, 2504, 2397, 2388, 2384, 2345, 2245, 2186, 2169, 1925, 1727, 1287, 1281.
Add RFC 2550 to Watch. Add a RFC 1437 viewer B-).
New RFC's of interest - 3401, 3402, 3403, 3404, 3405, 3406.
matrix-DFS is currently undergoing a massive ro-organization and split up,
including many code reviews. It's still a bit of a mess at the moment though. A
recent employer said that my Java skills are second to none. I write better than
this, I promise B-). Most of the recent stuff has been just a brain dump, get it
working and move on, sorry, hope it makes some sort of sense. Lots of little
hard coded things sprinkled throughout.
I'm probably trying to recreate a few things that exist in Java already. During
a recent code review I found out that I had duplicated the exception system, so
I rewrote it to use actual exceptions. Other things I might be trying to
recreate, and which should be the subject of later code reviews - beans,
RMI, listeners, name space management, media framework, factory methods, the
schedular, etc. On the other hand, some of that stuff is so loosely
defined that everybody does it different, and you are better off doing it
yourself than trying to work around all those differences. Since I'm just doing
a quick brain dump into Java of all the recent stuff, recreating things is often
quicker than trying to figure out how it works B-).
Some of this stuff we are duplicating coz while the 1.2 version works well, the
1.1.5 version still sucks, and that is what everybody is using.
The other major thing we are probably gonna recreate is the entire XML morass.
Note, this is a seperate issue from the actual XML support we will need for Ant,
Jabber, and Servlets. XML is a nightmare, looking worse every day, and specifically
for business. matrix-DFS is for the masses, and needs to be efficient. Let the
commercial world stick with their typically bloated procedures, it's what they
are comfortable with. Also note that the transmogrifier can reduce XML bloat.
The exception handling currently only uses SkangException, although several
others are defined. SkangExceptions must currently have a two digit error code
at the beginning. These error codes are defined in the Skang docs, note that
they all start with "-", so they are really only one digit. When we are using
the other Exception types, the two digits can go away, they are just a temporary
thing to pass the same info.
I suspect that reflect.getDeclared*() and reflect.get*() act differently in
different JVMs. That part needs a code review.
isValid() should set an isValid boolean in the widget object, and the invalid
widgets should have red backgrounds, or other similar visual cue. An error
message explaining what is wrong should also be set in the widget object, and
displayed in ERR during widget hover, also in red. POST should refuse while
postable widgets are invalid. Should also use isValid() for parameters,
complaining and ignoring invalid parameters.
The "dump" command is for dumping the last half hours worth of debugging info,
in exactly the same way the BPC_NO dump command works. Gotta standardize that.
Font and Textfield sizing seems to be a moving target. First, look for a JVM/OS specific
FontDetails.class, and ask it for details. If that isn't found, or when the user asks for it,
do a calibration. The font calibration routine first allocates a bit plane of ten times
the size it thinks the font is and fills it with white. Then it prints the first 256
characters in the middle, overlapping each other. Finally, it scans in from the edges to
find out how big the font really is and the baseline, etc. Textfield calibration must
first use the pixel scanning technique to find characters that will go to the edges
selected from the usual suspects (!|\/_$%#ypgj{}?wmWM). Then starting from the the bare
minimum size (max font height), add widget of that size to big blank canvas, scan it to
check if all of the text is visible, and increase the size by one to try again if not.
I thought of doing something similar to find invalid characters for UberMatrix. The
JVM/OS specific FontDetails.class can either use the 1.2 API if available, "just return
valid" all the time, or do a pixel by pixel compare to a known invalid character. Pixel
by pixel compare will be very slow, so we need to cache results and/or do the compare at
the beginning. The main problem with that is that the old computers with ancient JVM's
that are likely to need this won't have the RAM or performance to spare, hence the "just
return valid" option. For the "Font Challenged", "just return valid" only for 8 bit ASCII,
all others are "invalid".
Code bloat reduction review.
This file was last modified on Saturday, 30-Oct-2004 12:40:11 EST