gcalendar-api-shutdown

I published at the beginning of 2007 the first GCalendar version on the JED, since that time GCalendar has used the Google calendar API v1. It was working well in all this years, but it didn't meet the requirements of modern architecture nowadays and that's why Google decided to build a new API from ground up (v3). It is more secure (OAuth authentication) faster (JSON protocol) and more feature rich (event colors, enc more....). Since the beginning of DPCalendar we us the Google calendar API v3 in our Professional Google Plugin.

As we announced in April this year (2014), Google will shut down their calendar API which GCalendar used since years on the 17. November 2014. We do offer a migration path for GCalendar users to use their existing GCalendar installation with the FREE package of DPCalendar on their Joomla 2.5 or 3.x web site. Yesterday was the day, Google shut down their Google calendar API v1 and v2. Since Sunday we are seeing an increase in traffic and downloads of DPCalendar. Looks like people started to do the migration. Additionally we got GREAT feedback about the evolvement of GCalendar into DPCalendar.

We have big plans for 2015 with DPCalendar and brand new responsive Joomla extensions. More information will be published at the beginning of 2015. We hope that you will have a great time with DPCalendar as you had with GCalendar! Let's move on to new spheres....

against-bc

In my previous post, I’ve discussed what it means for software to be backward-compatible. Software manufacturers usually come down firmly on this issue one way or the other. An example of a software company that traditionally strives to maintain backward compatibility almost to the point of insanity is Microsoft. Apple (arguably a hardware company), on the other hand, strives to break backward compatibility where it deems it necessary. Of course, most software companies eventually do decide to break backward compatibility; it’s just a question of when. And no software company deliberately makes its every major release incompatible with its previous version (for instance, while Joomla! doesn’t guarantee backward compatibility between major releases, it doesn’t guarantee incompatibility either).

So what would make even a company like Microsoft, much less the Joomla core developers (who, let’s be honest, have less to lose) decide to throw away backward compatibility? What reasons could there be? Here are a few issues that may be factored in when deciding whether to maintain or break compatibility with previous versions of the software in question.

Increased complexity and costs

Backward compatibility can be very hard to maintain. In the case of Microsoft Windows, for instance, many of the smaller developers (and some of the larger ones!) have grown used to poking around its undocumented (internal) functions and data structures in ways that worked for one particular version – but then subsequently had to be maintained or emulated in all subsequent versions of Windows to come. The Sega MegaDrive (Genesis in the USA) could run Sega Master System (its predecessor) games… by including the main Master System processor as a co-processor.

At some point, the overhead associated with backward compatibility outweighs the benefits of maintaining it, and that is when the decision to break it should be taken. For an entrenched OS like Windows with millions if not billons of installs, that may take years or even decades. For something agile like Joomla, that point comes around much quicker.

Security concerns

In the earlier years of PC development, every application could (and often did) consider the entire PC (and by extension, all of DOS, and later, Windows) as its sandbox, and freely manipulated it as it saw fit. Even when Windows NT became the mainstream OS, developers remained quite happy to write applications in such a way as to require Administrator privileges (the Windows equivalent of UNIX-like systems’ root access). Today, such untrammelled freedom is unthinkable, given the massive security breach it would represent. Or at least, that’s how it should be. In practice, given the need to maintain backward compatibility with such applications, workarounds have to be put in place in order to fool them into thinking they could still do things in the same bad old ways. As it turns out, security is now a more important issue in everyone’s eyes, so sacrificing backward compatibility is easier when explained in those terms.

Stifled Innovation

When creating a new version of its software, Microsoft’s primary goal is not to create something innovative and groundbreaking; instead, it is to firstly ensure that it will do no harm to existing systems running the old version(s), and then add new features. For Apple, innovation and usability and delighting the customer comes first; if the price is breaking backward compatibility, it’s not even an agenda item for them to discuss – they just go ahead and do it. However, if the choice was to innovate or die, even Microsoft will throw backward compatibility to the back burner.

bc-part1In this new series of blog posts, I thought I should start off with something that seems as far away from Joomla! as possible, and discuss how the past affects the future. A funny apocryphal story relates the reason why the size of the Space Shuttle’s rocket boosters depended on the width of a horse’s arse (the boosters were limited by the size of the railway tunnels they travelled through from the factory to the launch site, the tunnels were limited by the size of the railway gauge, the railway gauge was chosen by British railway pioneers based on the size of ancient Roman roads, which were based on the size of Roman chariots, which were based on the size of the rear ends of the two warhorses that pulled them).

