If you’re attending as well, feel free to stop by and say hello.

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.

Going straight to the point let’s see the newly supported features in detail.

Concerning the rates services, previously, one could only fetch the full list – now there’s also the ability to fetch rates against a specific set of ISO 4217 values, thus retrieving only the exchange rates according to the latter. Furthermore, and as you probably know, the retrieved rates were calculated with USD as base rate, this has also changed, and at the moment one can also supply a specific ISO 4217 value to be used as a base rate.

Bellow follow a list of usage examples, who explain in detail how these new features work:

• How to retrieve latest exchange rates for specific Iso4217 values?
• How to retrieve exchange rates for a specific date and Iso4217 values?
• How to retrieve latest exchange rates with a base rate different than USD?
• How to retrieve latest exchange rates for specific Iso4217 values with a base rate different than USD?

As previously mentioned, an overall review of the library was also made, resulting in what I believe to be a very significant improvement, not only in terms of source code quality where the hand-written autoloader got replaced by the one supplied by Composer, PSR-0 compliant, but also with the cleanup made in order to also comply with PSR-2.

Concerning the library as a whole, there were also significant improvements, specially with the addition of unit tests, who are currently doing a code-coverage of 91.67%, and the setup of Travis CI, a hosted continuous integration service who makes sure  everything is working as supposed against PHP 5.3 and 5.4 versions.

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.

The first one, is Open Exchange Rates library for SugarCRM,  a package built to ease the pain of integrating the Open Exchange Rates library, in SugarCRM projects. The second one, actually depends on the first, is Currencies Exchange Rate Updater, a SugarCRM package designed to ease the process of updating active currencies exchange rates with the help of external data sources.

The video above, illustrates not only the installation process of these packages, but also the two different workflows supported by the latter, who enable an easy management of active currencies exchange rates updates. Either manually by filling latest rates values by hand or by importing these values from an external data source, or automatically, by defining a scheduler job who becomes responsible for performing this updates on a regular basis.

Both packages can be downloaded on SugarForge (here and here) and on GitHub (here and here) respectively.

Keep in mind that both packages are still beta, feel free to get in touch if you find some strange behavior, need any help or if you want to somehow contribute to any of these packages.

To finish, I would like to thank Joss Crowcroft for supporting the  Open Exchange Rates library developments by lending me a paid account in order to test paid services and Filipe Guerra for his feedback and help on testing both packages.

After a while I’ve found Open Exchange Rates, which seemed to answer all my needs.

It’s services are available in three flavours: one free for personal use, with a few restrictions and two other versions, which are paid but have support for a whole new set of features.

‘Cause I’ve a couple of projects in mind that would benefit of such data sources I decided to write a library to interact with such services, besides that, and because someone else might be looking for something similar I’ve also shared it on github.

Besides the documentation delivered with the code you can also take a look at the usage examples I’ve created in the project wiki.

Feel free to get in touch if you need any help or if you want to contribute to the library.

When it comes to labels, by default, this function only loads current module labels into SUGAR.language.

These labels are acessible through the following command:

SUGAR.language.get('<ModuleName>', 'LBL_<LabelName>');

In order to add support to other module labels to be included, you should override _displayJavascript() method in your modules view, and specify which other modules labels should be included.

// modules/<ModuleName>/views/view.edit.php

require_once 'include/MVC/View/views/view.edit.php';

class <ModuleName>ViewEdit extends ViewEdit
{
    protected function _displayJavascript()
    {
        parent::_displayJavascript();

        if (!$this->_getOption('show_javascript')) {
            return;
        }

        $modules = array(
            '<Module1Name>',
            '<Module2Name>',
        );

        foreach ($modules as $module) {
            if (!is_file($GLOBALS['sugar_config']['cache_dir'] . 'jsLanguage/' . $module . '/' . $GLOBALS['current_language'] . '.js')) {
                require_once 'include/language/jsLanguage.php';
                jsLanguage::createModuleStringsCache($module, $GLOBALS['current_language']);
            }
            echo '<script type="text/javascript" src="' . $GLOBALS['sugar_config']['cache_dir'] . 'jsLanguage/' . $module . '/' . $GLOBALS['current_language'] . '.js?s=' . $GLOBALS['js_version_key'] . '&c=' . $GLOBALS['sugar_config']['js_custom_version'] . '&j=' . $GLOBALS['sugar_config']['js_lang_version'] . '"></script>';
        }
    }
}

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.

