Re: Re: Forum hacks

On Tuesday 16 October 2001 20:22, Joao Prado Maia wrote: > On Tue, 16 Oct 2001, Luc Saint-Elie wrote: > > The question of the messages is more complex because PEAR::BD > > returns error messages that are not linked to the specific web site > > but are programmatic or technical errors. > > In a user class you’ll have error that doesn’t come from a program > > (or a database ) error but form the web site strategy (for example > > you may want to have a website where ‘Garbage Can’ is not a allowed > > user name.... And I’m not a PEAR error management specialist but I > > suppose that "the user name Garbage Can is invalid please choose > > another one’ is not part of the standard set of error values ;-)) > > Bu perhaps am I wrong.... > > But why should a PEAR::DB error be different from a User error ? Why > not just create a bunch of error codes just like PEAR::DB does and > leave the correct error message, translated or not, be a > responsibility of the implementor of the called script ? More or less > he will have to develop an array of error messages tailored to his > needs for his website / application. > > The error codes would be there available on the class. Implementation > of appropriate error messages will be a matter for the developer of > the script. > > I'm trying to stress this because whatever way you do the translation > of the error messages (if you decide on doing that), I will probably > need to tailor the error message for my specific application. It > doesn't make much sense worrying about that if most of the users of > this class (I'm guessing that the majority of people will do the same > as me) will not use the default messages anyway ? In my pear/HTTP_Upload class I covered much of this stuff (error codes, text messages, translations). Text error messages is a good thing and the 99% of users will use them. Of course my system is limited in some areas (can not retrieve only the error code or can not pass args to error messages) but is easy to enhance. Also with the error stuff is only initialized when a error occurs speding up the app as you don't need to initialize/store a bunch of vars or constants. If you think that this kind of error system could benefit PEAR_User I could send you some code. Tomas V.V.Cox