While the truth is somewhat more complex than the story makes it out to be (go ahead and read it at the link above), it does neatly encapsulate the software engineering principle which we call ‘backward compatibility’. There are many arguments for why this is an important part of software engineering, and equally, there are similar arguments for why backward compatibility should be jettisoned whenever and wherever possible. Joomla, for what it’s worth, is guaranteed to be backward-compatible with all minor (point) releases within a single major release.

Backward compatibility in practice

A good working definition of software that is backward-compatible is if you can perform an in-place upgrade of a previous version, and the software will continue to work (perfectly) with the existing scripts, add-ins, macros, files and settings already in use by the earlier version. On a larger scale, it can be said that backward compatibility is what Service Oriented Architecture (SOA) is intended to achieve, in that any modular component in an SOA system can be changed without impacting any other component. In a more narrow sense, software can be said to be backward compatible if it’s compliant with (and fully implements) the older version’s Application Programming Interface (API). It is in this latter sense that Joomla can be said to be backward compatible within any major release – it will not break API compatibility.

Nor is software the only part of IT that manifests backward compatibility. Hardware components are often backward compatible as well. Many Blu-Ray players will also play DVDs and CDs. By design, USB3 slots will happily accept USB2 and USB1.1 devices and work with them, while USB3 devices will happily plug into – and work in – USB2 and USB1.1 slots, also by design. The latest Intel Core i7 6-core 64-bit microprocessor still starts up in Real Mode (and therefore will run MS-DOS 5.0 or even PC-DOS 1.1 quite happily, albeit with some things to bear in mind). Given that the original 8086 microprocessor was released 36 years ago, that is quite a lot of backward compatibility.

But what are the advantages and/or disadvantages (if any) of backward compatibility, and are there any ‘gotcha’s to supporting backward compatibility? That question is the focus of the next two posts in this series. The fourth post will then focus on how Joomla handles the issue of backward compatibility.

dpcalendar-apiIn a previous blog post, we discussed the increasing relevance of Application Programming Interfaces (APIs) in Web programming, and the reliance of many applications (both traditional as well as Web) on various APIs. We also pointed out that our flagship extension, DPCalendar, allows for the use (and integration) of many different calendars through Joomla extensions. This blog post breaks down the details of how you can integrate your own calendaring system(s) into DPCalendar.

Specifically, DPCalendar supports the integration of various calendar APIs by implementing an API to which Joomla plugins (a subset of Joomla extensions) can be written. In Joomla, a plugin is an extension that is executed when a particular action (event) is taken (triggered). In the case of DPCalendar, loading the calendar view, for example, will signal an event (or possibly a series of events), which will cause plugins to execute. The act of creating, deleting, viewing or saving individual calendar items also signal events, which your external calendar plugins should respond to appropriately.

The DPCalendar API

The list of events which DPCalendar recognises, the parameters they take, and the input they expect (the return values from your plugin) form the basis of the DPCalendar API. In addition, as part of the installation process, we also include the DPCalendarPlugin class, which is a collection of functions that allow you to work with DPCalendar more easily – it, too, can be considered part of the API. And of course, the plugin also has to work with the Joomla API, as well as the API of whichever calendar system being supported by the plugin.

As with all APIs, neither DPCalendar, nor the external calendar plugin with which it is communicating, has to know how data is manipulated internally or how calendaring functions are implemented by the other side; merely that both sides are following the API standards. DPCalendar happens to use the industry-standard iCalendar format to import and export calendar data, so that’s what your plugin should support when working with DPCalendar.

Write Your Own Plugin!

Digital Peak has written a number of plugins for popular calendaring systems, such as Microsoft’s Outlook/Exchange, Google Calendar, Apple’s Calendar, Facebook, CalDAV, and so on. There’s nothing stopping you from writing your own plugin (for instance, to support the Cozi family calendar system). But first, you have to complete the following checklist:

  1. Understand how Joomla extensions (especially plugins) work, and how to create them. The Joomla Documentation website has a section on how to create a plugin for Joomla.

  2. Understand the DPCalendar API. The documentation section of our website has a page dedicated to DPCalendar developers, which explains in detail the various Events that your plugin should respond to, as well as an example plugin to give you an idea of how to write your own (also available on GitHub).

  3. Understand your external calendaring system’s API (if any). Knowing how the external APIs work is key to making your plugin – if you can’t interface with the external calendar, obviously your plugin will be useless.

