For the first time, not only I’ll be attending as I’ll also be part of SugarCon – the biggest event about CRM – this year uniquely focused on the individual.
If you’re attending as well, feel free to stop by and say hello.
That’s right, a new version of Open Exchange Rates library is out. The previous version was released in past October when I released my first two SugarCRM packages who also make use of it.
Since then, the Open Exchange Rates API has been continuously improved, which led to a perfect excuse to not only make an update but also to make an overall review of the library.
Not long ago, I wrote a post about the need of a free service that provided a variety of information related to currencies who led me to Open Exchange Rates: Real-time exchange rates for developers!
At that time I also mentioned how I had a couple of projects in mind related with the library I wrote then, curiously, one of these projects also matched a need felt by others: improving/automating the way how exchange rate updates are made in SugarCRM projects.
Two months later, more or less, I’m back with news regarding these projects: a few minutes ago I’ve released publicly, and more important, freely, my two first SugarCRM packages.
For the 3rd year in a row, I will be attending the biggest and geekiest event in Portugal!
Last week I was surfing the web looking for a free service that provided a variety of information related to currencies, namely: a list of currencies, their Iso4217 values and their exchange rates.
As you should know each SugarCRM view extends SugarView class which has a nifty method called _displayJavascript() who is responsible for including all needed JavaScript files.
When it comes to labels, by default, this function only loads current module labels into SUGAR.language.
What you need to do is inject some logic to clear selected field values before the view is displayed.
Like all other stuff made in SugarCRM, this process also depends on what type of module you’re hacking, in other words, the place where you’re going to write the logic depends if you’re hacking a custom module or a core one.
At times, while developing custom features in projects there’s a need to make date conversions.
Usually people tend to use strotime() indiscriminately, without being aware of its limitations. Although it is an awesome function, it needs to be used with care, otherwise it may lead to unexpected behaviors.
As last year, this year I will also participate in the event!
Thanks to DRI, this year I’m attending the event!