Before you perform view customizations on core modules you should check first if the view is already implemented, in this case, you should check if the following file exists:

modules/<ModuleName>/views/view.edit.php

If so, you should create a new file on:

custom/modules/<ModuleName>/views/view.edit.php

and add further customizations.

Beware that on latest SugarCRM versions, you’re able to create custom views without having to copy all the logic from the core ones, and by that I mean that now you’re able to “truly” extend the custom views from the latter.

In order to achieve this the view name should be prefixed with ‘Custom’:

// custom/modules/<ModuleName>/views/view.edit.php

require_once 'modules/<ModuleName>/views/view.edit.php

class Custom<ModuleName>ViewEdit extends <ModuleName>ViewEdit {
    /** 
     * ...
     */
}

If by instance you’re hacking a core module that doesn’t have the view defined, you should create it like the example above but with a few differences:

// custom/modules/<ModuleName>/views/view.edit.php

require_once 'include/MVC/View/views/view.edit.php';

class Custom<ModuleName>ViewEdit extends ViewEdit {
    /** 
     * ...
     */
}

One thing to keep in mind is that if you’re hacking a custom module, you are able to choose which directory suits you best. As opposite to the examples above, on the example below, the logic is written directly on the module main folder.

// modules/<ModuleName>/views/view.edit.php

require_once 'include/MVC/View/views/view.edit.php';

class <ModuleName>ViewEdit extends ViewEdit
{
    public function display()
    {
        $this->_processDuplicate();
        parent::display();
    }

    /**
     * How bean will act on edit view when it's being duplicated.
     */
    protected function _processDuplicate()
    {
        if ($this->ev->isDuplicate) {
            $this->bean-><FieldName> = '';
        }
    }
}

Thanks to Jeff Bickart of Nepo Systems and Matthew Poer of Profiling Solutions for pointing the “truly” Custom views feature out.

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.

Below there’s a list of notes, also available in the PHP documentation, that everyone should keep in mind before using this function:

If the number of the year is specified in a two digit format, the values between 00-69 are mapped to 2000-2069 and 70-99 to 1970-1999. See the notes below for possible differences on 32bit systems (possible dates might end on 2038-01-19 03:14:07).

The valid range of a timestamp is typically from Fri, 13 Dec 1901 20:45:54 UTC to Tue, 19 Jan 2038 03:14:07 UTC. (These are the dates that correspond to the minimum and maximum values for a 32-bit signed integer.) Additionally, not all platforms support negative timestamps, therefore your date range may be limited to no earlier than the Unix epoch. This means that e.g. dates prior to Jan 1, 1970 will not work on Windows, some Linux distributions, and a few other operating systems. PHP 5.1.0 and newer versions overcome this limitation though. For 64-bit versions of PHP, the valid range of a timestamp is effectively infinite, as 64 bits can represent approximately 293 billion years in either direction.

Dates in the m/d/y or d-m-y formats are disambiguated by looking at the separator between the various components: if the separator is a slash (/), then the American m/d/y is assumed; whereas if the separator is a dash (-) or a dot (.), then the European d-m-y format is assumed. To avoid potential ambiguity, it’s best to use ISO 8601 (YYYY-MM-DD) dates or DateTime::createFromFormat() when possible.

Using this function for mathematical operations is not advisable. It is better to use DateTime::add() and DateTime::sub() in PHP 5.3 and later, or DateTime::modify() in PHP 5.2.

Returns a timestamp on success, FALSE otherwise. Previous to PHP 5.1.0, this function would return -1 on failure.

]]> http://blog.joaomorais.com/sugarcrm-code-sprint-munchen-2011/feed/ 0