Developers have this function. It is called setEventMessages (with s). setEventMessage has become useless. Version with s can deal both error with a single string and error with arrays, and even error instring + error in arrays.
2014-10-31 10:38 GMT+01:00 Marcos García <marcos...@gmail.com>: > I agree that errors should be an array instead of string, but my original > question is: > > Why deprecating setEventMessage? They can both exist. Or we can accept a > string in setEventMessages and do a type check. > > My point was that is interesting for developers to have both a function that > allows adding a single error and adding a couple of errors. > > Regards, > > > > Marcos García > > marcos...@gmail.com > > > 2014-09-27 14:51 GMT+02:00 Destailleur Laurent <e...@destailleur.fr>: >> >> That's why I introduced the new function and make old one depracated. >> So compatibility is guaranted, even with old modules. >> >> 2014-09-26 21:09 GMT+02:00 Christophe Battarel >> <christophe.batta...@altairis.fr>: >> > Agree with Marcos, especially because all external modules using >> > strings... >> > Regards >> > >> > Le 25/09/2014 12:26, Marcos García a écrit : >> > >> > But the question was why will we remove the string? ~ 90 % of usage is >> > just >> > a string. And I don't get why moving to arrays if we only use strings. >> > >> > Regards, >> > >> > >> > Marcos García >> > >> > marcos...@gmail.com >> > >> > >> > 2014-09-24 17:23 GMT+02:00 Destailleur Laurent <e...@destailleur.fr>: >> >> >> >> We must be able to provide BOTH the string and the array, that are 2 >> >> different content during the same call. >> >> This for a transitionnal need. >> >> >> >> In future the string will be forgotten. >> >> >> >> >> >> 2014-09-22 1:59 GMT+02:00 Marcos García <marcos...@gmail.com>: >> >> > But what is the problem with having an string or and array in the >> >> > same >> >> > argument? An is_array check should be made but I think that is more >> >> > comfortable than using 2 params... Another way could be using >> >> > setEventMessage for string and setEventMessages for a set of >> >> > strings... >> >> > >> >> > Regards, >> >> > >> >> > >> >> > Marcos García >> >> > >> >> > marcos...@gmail.com >> >> > >> >> > >> >> > 2014-09-22 1:08 GMT+02:00 Destailleur Laurent <e...@destailleur.fr>: >> >> >> >> >> >> If you do so, you must provide a string XOR an array. >> >> >> In past only string was used. More and more we try to store errors >> >> >> into >> >> >> array. >> >> >> But for a transition need, we need both parameters (a lot of part of >> >> >> code currently store error into string AND other errors into array). >> >> >> So we need to provide both type at same time to function. >> >> >> >> >> >> 2014-09-22 1:00 GMT+02:00 Marcos García <marcos...@gmail.com>: >> >> >> > Hi: >> >> >> > >> >> >> > I've noticed that setEventMessage is now a deprecated function and >> >> >> > setEventMessages should be used instead. >> >> >> > >> >> >> > Its signature is >> >> >> > function setEventMessages($mesg, $mesgs, $style='mesgs') >> >> >> > where $mesg is for a string and $mesgs is filled when we want to >> >> >> > attach >> >> >> > an >> >> >> > array of messages. >> >> >> > >> >> >> > My question is... why doing this and not doing a setEventMessage >> >> >> > where >> >> >> > the >> >> >> > first param can be either an array or a string? I must say I don't >> >> >> > really >> >> >> > like functions that act differently depending on 1st or 2nd param >> >> >> > filled. >> >> >> > >> >> >> > Regards, >> >> >> > >> >> >> > >> >> >> > Marcos García >> >> >> > >> >> >> > marcos...@gmail.com >> >> >> > >> >> >> > >> >> >> > _______________________________________________ >> >> >> > Dolibarr-dev mailing list >> >> >> > Dolibarr-dev@nongnu.org >> >> >> > https://lists.nongnu.org/mailman/listinfo/dolibarr-dev >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> Laurent Destailleur (alias Eldy) >> >> >> >> >> >> >> >> >> >> >> >> ------------------------------------------------------------------------------------ >> >> >> Social networks of my OpenSource projects: >> >> >> Dolibarr Google+: https://plus.google.com/+DolibarrOrg/ >> >> >> Dolibarr Facebook: https://www.facebook.com/dolibarr >> >> >> Dolibarr Twitter: http://www.twitter.com/dolibarr >> >> >> AWStats Google+: https://plus.google.com/+AWStatsOrgPoject/ >> >> >> AWStats Facebook: https://www.facebook.com/awstats.org >> >> >> AWStats Twitter: http://www.twitter.com/awstats_project >> >> >> >> >> >> _______________________________________________ >> >> >> Dolibarr-dev mailing list >> >> >> Dolibarr-dev@nongnu.org >> >> >> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > Dolibarr-dev mailing list >> >> > Dolibarr-dev@nongnu.org >> >> > https://lists.nongnu.org/mailman/listinfo/dolibarr-dev >> >> > >> >> >> >> >> >> >> >> -- >> >> Laurent Destailleur (alias Eldy) >> >> >> >> >> >> ------------------------------------------------------------------------------------ >> >> Social networks of my OpenSource projects: >> >> Dolibarr Google+: https://plus.google.com/+DolibarrOrg/ >> >> Dolibarr Facebook: https://www.facebook.com/dolibarr >> >> Dolibarr Twitter: http://www.twitter.com/dolibarr >> >> AWStats Google+: https://plus.google.com/+AWStatsOrgPoject/ >> >> AWStats Facebook: https://www.facebook.com/awstats.org >> >> AWStats Twitter: http://www.twitter.com/awstats_project >> >> >> >> _______________________________________________ >> >> Dolibarr-dev mailing list >> >> Dolibarr-dev@nongnu.org >> >> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev >> > >> > >> > >> > >> > _______________________________________________ >> > Dolibarr-dev mailing list >> > Dolibarr-dev@nongnu.org >> > https://lists.nongnu.org/mailman/listinfo/dolibarr-dev >> > >> > >> > >> > -- >> > Christophe Battarel >> > Responsable technique >> > sarl altairis >> > Informatique et Web en Grésivaudan >> > 33 Grande Rue >> > 38570 Goncelin >> > 09 52 71 70 96 (appel local) >> > cont...@altairis.fr >> > http://www.altairis.fr >> > >> > >> > _______________________________________________ >> > Dolibarr-dev mailing list >> > Dolibarr-dev@nongnu.org >> > https://lists.nongnu.org/mailman/listinfo/dolibarr-dev >> > >> >> >> >> -- >> Laurent Destailleur (alias Eldy) >> >> ------------------------------------------------------------------------------------ >> Social networks of my OpenSource projects: >> Dolibarr Google+: https://plus.google.com/+DolibarrOrg/ >> Dolibarr Facebook: https://www.facebook.com/dolibarr >> Dolibarr Twitter: http://www.twitter.com/dolibarr >> AWStats Google+: https://plus.google.com/+AWStatsOrgPoject/ >> AWStats Facebook: https://www.facebook.com/awstats.org >> AWStats Twitter: http://www.twitter.com/awstats_project >> >> _______________________________________________ >> Dolibarr-dev mailing list >> Dolibarr-dev@nongnu.org >> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev > > > > _______________________________________________ > Dolibarr-dev mailing list > Dolibarr-dev@nongnu.org > https://lists.nongnu.org/mailman/listinfo/dolibarr-dev > -- Laurent Destailleur (alias Eldy) ------------------------------------------------------------------------------------ Social networks of my OpenSource projects: Dolibarr Google+: https://plus.google.com/+DolibarrOrg/ Dolibarr Facebook: https://www.facebook.com/dolibarr Dolibarr Twitter: http://www.twitter.com/dolibarr AWStats Google+: https://plus.google.com/+AWStatsOrgPoject/ AWStats Facebook: https://www.facebook.com/awstats.org AWStats Twitter: http://www.twitter.com/awstats_project _______________________________________________ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
