I also stalled out on using this, just because the doc was so old and did
not match what I was seeing. It really looks like it would be a nice
package if it had a little usability enginnerring, internals doc and was
brought up to at least php 4.2
--- In errorhandler@yahoogroups.com, Papp Győző <gerzson@p...>
wrote:
> Just in theory. Actually, it's almost dead, though I am very happy
if any one wants to help me out to continue with this project. I'm
using errorhandler in my job, but the package maintaining is stalled.
There are some devel version out there (in the yahoogroups files
folder for example). Last summer I started to upgrade EH up to the
most recent PHP version, but this effort also exhausted.
>
> Be brave and contribute! :)
>
I wish I had more time. This is a relatively big piece of code and I
don't think I would have the time to learn the internals to the point
where I could modify it.
It is really a shame. There is no production quality script like this
out there (at least nothing documented). If you were to update it I
might be able to help with some documentation. Unfortunately I need
to update my error handler now and if I end up writing my own I will
be less likely to have spare time...
culley
culleyharrelson írta:
> Hi,
>
> I just discovered ErrorHandler while researching ways to upgrade my
> existing errorhandling setup. I am very impressed. I wanted to know
> if any more work is going into this project. From the phpclasses
> page:
>
> http://www.phpclasses.org/browse.html/package/345
>
> It appears as if the most recent version is from 2002. Is this
> project still being maintained?
Just in theory. Actually, it's almost dead, though I am very happy if any one
wants to help me out to continue with this project. I'm using errorhandler in my
job, but the package maintaining is stalled. There are some devel version out
there (in the yahoogroups files folder for example). Last summer I started to
upgrade EH up to the most recent PHP version, but this effort also exhausted.
Be brave and contribute! :)
Best
Gyozo Papp
Hi,
I just discovered ErrorHandler while researching ways to upgrade my
existing errorhandling setup. I am very impressed. I wanted to know
if any more work is going into this project. From the phpclasses
page:
http://www.phpclasses.org/browse.html/package/345
It appears as if the most recent version is from 2002. Is this
project still being maintained?
culley
Enter your vote today! A new poll has been created for the
errorhandler group:
Will you send a short (10-20 lines)
description about how you are using this
class to include this in a user's manual?
o Yes. I'll send it to the list.
o No. I have no time for it, sorry.
To vote, please visit the following web page:
http://groups.yahoo.com/group/errorhandler/surveys?id=11360155
Note: Please do not reply to this message. Poll votes are
not collected via email. To vote, you must go to the Yahoo! Groups
web site listed above.
Thanks!
Enter your vote today! A new poll has been created for the
errorhandler group:
Do you understand the concept of ALTDLOG?
Have you tried it ever?
o Yes, and I use it.
o Yes, but I can't see the point where it could help me out.
o No, not clearly but I tried it once.
o No, and I haven't tried it yet.
o Hey, man? What? There isn't any docs yet from where I could figure out what
this magical abbrevation is.
To vote, please visit the following web page:
http://groups.yahoo.com/group/errorhandler/surveys?id=11360150
Note: Please do not reply to this message. Poll votes are
not collected via email. To vote, you must go to the Yahoo! Groups
web site listed above.
Thanks!
Enter your vote today! A new poll has been created for the
errorhandler group:
Several third-party packages (template,
forum, blog softwares image galleries
and so on) presume the error_level
directive in php.ini excludes E_NOTICE
(E_ALL & ~E_NOTICE). (In even worse
case, these softwares only work with a
specific error_level value, so you must
change your default settings ,for
example, in .htaccess file.) Thus using
them in an environment where error_level
is set to E_ALL (which is the right,
deliberated decision), lots of annoying
error messages are thrown and presented
to developers, though they are commonly
unlikely to fix bugs in a 3rd party
library. (Maybe send a bug report)
Do you want to see these error messages
which is fired by other one's code while
using such 3rd party packages?
o Yes, it might be helpful in some cases.
o It depends. A new ErrorHandler ini setting would serve my convenience to
switch on/off handling these errors.
o I think ALTDLOG sections should be the right place to handle this.
Unfortunately, ALTDLOG only deals with logging. Enhance this section to able to
discard the entire error handling for such an error.
o No, not at all. I worked around it somehow. (short .htaccess files in the
directories where these packages resides, or other solutions)
o Well, I don't understand the problem clearly. Please describe it more
precisely.
To vote, please visit the following web page:
http://groups.yahoo.com/group/errorhandler/surveys?id=11360142
Note: Please do not reply to this message. Poll votes are
not collected via email. To vote, you must go to the Yahoo! Groups
web site listed above.
Thanks!
The following errorhandler poll is now closed. Here are the
final results:
POLL QUESTION: Is it time to leave behind the
compatibility with PHP 4.0.6 and to
require a latter version of PHP for
ErrorHandler to work?
CHOICES AND RESULTS
- Yes, upgrade it to PHP 4.2.x, 2 votes, 28.57%
- Yes, upgrade it to PHP 4.1.x, 3 votes, 42.86%
- No, I still need a version for PHP 4.0.6, 2 votes, 28.57%
- Yes, upgrade it to PHP 4.3.0, 0 votes, 0.00%
INDIVIDUAL VOTES
- Yes, upgrade it to PHP 4.2.x
- rob@...
- gerzson@...
- Yes, upgrade it to PHP 4.1.x
- s-m-k@...
- adamx@...
- lists@...
- No, I still need a version for PHP 4.0.6
- saxtus@...
- michael@...
- Yes, upgrade it to PHP 4.3.0
For more information about this group, please visit
http://groups.yahoo.com/group/errorhandler
For help with Yahoo! Groups, please visit
http://help.yahoo.com/help/us/groups/
The following errorhandler poll is now closed. Here are the
final results:
POLL QUESTION: SOURCE 'block' support to alternative syntax
Note: I won't deal with this issue until
someone does not come up a feasible
implementation, or suggestion.
CHOICES AND RESULTS
- important & urgent, 0 votes, 0.00%
- important but I can wait., 1 votes, 25.00%
- it might be useful for someone else., 3 votes, 75.00%
- useless (It'll never be used.), 0 votes, 0.00%
INDIVIDUAL VOTES
- important & urgent
- important but I can wait.
- yahoo@...
- it might be useful for someone else.
- rob@...
- AlberT@...
- gerzson@...
- useless (It'll never be used.)
For more information about this group, please visit
http://groups.yahoo.com/group/errorhandler
For help with Yahoo! Groups, please visit
http://help.yahoo.com/help/us/groups/
Hi,
it's nice to hear such a good reviews about ErrorHandler. To be frank, the
beginning of this year, I was about to put all the informations together to
produce a so-called user's manual or (whatever it is said to be). After the
first enormous rousing I was stucked with it and this project was halted due
to organizing the first PHP conference in our country, in Hungary (You might
have seen it at php.net)
Since then, very new version of PHP has come out with interesting features.
Currently, I'm about to enhance and/or upgrade the full class to the recent
PHP branch before it becomes a hairy old-fashioned and unsupportable code.
Actually, all I can provide is a TODO list to the list members to see EH is
not dead. Please still hope or contribute with any little piece of information
or experience while installing, using or struggling with ErrorHandler.
Best regards,
--
Gyozo Papp
napiobai írta:
> I heard very good things about this class
> but now I am downloading and I don't see nothing on
> how to use it. I read Errorhandler.ini and even in the source code
>
> and still, just some example of use would be good, like
> show
>
> ugly messy code before Errorhandler
>
> nice cool code after Errorhandler
>
> I am thinking this will be very easy once I see
> good example.
>
>
>
> download: http://www.phpclasses.org/ErrorHandler
> development: http://members.chello.hu/pipolino/ErrorHandler/
> polls,docs: http://groups.yahoo.com/group/errorhandler/ (Yahoo!ID)
> rate it: http://freshmeat.net/rate/30757/
> unsubscribe: errorhandler-unsubscribe@yahoogroups.com
ErrorHandler TODO:
- session support
- documentation
- tokenizer => revamped SOURCE report (opening and closing PHP tags + new block
mode + new highlight source via css + variable values in tooltips)
=> affect on CONTEXT mode (finding variable variables)
- allow print_r() instead of built-in _sprint_var in CONTEXT report (similar to
var_export() )
Features in from other sources
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
errorReporter from Dan Allen (www.mojavelinux.com/forum/viewtopic.php?t=51)
1. "exclude class" not only variables (do not dump smarty, ADODB, etc.)
2. weep out repeated errors (regarding to the PHP .ini settings responsible for
the same thing)
3. customizable console window look'n feel (css)
4. click-on-bomb instead of automatically pop-up (choosable from .ini)
http://dev.izibox.isa-geek.org/NiceDebug/example.php ("David JL"
<izi@...>)
1. CONTEXT report layout may be replaced with a floating windows (tooltips if
scalar values) on demand
3 layout: raw, floating,
Questions
~~~~~~~~~
1. registering custom errorhandler would happen in constructor only, not when
including the script
2. there is an ini setting to ignore the repeated errors, but does it affect
custom error handling?
3. set() renamed to set_level() to lighten load_ini() and other methods
Upgrading to the latest PHP (4.3.0)
~~~~~~~~~~~~~~~~~~~~~~~~~~~
- revise ob functions neccessity
+ version_compare instead of phpversion
- array functions
- replace $HTTP_*_VARS with $_* superglobals
- debug_backtrace (there is a backport available for 4.2.0)
- possible use of new functions exchanging complex code blocks
- ready to use with session
+ set_error_handler supports object callback
I heard very good things about this class
but now I am downloading and I don't see nothing on
how to use it. I read Errorhandler.ini and even in the source code
and still, just some example of use would be good, like
show
ugly messy code before Errorhandler
nice cool code after Errorhandler
I am thinking this will be very easy once I see
good example.
Hi Michaël,
first let me thank you to report this issue The situation is that
there will be (are ?) some new .ini directives which have not been
published yet and possibly missing from your ini file
([CONTEXT]/display and [LOGGING]/timestamp). I attach and upload, too,
the recent ini file structure.
When I started ErrorHandler my assumption was that all the ini
directives must be set in the ini files so to avoid the unneccessary
and annoying use of isset(). Though I think this requirement is
correct and the class works correctly in this case, it may be worth
rethinking.
Best regards,
Gyozo Papp
Michaël Willemot írta:
> Hey group,
>
> Just found out about the ErrorHandler class and tried version 2.0.0
(alpha 6) out.
>
> Well...when the popup-window comes up which shows me my errors...i still
> get error-warnings in my own page:
>
> Notice: Undefined index: display in /<snip>/ErrorHandler.php on line 534
>
> Notice: Undefined index: timestamp in /<snip>/scms/ErrorHandler.php on
> line 613
>
> Probably this can easily been fixed with using the isset() function
>
>
> Greetz,
>
>
>
>
; ErrorHandler configuration settings
; written by : Gyozo Papp @: gerzson@...
; VERSION-CTRL : 2.0.0
; last modified : 2003.02.28.
;
; This file is distributed as the part of the ErrorHandler package
under the
; licence terms and conditions presented in ErrorHandler informational
page
; (see readme.1st)
; -- IMPORTANT NOTE --
; Each following directive (except LOCKED, LEVEL and level's) must be
specified
; in a proper .ini file, that is, must not be commented out or left
out. Use
; the special value 'Off' or leave blank, if you don't want to supply
any value
; at all. (ErrorHandler has no default setting from now on.)
; This file contains each allowed configuration directive. The ones
commented
; out are not supported yet, e.g. SESSION.
; Comments (lines starting with can be removed at will apart from the
; authoring and licencing information above.
; -- GLOBAL settings --
;
; LOCKED controls if ini settings be protected from run-time changes
or not.
;
; If LOCKED is On, then no default ini directive can be changed by calling
; set_*() methods, though you can still twist ErrorHandler object
properties
; owing to the PHP's OO limitation (lack of private properties).
(However, I
; worked around it).
;
LOCKED = Off ; On/Off - run-time changes rejected/allowed, resp.
; general error reporting level is either an integer, or named constant.
; Using named constants is strongly encouraged
LEVEL = E_VERY_ALL
; You can specify a callback function which manipulates the original error
; messages. It may be handy if you want to print a precise error
message in the
; FAULT page (see below) and to hide some sensitive information as well.
; The supplied function must take 4 arguments: (see example in try.php)
; (string) message, (int) level, (string) file_name, (int) line_no
CUSTOM = ; the name of the callback function, e.g
'msg_customize'
; if SILENT is turned ON (or an error page is specified in REPLACE),
then the
; CONSOLE window will not be displayed, thus error reports can be
examined only
; where the log messages have been sent to. Another effect is similar
to the @
; operator: it suppresses error reporting from the point where it is
turned ON.
SILENT = Off ; whether CONSOLE window displayed or not
; MUTE directs ErrorHandler to treat errors muted by '@' error-suppressing
; operator as regular (Off) or not (On), that is, do nothing with
respect to
; the intended effect of '@'. By turning on, errors in expression
prepended
; with @ will not be reported at all, though it still can be trapped.
MUTE = Off
; TRAPCLEAR specifies if the error trap should be emptied
automatically after
; querying with is_trapped() method.
TRAPCLEAR = On
; Please note that SESSION is NOT SUPPORTED yet!!!
; The following lines only describes my conception about how to use
; ErrorHandler in conjuction with PHP sessions.
; ErrorHandler can register itself in the SESSION, so it can retains error
; messages/reports between redirections, i.e. after header('Location:
...');.
; A standalone terminal may fetch the error messages generated in the main
; script. It can be very helpful in a production environment where you can
; perform a per-session debugging. Now, ErrorHandler is not able to
distinguish
; one session from the rest, and so, there is no way to dedicate a session
; which error reports can be handled differently. In short, either each
; user can see the CONSOLE window at a certain page and each error message
; generated by each individual request will be logged or none of them.
; The per-session debugging is intended to break through this limitation.
;
;[SESSION]
; whether ErrorHandler is used with session or not
; already "figured out" directives:
;output = 'terminal' ; 'console', 'terminal'
;authorize= ; name of a callback function responsible for
; authenticate the session
;reset = ; whether restores ini definition after/before
script be
; executed
[REPLACE]
level = ;E_ERROR_ALL ; what type of error should halt the script
page = onerror.html ; the file to be displayed if script halts
redirect= ; whether the page displays immediately or try to
; redirect the browers
; acceptable values to 'redirect' are:
; On/Off - display immediately (old behaviour)
; server - force header('Location: ...');
; client - print javascript code into the HTML
source.
; Note that using 'client' disables CONSOLE window implicitly! It
seems odd
; first, but it is deliberated decision. If you want to redirect on
the client
; side, HTML content has already been sent to the client, because, for
example,
; something must be display (clock, progress bar, etc.) If so, CONSOLE
window
; could not be displayed, because output buffering is disabled
(content has been
; flushed already). If not, why not you use 'server'-side redirect
instead?
; It's still your responsibility to flush the content.
; However, do not trust on this feature too much! There may be so many
softwares
; on so many environments involved, that I hardly believe it will ever
work
; without twisting ErrorHandler source code. Read more about output
buffering in
; the PHP Manual (especially flush() and ob_implicit_flush(), etc)
[SOURCE]
level = E_NOTICE_NONE ; what type of error invokes CUSTOM handler
lines = 3 ; how many lines extracted around the failed line
block = On ; experimental -- NOT RECOMMENDED for general
use!!!
; 'lines' must be declared regardless to the actual value of 'block'. If
; ErrorHandler is not able to find the block where the error occurred,
it will
; print out that number of lines before and after the failed line.
; (old behaviour)
; 'block' has very limited capabilites now. Neither does it handle
alternative
; syntax nor recognize control structures spanning multiple lines,
such as:
; if ( /* conditions in the 1st line ...*/
; /* conditions in the 2nd line ...*/){ // block starts
here
; Comments and '}' inside string literals can fool ErrorHandler as well.
[CONTEXT]
strict = On ; variables in the extracted source be dumped only
depth = 5 ; how deep nested variables will be traversed
(at most)
exclude = HTTP_ENV_VARS HTTP_SERVER_VARS _ENV _SERVER pwd passwd password
; under no circumstances excluded variables
should be
; displayed
display = extended ; the preferred dumping format: var_export or
extended
[LOGGING]
; the directive can be one of the LOG target constant such as
FILE_LOG, MAIL_LOG
; and SYSTEM_LOG. The actual value of the directive is the log
destination.
; The user, under whose account the webserver is running (www-data,
nobody,
; wwwrun, etc), must have write permission to the logfile.
; See the following examples!
level = E_ALL
timestamp= [%x %X %Z] ; Timestamp format at the beginning of the
error messages
encrypt = Off ; the name of the callback function to encrypt
; logmail message
collect = On ; collect error reports and send one mail per
request
; (using register_shutdown_function(), see PHP
Manual!)
FILE_LOG = /tmp/ErrorHandler.log
MAIL_LOG = your@...
SYSTEM_LOG = Off
; ALTDLOG -- Auto logging target detection
; You can specify additional log destinations to a specific file with
ALTDLOG.
; If an error occurs in a registered file, ErrorHandler sends a log
message to
; the specified location (it can either a file or a mail box, just
like LOGGING)
; (Please note that the LOGGING/encrypt setting affects ALTDLOG mails,
too.)
; The section name is the name of the file to be registered, it must
exists in
; the local file system. Allowed directives are the same as in LOGGING.
;
; The following sections are examples for ALTDLOG file registering
;
[ErrorHandler.inc]
level = E_VERY_ALL
MAIL_LOG = gerzson@...
[/path/to/your/file.php]
FILE_LOG = file.log
MAIL_LOG = mail@...
Hey group,
Just found out about the ErrorHandler class and tried version 2.0.0
(alpha 6) out.
Well...when the popup-window comes up which shows me my errors...i still
get error-warnings in my own page:
Notice: Undefined index: display in /<snip>/ErrorHandler.php on line 534
Notice: Undefined index: timestamp in /<snip>/scms/ErrorHandler.php on
line 613
Probably this can easily been fixed with using the isset() function
Greetz,
--
Michaël Willemot <michael@...>
The following errorhandler poll is now closed. Here are the
final results:
POLL QUESTION: LOGGING: support HTML formatted email logs
Error messages as shown in CONSOLE
window can be logged via mail, or
alternatively, the whole CONSOLE window
can be sent as HTML attachment, hence ,
for example, the source code would be
highlighted.
CHOICES AND RESULTS
- I need it, it would make me clearer the logs., 0 votes, 0.00%
- It wolud be nice! , 0 votes, 0.00%
- It may be useful, but I'm satisfied with the current possibilities., 2 votes,
50.00%
- I'm totally against it, emails wolud be 3-4 times longer consuming too much
resources., 2 votes, 50.00%
INDIVIDUAL VOTES
- I need it, it would make me clearer the logs.
- It wolud be nice!
- It may be useful, but I'm satisfied with the current possibilities.
- gerzson@...
- yahoo@...
- I'm totally against it, emails wolud be 3-4 times longer consuming too much
resources.
- AlberT@...
- rob@...
For more information about this group, please visit
http://groups.yahoo.com/group/errorhandler
For help with Yahoo! Groups, please visit
http://help.yahoo.com/help/us/groups/
The following errorhandler poll is now closed. Here are the
final results:
POLL QUESTION: And finally, here is a wish list. Choose
what you would like to see in the
upcoming relelases!
CHOICES AND RESULTS
- Featured CONSOLE window with "prev/next" linking, highlighting and better
looks. (see Dan Allen's implementation >> Links), 4 votes, 57.14%
- The availability of setting all directives belonging to the same INI section
with one function call. Now, each directive must be set individually at
run-time. If you wish, it might change.
, 1 votes, 14.29%
- To implement, or at least, to examine the per-session debugging capabilities.
(see notes about SESSION in the recent ini file.), 2 votes, 28.57%
- Any suggestions are welcome to the mailing list., 0 votes, 0.00%
INDIVIDUAL VOTES
- Featured CONSOLE window with "prev/next" linking, highlighting and better
looks. (see Dan Allen's implementation >> Links)
- gerzson@...
- rob@...
- AlberT@...
- ben.margolin@...
- The availability of setting all directives belonging to the same INI section
with one function call. Now, each directive must be set individually at
run-time. If you wish, it might change.
- yahoo@...
- To implement, or at least, to examine the per-session debugging capabilities.
(see notes about SESSION in the recent ini file.)
- gerzson@...
- AlberT@...
- Any suggestions are welcome to the mailing list.
For more information about this group, please visit
http://groups.yahoo.com/group/errorhandler
For help with Yahoo! Groups, please visit
http://help.yahoo.com/help/us/groups/
Enter your vote today! A new poll has been created for the
errorhandler group:
Is it time to leave behind the
compatibility with PHP 4.0.6 and to
require a latter PHP version for
ErrorHandler to work?
o Yes, PHP 4.3.0
o PHP 4.2.x
o PHP 4.1.x
o No, I still need a version for PHP 4.0.6
To vote, please visit the following web page:
http://groups.yahoo.com/group/errorhandler/surveys?id=11046106
Note: Please do not reply to this message. Poll votes are
not collected via email. To vote, you must go to the Yahoo! Groups
web site listed above.
Thanks!
Hello folks,
I inform you that the secondary site has been moved to another
location:
http://members.chello.hu/pipolino/ErrorHandler/
(Pipolino is the nickname of my dalmatian. No other reasonable idea
came to my mind what name to be used for my personal web space.)
The primary download location is _not_ changed, it still resides at:
http://www.phpclasses.org/ErrorHandler
I updated the groups website at Yahoo!:
* new polls about possible directions of development
(please vote or mail me or to the list what to add to EH!)
* new links related to ErrorHandler,
* development tarball in Files.
* DocBook skeletons for contributors of the documentation,
* change the mail signature containing the most relevant URLs.
> > Do you have some preference as to what tools to use to put together this
> > document? Are we aiming for HTML?
>
> Yes we are aiming for HTML, but from DocBook XML source through an
> automatic transformation with XSLT or DSSSL. I've been working on PHP
> Manual in the past, I've some experience about those products. If you
> are unfamiliar with those, it is not a problem.
>
> It is totally enough for me, if you write it text/plain (maybe with mose
> special markup for linking, etc. -- we'll discuss it), or .rtf.
>
If you'd like to get acquinted with the DocBook format without learning
the whole, I'll make a skeleton and you only need to fill it in with
your contributions. It would be more easier to assemble and maintain our
results, and mostly to produce documentation. What do you think?
--
Gyozo Papp
Enter your vote today! A new poll has been created for the
errorhandler group:
And finally, here is a wish list. Choose
what you would like to see in the
upcoming relelases!
o Featured CONSOLE window with "prev/next" linking, highlighting and better
looks. (see Dan Allen's implementation >> Links)
o The availability of setting all directives belonging to the same INI section
with one function call. Now, each directive must be set individually at
run-time. If you wish, it might change.
o To implement, or at least, to examine the per-session debugging
capabilities. (see notes about SESSION in the recent ini file.)
o Any suggestions are welcome to the mailing list.
To vote, please visit the following web page:
http://groups.yahoo.com/group/errorhandler/surveys?id=11012026
Note: Please do not reply to this message. Poll votes are
not collected via email. To vote, you must go to the Yahoo! Groups
web site listed above.
Thanks!
Enter your vote today! A new poll has been created for the
errorhandler group:
LOGGING: support HTML formatted email logs
Error messages as shown in CONSOLE
window can be logged via mail, or
alternatively, the whole CONSOLE window
can be sent as HTML attachment, hence ,
for example, the source code would be
highlighted.
o I need it, it would make me clearer the logs.
o It wolud be nice!
o It may be useful, but I'm satisfied with the current possiblities.
o i'm Totally against it. Emails wolud be 3-4 times longer consuming too much
resources.
To vote, please visit the following web page:
http://groups.yahoo.com/group/errorhandler/surveys?id=11012018
Note: Please do not reply to this message. Poll votes are
not collected via email. To vote, you must go to the Yahoo! Groups
web site listed above.
Thanks!
Enter your vote today! A new poll has been created for the
errorhandler group:
SOURCE 'block' support to alternative syntax
Note: I won't deal with this issue until
someone does not come up a feasible
implementation, or suggestion.
o important & urgent
o important but I can wait.
o it might be useful for someone else.
o useless (It'll never be used.)
To vote, please visit the following web page:
http://groups.yahoo.com/group/errorhandler/surveys?id=11012001
Note: Please do not reply to this message. Poll votes are
not collected via email. To vote, you must go to the Yahoo! Groups
web site listed above.
Thanks!
Hello,
This email message is a notification to let you know that
a file has been uploaded to the Files area of the errorhandler
group.
File : /EHTerm.tar.bz2
Uploaded by : gerzson17 <gerzson@...>
Description : This sample explains the Terminal concept. Unfortunately it is
not based on the recent version, but an uncompatible previous one.
You can access this file at the URL
http://groups.yahoo.com/group/errorhandler/files/EHTerm.tar.bz2
To learn more about file sharing for your group, please visit
http://help.yahoo.com/help/us/groups/files
Regards,
gerzson17 <gerzson@...>
Hello Rob,
rob wrote:
> Yes, I'd go for the second version too. I'm just thinking that what the
OK, now I'll finalize the exact division and names for chapters.
> reader wants and what we want to get across is
> 1) Why use EH and
> 2) How to use EH.
I wolud be very happy if you wrote some paragraphs about what you or
anyone else colud benefit from using EH. I'm always coding and trying to
add new features to it, and finally I'm just too tired to translate my
jumbled thoughts about why this and that would be useful and especially
in what cases.
> The section I) copyright etc goes first just so it gets read ;-)
Similar to
> what is in the original manual?
Yes. Though, IMHO, it is a matter of taste, and in other hand, it
doesn't matter where to put, if someone is interested, he will look for
it, but if not, just skip it.
> In II) Features, I would be concentrating on Why use EH. A short
description.
> Like some of what is in try.php
Yes, but I need to write a more convincing, demonstrative test page. It
is key point whether the chapter "Why use EH?" should explain what one
can see while testing the demo page (try.php). What do you think about it?
> A more in-depth discussion could follow.
OK.
> My immediate and selfish interest is in 2) How to use EH.
> I like the PHP installation instructions which have a very brief
step-by-step
> installation and test instructions - really useful the second time
around as
> a reminder - followed by a more detailed version.
> I'd like to include the obvious - put the ErrorHandler.inc file in your
> include directory - reported by phpinfo(). Put try.php in directory
your
> webserver serves.
You are welcome :))
> Put the .ini file in the same directory as ErrorHandler.inc (I just
found
> this out ! )
You are free to change the default ini path in ErrorHandler.inc to
assign new value to ERRORHANDLER_DEFAULT_INI contants at beginning of
the file or to supply the file location to constructor in the 1st argument.
> Do you have some preference as to what tools to use to put together this
> document? Are we aiming for HTML?
Yes we are aiming for HTML, but from DocBook XML source through an
automatic transformation with XSLT or DSSSL. I've been working on PHP
Manual in the past, I've some experience about those products. If you
are unfamiliar with those, it is not a problem.
It is totally enough for me, if you write it text/plain (maybe with mose
special markup for linking, etc. -- we'll discuss it), or .rtf.
The main thing is not to waste time to design the resulting pages, it is
up to the automatic transformation process (like PHP manual.) I'm
thinking about to use a stylesheet like used in the Postgres Manual.
--
Your turn,
Gerzson
Il 10:11, domenica 5 gennaio 2003, Gyozo Papp ha scritto:
> I vote for the last one. And you?
>
me too !!
:-)
--
<?php echo ' Emiliano `AlberT` Gabrielli '."\n".
' E-Mail: AlberT@... '."\n".
' Web: http://SuperAlberT.it '."\n".
' IRC: #php,#AES azzurra.com '."\n".'ICQ: 158591185'; ?>
Hello Rob,
this is far the best news I've heard since the first release :))
Please let me know what you need and what you want to do or what you
have done.
I already sketched the structure of the documentation very similar to
the PHP or Smarty manuals. Comment it! I was thinking a lot about what
would be the most appropiate:
a) telling everything about every feature and aspect of EH one by one
(going into details immediately chapter by chapter), which results
something like this:
I. CONTEXT (an sample chapter)
1. What it is?
2. INI settings
3. API (methods and properties)
4. changelog
_OR_
b) first give an outline, then show how to use it, and last but not
least reveal how it works, what the proper syntax is, what internals
must taken into consideration.
I. Acknowledgments - Copyright - Short Intro
II.Features Part
1... (you know :) CUSTOM, CONTEXT, SOURCE, LOGGING, ALTDLOG, etc ...
each one with a short example.
III.Usage Part
(How-tos, describing the most common and advanced use cases)
1. installation
2. upgrading - from now on, this chapter would comprize the
information about how to replace an earlier version with the new one
strongly considering what should be rewritten in your application (if
required).
3. common practise - debug and silent mode mainly
4. advanced tips
4.1 working with non-textual MIME outputs
(using while creating images, pdf-s, etc.)
4.2 per-session debugging
4.3
5. contributions - if any
IV.Reference Part
1. Ini file - complete reference of ini directives
(mainly copy from ini file)
2. Constants
3. Methods
4. Summary about EH parts with versioning
5. changelog (copy from readme.1st)
I vote for the last one. And you?
Please let me thank you again your kindness to help me improve the
documentation.