Archive for January, 2008
Last week I was at the Dutch Joomla BootCamp, which was organised by our friends from Jira. Johan gave one of his famous unstoppable sessions about the Joomla framework and the MVC model. Jisse talked about templates, and brought along the very first copy of his new book on templates (a rather thorough one I must add, it goes beyond any book on templates I’ve seen — too bad it’s in Dutch only for now).
Finally, I gave a presentation about migrating a Joomla! 1.0 site to Joomla! 1.5, and took the opportunity to announce the migrator plugins for DOCman.
Com_migrator is a component written by J! Core developer Sam Moffat. The latest version 1.0RC6 was released this week. You install it on your old J!1.0 site (or even Mambo!) and it will take a snapshot of your database. During the installation of J!1.5, you can upload the snapshot (an SQL file). The new site will now contain the contents of the old site. A great feature of com_migrator is the ability to load additional plugins for 3PD extensions, such as DOCman. These plugins expand the snapshot with the data from the extension.
With a little knowledge of phpMyAdmin, you can also use the migrator to copy data from a DOCman installation on a site to an existing J!1.5 installation.
You can download the DOCman migrator plugins at Joomlacode.org, where you can also find the com_migrator component. Extract the plugins’ zip file and read the included README.php file for detailed instructions. We’ve also opened a new forum category where you can discuss DOCman migration.
Good luck migrating!
When you’re defining one or more tables to use in your component, it’s always a good idea to put some thought in how you’ll name them. First of all, we have of course the #__ prefix, which Joomla! replaces with the user defined prefix. The default is jos_, which stands for ‘Joomla! Open Source’, a leftover from the Mambo days.
Next, we want to prevent name collisions. Component names in Joomla! are unique, so using that for the first part of your table names will fix that: #__mycomponent_. Don’t use #__com_mycomponent_, that’s unnecessary luggage.
Let’s take a classic example: a component that manages a book collection, called com_library. The table name should reflect the contents of the table. This is always plural: you use a table to store multiple items.
Bad: #__library_book
Good: #__library_books
Even if your component uses only one table, you shouldn’t use #__mycomponent. You might need more tables later, eg #__library_authors and #__library_publishers.
Finally, you always need to define a primary key. Most people simply use id for this, or something like bId for the books table, aId for the authors etc. A better idea is to use the table name, in singular, followed by id.
#__library_books -> library_book_id
#__library_authors -> library_author_id
There are some very important advantages to this naming strategy. It’s easier for you or other people reading your code, what tables belong to what component, and what’s in them. Relations between tables are now very clear as well. #__library_books for example has two additional fields called libray_author_id and library_publisher_id, which of course link an author and a publisher to the book.
But more importantly, it’s easy to write code now that can detect those relations automatically. As your com_library becomes smarter, you could add data mapping functionality that can understand the relations between tables, without the need to hardcode them.
Finally, in most situations, you’ll want to use auto_increment for primary keys. As we’re all moving to PHP5.2 and along with that, hopefully MySQL 4.1 or 5, we can make use of new feature: the SERIAL keyword. SERIAL is just an alias BIGINT UNSIGNED NOT NULL AUTO_INCREMENT UNIQUE. This allows your primary keys to be as big as possible (and it’s easier to remember as well).
In Joomla!, we’re still stuck with backwards compatibility, but hopefully, these coding conventions will be picked up in a future version. Component developers can already start using them. The possibilities are endless.
Anyone who’s been around in the Joomlasphere for the last couple of days, could feel something was buzzing… And what better time for an announcement like this than right after the DocCamp weekend? So with no further ado, ladies and gentleman, may I present to you…
Joomla! 1.5 the greatest thing since someone said ‘Hey, what if we connect these two computers to each other?’
Joomla! was born on August 17, 2005, so it’s now 2.4 years old… in human years. Similar to dog years, it is generally accepted that for open source projects, the equivalent of one human year is 8.75 years.
2.4 x 8.75 = 21
So today is Joomla!’s 21st birthday! Our baby’s grown up and is now officially an adult!
For you, the user, this is just the beginning. You can now install Joomla! 1.5 on your sites or migrate your old sites. Developers who haven’t done so already, now have an extra incentive to make sure their components are compatible with 1.5, either using legacy mode or as native extensions. And everyone in the community is invited to write documentation, help spot leftover bugs, and spread the love.
I’m working on further improving DOCman, so I’m going to deliver a final release candidate (RC2) soon, followed by DOCman 1.4 Stable.
First on the list however is a migrator plugin, that will help you to easily move your existing DOCman installation to Joomla! 1.5. I’m giving a talk about the migration process next Thursday, with some pointers on how to easily migrate all existing extensions, so make sure to drop by if you’re interested. Keep an eye on this blog, we’ll announce more events like these soon.
We are also working on a very ‘secret project’. A J!1.5 extension of course, one that will multiply your website’s audience in the blink of an eye. Excited? So are we.
Now stop reading blogs and go play with Joomla!
Can anybody tell me how Joomla! 1.5 will be able to give just raw output so I can generate XML or JSON for my dynamic pages?
This is a common question for developers that are diving a bit deeper into Joomla! 1.5 and want to integrate AJAX functionality into their extensions. They quickly find that index.php always generates code within the XHTML-template and thats not what they need. Instead they want to generate XML for evaluating in JavaScript without any XHTML wrapped around it. Sounds familiar ? Well, here is how you can do this with Joomla! 1.5.
Before we dive into the actual solution we need to talk a bit about JDocument first. JDocument is a completely new framework API that allows developers to render different types of output. JDocument is a very flexible library that handles the loading and rendering of your templates and is made up out of formats and renderers.
A format is the type of document that gets created, for 1.5 the supported formats are html (default), pdf, feed, error and raw.
A renderer is responsible for creating the actual output. It can be triggered by a function call or by a placeholder. For example, the html format has renderers for a module, modules, component, head and message. These renderers are triggered by the
