#12 error and info console

[JT Moree]

Therew will be 2 divs with id's consoleHeader and
consoleBody. consoleHeader can be absolutely
positioned and sized by the user and should be
always visible. The code will probably force the
visibility part and possibly set the zindex to make it
be above everything else.

The generateConsole() method will output the div's into
the current object (or would it output a string which
the programmer can $doc->print($doc->generateConsole);
? The developer can overload css entries to absolutely
position it, etc. if they so desire. Otherwise it
will be placed in the flow of the document based on
when you call it, so I'm just going to write into the
body string at the point you call me and I'm not going
to try and force it to be at the top/bottom/whatever.

The div consoleHeader will display "Console name | #
unread/new | Show/Hide button". We need to come up
with the "Console name" string and if we want #unread
or # new, etc.

The consoleBody div will be auto positioned under the
consoleHeader when it is displayed and the width/height
will be auto determined based upon the number of
entries to show (kindof like the searchBox does).

The methods pcxWarn, pcxError, pcxInfo will take an
object that defines the data to be displayed and a
boolean value that indicates if the console should be
displayed if hidden. The # unread will be updated
regardless. The object will contain at least the
following:

objtype - info, warn, error, critical?
line - line number
file - name of file the error is in
message - message to display
prgname - name of the program - optional (only used by
contact)
prgversion - version of the program - optional (only
used by contact)
type - js, db, user-input, etc. (This is totally user
definable and is just a filter for us)
email - e-mail address the contact form should be sent to.

JT says - having both type and objtype is redundant.
make the system flexible enough to just use type and
let users define new types if you really want that
functionality.

The reason I'm suggesting an object is that we can then
add extra attributes to work with for different objtype
values without having to go back and rewrite a lot of
function calls down the road.

The display code will then allow the user to not only
show All or just specify an objtype, but will also
provide a drop-down (possibly multi-select) of all the
unique type's defined for that objtype and allow the
user to just show them or all type's if desired. (JT
says clean that up. have type be the filter and no
subtypes.)

The user may want to allow or disallow messages. put a
boolean check on the console for the user to toggle.
the function should check it before unhiding the
consoleBody.

Errors of type js could add a link to popup the true js
console and thus be able to get at the source of the error.

If the contact email is specified, then I would provide
a "contact developer" link and when clicked it would
display the current js error handler form with all the
info populated to allow the user to send a bug report.

When the user clicks on an entry, the #unread/new will
be decremented in the consoleHeader div. That entry
will visibly change so the user knows it has focus and
the "Delete" button will then become available. The
"Delete All" button will always be available, as long
as there are entries in the console.