harpur

Modules provide a great way to split up the development of Joomla components by encapsulating a reusable block of content on a page. The problem with the overall Joomla design is that these 'modules' cannot be used anywhere by default. You have to specify locations on the page where they are to appear and then program these positions into the overall template. So I might specify 'user1' as the name of a position. In the template I specify that all 'user1' modules are to appear here, say, at the bottom of the page. This is very web-site orientated, and does not facilitate the job of the component designer. What I want to do is put a module anywhere, and not have to use someone else's plugin to do it.

What this means is that views can be composed of recombinations of modules, which not only makes development easier, but also makes it more consistent. So the twin, facsimile, annotate and edit views will all use the same basic components (and others) that were defined for single view. Now that's cool.

In fact, that bit is easy. To place a module anywhere all you say is:

$module =& JModuleHelper::getModule( "mod_infobox" );
$document = &JFactory::getDocument();
$renderer = $document->loadRenderer('module');
echo $renderer->render($module);

Simple enough to be encapsulated in a small class and called when needed. I wrote one called 'LoadModule' and to call it I just say:

echo LoadModule::getModule("mod_infobox",$params);

Now I have added another argument, an associative array of 'params' which get passed into the module. This allows me to customise that particular rendition of the module. So for example I could have two instances of mod_infobox on the same page and they would look different and do different things. But 'params' are global things that you set in the back end of Joomla when you configure all instances of the module. I don't want that. My params get passed into mod_infobox where they are automatically available as the "$attribs" array. This is a seemingly undocumented facility which solves the problem for me.

This took me several weeks, unfortunately. Since importation of several long files into a multi-version document can take quite a few seconds, you need to give the user some indication of progress, or otherwise they might cancel and mess the whole thing up. So first I decided that the results of a import operation would be held in a temporary table, then on successful completion, would be copied to the main table of 'works'. Safe huh? So if there is an error we can take the user to an error page and if one version seemed not to belong to the set we could issue a warning and ask the user to proceed or cancel.

Indicating progress was harder. At first I tried to design a separate view that would show progress with the same files that the user had just selected in the browse view. Then it became obvious from a design point of view that I would be better off just displaying the progress somehow in browse view (where the user selects the files). The best method I came up with was to colour the file input fields, making them green if they were processed and red if not. Although you can't style a file input field much, one thing you can do on all browsers is to set its background colour, via the class attribute.

What was really hard was getting information about which files had already been merged into the MVD. The only way was to use Ajax to contact the server without refreshing the page. When the page is first loaded I launch a timed Javascript function that fires every second, that calls the Ajax routine. The returned value is the number of converted files out of the set, thus allowing me to colour the right number of file input fields. For that I needed some way to hold the number of converted fields that could be read or written by the server and read by the Ajax routine. So I first tried the Joomla session object, but the Ajax routine starts its own environment that doesn't recognise the Joomla session object. Then I tried the php $_SESSION object, but it too is recreated by Ajax. So I had to create a separate table indexed by ids to store the progress value for a particular import operation. This was more complex and that's why it took three weeks of spare time before it worked satisfactorily.

The few posts I have seen have made it clear that no one has a good idea how to do this. POST parameters will be lost after a redirect, of course. That's inconvenient because it means that views needing to display different information based on the user response, for example asking for confirmation or abort, or displaying error messages, require conditional sections, which complicates things. How much better it would be to handle these cases by redirecting to a completely separate view and passing the POSTed parameters to that! But technically this is impossible. Converting them into GET parameters and encoding them into the URL is one possibility, but this has the drawback of uglifying the URL displayed to the user, and perhaps exceeding the limit on length for these parameters. I chose instead to store the post parameters as a string in the session object. Then when I redirect to the new view, I can restore them from the session. Pretty simple.

One problem with this technique, though is that the breadcrumb trail, which reflects the menu choices you made to get to that page, will be wrong. Ideally they should reflect the hierarchy of views you needed to get where you are. That can be emended, though, by directly updating it by using the JPathway object.

XAMPP is a hack.

I tried to install a debug system for using eclipse and php together to speed up development of the mvd component. The problem is that I have to insert print statements and use other basic methods to debug the application and sometimes there seems no good way to obtain the correct information, and it wastes time. The Joomla people advise me to install XAMPP, a package of MySql, PHP and Apache and a lot of other stuff that is also available via the usual Synaptic installer in Ubuntu. Because XAMPP is a simple binary download that circumvents the package installation mechanism altogether, and doesn't provide the source code, you end up with a 32-bit application trying to access a 64 bit debugger, so wham! it doesn't work. In a nutshell XAMPP s****. In attempting to 'help' clueless users the author of XAMPP screws up in a big way. If it does anything useful then make it part of the standard installation mechanism or just forget it. Do it properly or don't do it at all.

I have upgraded from Joomla 1.5.14 to 1.5.15. The new version fixes some bugs, such as left alignment of the mvdlist in IE instead of centre alignment. Simple but annoying.

Also, now I have a real Windows machine (on which I am typing this), I have fixed some of the IE-specific quirks in the MVD component, which may not work in other versions of IE other than 8.

Import is still not finished - the last step when it actually does the import is not yet working. Also, I haven't managed to get java to work on the live server yet, but it should work.