Was trying to figure out the logging architecture of the NCC application when I found something very useful in the debugging of Joomla applications. There are often times when you would very much like to look at all the SQL statements which have been executed in the page request. It can be easily done in Joomla by:
Step 1: Enabling the debug plugin.
Step 2: Activating it in Global Configuration.
Results: Shown at the end of the page.
27 Mar, 2009
Posted by: Mr Otter In: Joomla
I was assigned a task by Mr. Otter, recently. It was basically to do a review on available Gallery Components for the Joomla CMS. I will do a quick review for the component Morfeoshow image gallery along with screen shots to give you an insight over it. I have used graphics to expose the functionality and usability for component in review. So let’s start here.
The Morfeoshow Gallery
I hope for you all know how to install a component in Joomla. If not than get yourself some help from Google. Alright, after installing the Morfeoshow Gallery, let’s go straight to the component back end Panel, inside Joomla. It gives us three main options,
Quite often, in CMS driven websites, the thumbnail images to be shown on the listing page is very hard to be controlled to be the same size, especially for clients who do not have image processing knowledge. I discovered a easy workout which can automatically crop the images and add a nice border.
Well, just chanced on a really, really hot backend administration panel. Major revamp. Loved the activity logs, mac like toolbar at the bottom, easy templating mechanism. etc.
Check it out!
Have been working on a serious of frameworks by now. Most mature frameworks have their own validation framework. This ensures that field validation are handled in a standard way. Hmmm, does Joomla have something similar?
Let’s Investigate.
Step 1: I tried to submit an article via the front end. Was confronted with a javascript alert box that says:
Article must have a Title
Step 2: Looked into the backend.. and I see semblance of validation logic at the javascript:
function submitbutton(pressbutton)
Step3: Investigate code at:
http://localhost/joomla/index.php?option=com_content&view=article&layout=form&Itemid=4&lang=en
Well, looking at the url, we can conclude that we will need to look into:
com_content/views/article/tmpl/form.php
Alamak… no luck. The validation logic is all hard coded. Looks like the validation framework is just not robust enough….
Step4: Google online
Fantastic! Seems like we can do the validation just by setting some classes to the form elevements!
http://docs.joomla.org/Form_validation
i.e. for both required and email validation, use:
<input type="text" name="email" size="30" class="required validate-email"/>
For a moderately sophisticated web application, you will generally have some tasks which you need to be run on a regular basis. In Java you have the quartz framework. In .NET, I hear they rely on the Windows Scheduler to schedule regular jobs. How about Linux, PHP? I am aware that we can probably do a wget in the crontab, but.. is there a better way? Edward did mention something about drupal having some kind of cron implementation… so just wanted to dig a little deeper into that…
Well, hmmm.. turns out that drupal way… is basically just leveraging on the crontab. Nothing new. Relying totally on the OS scheduling mechanism. :P
But found something quite interesting though… they call it a Poor Man’s Implementation of Cron. Basically, it is treating each page view as a possible trigger point for scheduled jobs, since PHP codes are executed on each browser request. Apparently both drupal and joomla has their own implementation.. but of course, it will not work for a more serious project like ours…
http://extensions.joomla.org/extensions/847/details
http://drupal.org/project/poormanscron
I was looking at the JHTML framework in Joomla. Basically JHTML does a lot of html formatting which is a common functionality of all web applications.
Fired up my PhpED to take a look at the include paths of JHTML by calling
JHTML::addIncludePath()
It seems that JHTML by default has only one include path at:
libraries/joomla/html/html
Well, there are a lot of useful infrastructure codes in Joomla. One of it has to do with email cloaking. Basically joomla has a way or writing out the entire email address via javascript… so that spiders (which are generally just scraping the HTML with no javascript interpretation will not be able to read the emails…)
It can all be done in one line… by leveraging on Joomla’s JHTML framework…
echo JHTML::_("email.cloak", "james@xtremax.com");
The entry point of each component is standard:
[COMPONENT_NAME].php
and for backend modules, it is also possible to use
admin.[COMPONENT_NAME].php
to be the entry point.
The purpose of the entry point is very simple, initiate the correct controller and execute the task. See below for a very typical entry point file:
Another important function for the entry point file is to register any path for any JTable, JModel that are not in standard location, or not in standard file names, for example, when you want to have JTables to be places in the front end component:
JTable::addIncludePath(JPATH_COMPONENT.DS.’tables’);
This “addIncludePath” method is available for both JTable and JModel, but please do not mix up.
For JModel, alternatively, the search path can be added by calling JController::addModelPath method, but eventually, it is still done by calling the JModel::addIncludePath.
For backend module, it is advisable to follow the Joomla default UI configuration, in this way, users are presented with a consistent UI experience, prevent mistakes and reduce training complexity.
One of the key features of Joomla backend UI is its Toolbar:
To program this, actually it is quite easy, especially if you are using the common toolbar tasks like:
We do not even need to specify the icon to be used. The complete list of methods available are listed below:
We can see for many of the methods, there are 2 different version: one with ‘X’ and one without ‘X’. What is the difference?
For the versions with an “X” in the end, the official comment says something like this:
Extended version of *** calling hideMainMenu() before submitbutton().
Hiding the menu prevents the page from being navigate away easily in doing the task, and gives people a “transaction” kind of feeling.
What happen is, all the buttons represent a “task” in your controller, upon clicked, the task will be “executed” on the specific controller.
How should we use the JToolBarHelper class? TO BE CONTINUED.
Well, Tweety asked me a question. An administrator component like Media had many layouts. How can we know which layout just based on the url?
I looked at the url.. and no.. there is no way. Internally, there are some codes which have actually set the layout, but it is not based on the core joomla framework. By right, the url should have been more informative like:
It will point to the same codes, but this will be in compliant to the Joomla core framework without relying on strange little snippets of codes that set layouts..
To sum it all, 4 different parameters in a url will determine the automatic wiring of the different files from Joomla.
| Parameter | Description |
| controller | used to determine the controller to call in the controller folder.
this is normally coded in the component entry point file.. and cannot really be said to be part of the main framework |
| view | points to the relevant view.html.php |
| layout | points to the relevant php in tmpl. layout=default will point to default.php in tmpl, while layout=form will point to form.php in tmpl |
