If i join into a single parameter i can't provide both the string ->error and the parameter ->errors into one call.
2014-11-04 12:42 GMT+01:00 Marcos García <marcos...@gmail.com>: > But why don't you join the 1st and 2nd parameter into a unique one? > > Doing a typecheck will lead to one behavior or other. > > I find adding 2 parameters that do the same in a function is overcharging > it, that's why I suggested to keep both setEventMessage and > setEventMessages. > > https://github.com/Dolibarr/dolibarr/blob/b74bdb8f7d08bf192b129b514145cfdc48ca19f8/htdocs/core/lib/functions.lib.php#4162 > > * @param string $mesg Message string > * @param array $mesgs Message array > * @param string $style Which style to use ('mesgs' by default, 'warnings', > 'errors') > > Regards, > > > Marcos García > > marcos...@gmail.com > > > 2014-11-01 21:06 GMT+01:00 Destailleur Laurent <e...@destailleur.fr>: >> >> 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 > > > > _______________________________________________ > 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