Another example is our popular attachment extensions which allows with three lines of code to integrate drag and drop/copy paste attachment support for your own extension. To do that you have to write a Joomla plugin as well:

<?php
/**
 * @package    DPAttachments
 * @author     Digital Peak http://www.digital-peak.com
 * @copyright  Copyright (C) 2012 - 2014 Digital Peak. All rights reserved.
 * @license    http://www.gnu.org/licenses/gpl.html GNU/GPL
 */
defined('_JEXEC') or die();

JLoader::import('components.com_dpattachments.libraries.dpattachments.core', JPATH_ADMINISTRATOR);

// If the component is not installed we fail here and no error is thrown
if (! class_exists('DPAttachmentsCore'))
{
	return;
}

class PlgContentDpattachments extends JPlugin
{

	public function onContentAfterDisplay ($context, $item, $params)
	{
		if (! isset($item->id))
		{
			return '';
		}

		$catIds = $this->params->get('cat-ids');
		if (isset($item->catid) && ! empty($catIds) && ! in_array($item->catid, $catIds))
		{
			return '';
		}

		$options = new JRegistry();
		$options->set('render.columns', $this->params->get('column_count', 2));
		return DPAttachmentsCore::render($context, (int) $item->id, $options);
	}

	public function onContentAfterDelete ($context, $item)
	{
		return DPAttachmentsCore::delete($context, (int) $item->id);
	}
}

 

pro-templateThe major decision you have to make before launching a Joomla website is how the design of the web site should be. Joomla's template framework allows you to have one neat design across the whole site. Creating such a template is not so easy, especially if you don't have PHP skills. That's why it sounds reasonable to use professional Joomla Templates from trusted template companies like TemplateMonster. This company has been offering Joomla templates since 2007.

Now, let's try to understand why more and more people show interest in using professional Joomla templates instead of making their own or downloading free ones.

What are the Advantages of Using Joomla Templates?

Price

You may like it or not, but a Joomla Template is definitely cheaper than ordering a custom one. And even if you will have to hire a web designer to edit the template for you, it's still not as expensive as if you would have to pay for a custom one.

Multiple Design Options

There are thousands of Joomla templates on the net, both free and premium ones, so you can always find the design to your liking. But please do not only pay attention to the layout of the template, but also its options to adapt to your site. Especially how it handles visitors which browse your site from a tablet or smartphone.

Saving Time and Efforts

With a Joomla template you save a lot of time because you don't need to actually design a website. You should simply replace the default texts and images with your own ones and you're ready to go.

By the way, this feature makes Joomla templates quite popular with web designers who specialize in building Joomla websites. After all, it's much faster to edit a template and turn it into an original website than build a template from scratch.

Free Customer Support

The most trusted template companies provide free support for their customers. For example, TemplateMonster can be reached in a number of ways: by phone, live chat or you can submit a ticket by selecting the appropriate department. This ensures that all your questions will be answered promptly.

Additional Bonuses

It's quite often that Joomla templates come with extra bonuses. For example you also get stock photos included into the template. They provide also a complete Joomla installer to set up their demo site on your own Joomla server.

Works with 3rd party extension

If you use a professional Joomla template than you can be sure that they fit with the big extension companies like Digital Peak. For us it is important that our extensions do work smoothly together with templates from the major template companies like Templatemonster. For example DPCalendar fits perfectly into the design of Templatemonster latest template "Ecofriendly Industrial Services Joomla Template".

 

Of course, it's your choice how to build your Joomla website, but we hope today's article will give you a quick introduction to help you make the right decision.

And if you want to get a professional Joomla Template and you want to get it at a special price, please go to TemplateMonster.com and save 30% with code 'Digital-Peak'.

Please note: the discount code will be only valid for a week, and will expire on Thursday, September 4.

Cookies make it easier for us to provide you with our services. With the usage of our services you permit us to use cookies.