Hi Florian and all.
What about:
sed "s/setEventMessage(\(.*\),\s?\(.*\)/setEventMessages(\1, null, \2/"
Regexp are not that hard to cook once you grasp the working internals and
the building recipes.
Reading them is a little bit more involved though.
This one searches for "setEventMessage(" captures anything until the next
comma into the first capture group, then searches for any whitespace or
none and captures the rest into the second capture group.
The second part builds what you want as a result using the captured values.
The whole thing is assembled in the standard search and replace sed fashion
of "s/search/replace/".
Please make sure you have a backup handy before applying.
Also be extra careful if applying recursively to the source tree (using
find or similar).
You really want to ignore that .git folder or it will eat your repository
for breakfast (been there, done that).
Also remember that it's processed line by line, so something like:
setEventMessage(
aaaa,
bbbb
)
Will not be processed.
I use ack (or ack-grep in Debian) everyday to check for those sort of
things.
The beauty of ack is that it understands source-code, is recursive by
default, has color highlighting and line numbering.
Try
ack --php "setEventMessage[^s]"
at your project's root.
It may very well be the only thing you need.
If you want to learn more about regexp, I can't recommend enough "Mastering
Regular Expressions" by Jeffrey Friedl. It changed my life! (Really!)
Cheers,
2015-08-20 10:39 GMT+02:00 Florian HENRY <[email protected]>:
> Hello,
>
> That already the case in most of the times, deprecated function/method
> put warning log that said Method will be deprecated (good exemple is hook
> resprint feature with multicompany, in 3.6 it was a warning, in 3.7 it is
> an error into log (but still works)). The setEventMessage produced a
> warning log message but this line have been commented because this function
> is used by setEventMessages :
> function setEventMessage($mesgs, $style='mesgs')
> {
> //dol_syslog(__FUNCTION__ . " is deprecated", LOG_WARNING);
> This is not deprecated, it is used by setEventMessages function
>
> In object world we should said private method, but is is a function not a
> method.
>
> My point wasn't to open discution about retrocompatibility.
> To my mind, even if I can be upset when my modules didn't work anymore on
> new dolibarr version cause of change into core, I accept it and take time
> to upgrade my module, that why we sell them, not only to pay dutty on them
> but to have fund to upgrade them. In other case, put should give for free
> on Dolistore.
> In most of case, change in dolibarr core goal is to cleanup bad code or
> make it better and I can't imagine that you can agreed that.
> On the other hands, an exemple is canvas feature, it was broken, and
> Christophe, you discover it and complain on this mailling list, and it was
> fixed, thank to you I can use them now. This kind of stuff is always tricky
> because only module use it, and see a regression is not easy with standard
> units test. Only module developpers can be aware of that.
> Change table column name like fk_soc to fk_thirdparty is a very good idea,
> it will break a lot's of stuff but allow automation stuff like thirdparty
> fusion feature (in 3.8), I prefer to review my code in this case rather
> than open SQL manager to check the column name in each table because on
> time it's id another rowid, or fk_sod, or socid, or fk_thirdparty... As
> Laurent said during the devcamp : "step by step, no big bang", but after 2
> years of deprecated function/method it seems to be enought to take time to
> upgrade modules.
>
> My two cents.
>
>
> Florian Henry+33 6 03 76 48
> [email protected]http://www.open-concept.pro
> Twitter : @_Open_Concept_
> Google+ : https://www.google.com/+Open-conceptPro
>
> Le 19/08/2015 22:41, Charles Benke a écrit :
>
>
>
> Propose to add a specific log trace for use of retrocompatibility function
>
>
>
> Bien cordialement,
>
> Charlie Benke
>
>
>
> *De :* [email protected] [
> mailto:[email protected]
> <[email protected]>] *De la part de*
> Laurent Destailleur (aka Eldy)
> *Envoyé :* mercredi 19 août 2015 20:51
> *À :* Posts about Dolibarr ERP & CRM development and coding
> <[email protected]> <[email protected]>
> *Objet :* Re: [Dolibarr-dev] Question about sed RegExp for
> setEventMessages
>
>
>
> That's the way it is now.
>
>
>
> But we can't maintaint all retrocompatibility functions for ever. If we
> did that, dolibarr code should be currently 2 or 3 times larger in code
> line than it is now making it not possible to be enhanced. That's why
> retrocompatibility for very used function is kept only during 1 or 2 year
> only and why we will remove this deprecated function one day.
>
>
>
>
>
>
>
> 2015-08-19 17:19 GMT+02:00 Christophe Battarel <
> [email protected]>:
>
> Best answer: retrocompatibility !!! Lets's have a setEventMessage function
> that calls the new one !
>
> *J'ai l'impression de me répéter et de pisser dans un violon parfois...*
>
> Le 19/08/2015 16:47, Florian HENRY a écrit :
>
> Hello all,
>
>
>
> Do you have in your basket a shell script (I imagine with sed and
>
> regexp) or any tools that can update externals modules (to be ready when
>
> setEventMessage will be remove to setEventMessages) ?
>
>
>
> The game is change
>
> setEventMessage(aaa,bbb);
>
> to
>
> SetEventMessages(aaaa,null,bbbb);
>
>
>
> Regards
>
>
>
>
>
> --
>
> <small><i>Christophe Battarel<br/>
>
> Responsable technique Altairis</i><br/>
>
> +33 (0)9 52 71 70 96</small>
>
>
> _______________________________________________
> Dolibarr-dev mailing list
> [email protected]
> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
>
>
>
>
>
> --
>
> EMail: [email protected]
>
> Web: http://www.destailleur.fr
>
>
> ------------------------------------------------------------------------------------
>
> Google+: https://plus.google.com/+LaurentDestailleur/
> Facebook: https://www.facebook.com/Destailleur.Laurent
>
> Twitter: http://www.twitter.com/eldy10
>
>
> ------------------------------------------------------------------------------------
>
> * Dolibarr (Project leader): http://www.dolibarr.org (make a donation for
> Dolibarr project via Paypal: [email protected])
>
> * AWStats (Author) : http://awstats.sourceforge.net (make a donation for
> AWStats project via Paypal: [email protected])
>
> * AWBot (Author) : http://awbot.sourceforge.net
>
> * CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net
>
>
>
>
>
>
> _______________________________________________
> Dolibarr-dev mailing
> [email protected]https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
>
>
>
> _______________________________________________
> Dolibarr-dev mailing list
> [email protected]
> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
>
>
--
*Raphaël Doursenaud*
Directeur technique (CTO)
Expert certifié en déploiement Google Apps
<https://gpcsolutions.fr/raphael-doursenaud-google-apps-certified-deployment-specialist>
+33 (0)5 35 53 97 13 - +33 (0)6 68 48 20 10
--
<http://gpcsolutions.fr>
http://gpcsolutions.fr
Technopole Hélioparc
2 avenue du Président Pierre Angot
64053 PAU CEDEX 9
SARL GPC.solutions au capital de 7 500 € - R.C.S. PAU 528 995 921
<http://wiki.dolibarr.org/index.php/Dolibarr_suppliers_France#GPC.solutions>
_______________________________________________
Dolibarr-dev mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
