> Right, errors should never be exposed, and error_reporting should be 0 in > production but log function and the fact you can move Formaldehyde with the > application means it does not require extra effort.
No, display_errors should be turned off (with log_errors turned on) and error_reporting should be set to whatever standard you're coding to (preferably, E_ALL | E_STRICT, but a lot of people like to ignore E_NOTICE's). > In few words, if in production Formaldehyde constant is false, and it must be > false, nothing will be exposed. So it's not zero configuration, then? > You do not need to change your code if you configure properly the defined > constant while you can use what logs have to offers plus you'll have 1:1 > production/development application How do I configure a constant without changing code? And I wasn't aware that a 1:1 development:production environment was a desirable thing. Things like xdebug, display_errors, inclued, etc. should be disabled for production and enabled for development. > That simplicity is not offered so far by your suggested one as well, and > please tell me how quick could be an instant PHP error "on screen" during > tests or debug rather than a log analysis but in any case, thanks for the > feedback. Run "tail -f /path/to/your/php/error.log" and watch the error logs as they're appended, if you need instant error notification. Honestly, I'm sure it sounds like this by now but I'm not trying to trash your application, but you've not done a very good job selling it. It looks like you took some keywords ("ajax", "zero configuration", "portable", etc. etc.) and tried to apply them to your project, without actually seriously describing what your project is. As best I can tell, your project doesn't do much other than facilitate php debugging with Firebug, which is a very niche thing to do and any development cycle that I've been a part of has had no need to do such things, so I'm still failing to see Formaldahyde's usefulness. Maybe I've missed something? > > This is the only serious analysis so far, and I am looking forward for > others, if any. > > Best Regards > >> The thing is, in a properly configured development environment, it's >> local, so I can immediately read the logs, or just fire the script up >> with xdebug, or the errors will get caught in the editor. And I would >> NEVER imagine publicly exposing error messages in a production >> environment, so I'm just really confused as to what this offers, other >> than some seemingly small benefit in readability, specifically in >> firebug (and some other cruft that you really ought to remove, like >> the X-Formaldehyde header). And furthermore, this requires code >> changes from development -> production, which is a problem I've always >> had with FirePHP, too, as that information does not belong in a >> production environment. As far as support for shared hosting is >> concerned, I've stated on this list several times that my firm opinion >> is shared hosting is shooting yourself in the foot (especially as a >> good VPS isn't that much more expensive, I'm paying $20/mo for mine). >> >> I think you best summed up why so many on this list think Formaldehyde >> isn't a very useful product yourself: the errors are shown on the >> client side. In theory, a good development environment already >> exposes this information to the developer and things should fail a lot >> more gracefully than error output for the user. You said that this >> project is something that doesn't already exist, perhaps you should >> consider that it doesn't exist because a sane development cycle >> precludes Formaldehyde's usefulness? >> >> -- >> PHP General Mailing List (http://www.php.net/) >> To unsubscribe, visit: http://www.php.net/unsub.php >> > > _________________________________________________________________ > Show them the way! Add maps and directions to your party invites. > http://www.microsoft.com/windows/windowslive/products/events.aspx -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php