Friday, 14 January 2011

mvd-core component complete

It's not tested yet fully but the backend component that is meant to govern how the mvd-gui works as a whole is finished. Here's a picture of it:

I've come to the conclusion that the only way to write a successful Joomla GUI is to break it up into small components and modules. Otherwise it rapidly gets too complex to handle. This way I can add new views at will, or take them away and it will all still work. Each view hangs off the mvd-core component, which only has this simple backend, and provides access to nmerge. And that's it. With components this small fixing bugs should be a breeze.

Monday, 10 January 2011

Writing an admin backend for a Joomla! component

I wanted to add an admin back-end to my mvd-gui component. There are few instructions about how to do this and all of them are messy. Basically you are supposed to define a model-view-controller interface as in the site part of the component. But in the Joomla application they have shortcuts that only require a few lines of code, so I wanted to do it that way. Also it would look more consistent and reformat properly when the user changed the admin template.

So I took the massemail component's admin interface, which was quite simple, and deconstructed it. Customising the icons that appear in the toolbar was easy: just modify the calls to JToolBarHelper in toolbar.massemail.html.php. (You should rename this file as something else). I then got stuck on changing the icon that is displayed in the toolbar. Basically you call JToolBarHelper::title with 2 arguments: the first is the text you want displayed. The 2nd argument is supposed to be an image, but in reality it has to be one of the images in the images directory of the admin template. Since I can't add to that without making my changes non-portable I decided just to use the generic icon. It looks OK:

Or, in code-form:

class TOOLBAR_mvdcore
{
 /**
 * Draws the menu for a New Contact
 */
 function _DEFAULT() {
  JToolBarHelper::title( 'mvd-core', 'generic.png' );
  JToolBarHelper::cancel();
  JToolBarHelper::save();
  JToolBarHelper::help( 'screen.users.massmail' );
 }

Next step is to supply a help file. That's the last line in the code above. Then I still have to provide code for the save button and reformat the HTML form so that it displays my stuff. I'll save that for tomorrow's post.

Sunday, 2 January 2011

Debugging php in Netbeans on Ubuntu

I used to be an avid fan of Eclipse. But setting it up to debug php drove me to try Netbeans yet again. And no it is not much easier in that IDE either. What they don't seem to understand is that all the programmer really wants is to do is install the package and it just works. So here are the problems I had getting the debugger to work and how I overcame them.

  1. First, you have to install the xdebug package and apache2 with php etc. This is straightforward using Synaptic or apt-get etc.
  2. Next you can just run a php application you create in Netbeans and it will tell you to add certain lines to your php.ini file. Cool. Do that.
  3. Third, if it still does not work, and inexplicably gives the same error, the reason is probably that you haven't specified the script to debug. Right click on the project and check that the "index file" in the "run configuration" section is set to your root script.
  4. Fourth, if you created a source folder in your project, remember to set the "source folder" in the project properties under "Sources". And no, of course you can't edit it directly in the GUI, Silly, but you can in the "project.properties" file in the nbproject folder (look under the "files" tab on the left of the IDE). Now that's what I call a useful feature.
  5. If it debugs but the line-numbers are wrong, remember that the executing script is the one copied to the server. And the files visible in your debugger are the ones in the project. Cool. To keep them in sync click on "sources" in the project properties and select "Copy sources from Sources folder to another location". And remember to specify the folder on your web server. Of course you'll have to set the creator of that folder to your user name not www-data (if you're using Apache). But you knew that.
  6. So it all works but you don't see any local variables, just global ones and the current object? The problem is with xdebug. You need to upgrade it manually. There are some instructions here.

So now it all should work. Thank heaven for Linux or geeks would be extinct.

Saturday, 23 October 2010

Unexpanding entites in expat

Entities are 'expanded', that is resolved, in expat so that if you parse a file containing & it will turn into &. Expat does this automatically and there is no option to turn it off. The problem with this is that any XML file written from the parsed data will be invalid. In the documentation it says you can specify a 'default handler' which will turn off the expansion as a side-effect. However, in a SAX parser if you define a character handler it will receive the resolved entity instead:

XML_Char ch = (XML_Char) XmlPredefinedEntityName(enc,
          s + enc->minBytesPerChar,
          next - enc->minBytesPerChar);
if (ch) {
if (characterDataHandler)
    characterDataHandler(handlerArg, &ch, 1);
else if (defaultHandler)
    reportDefault(parser, enc, s, next);
break;
And even the default handler will receive the resolved ampersand, not the literal entity reference. Ho hum. But the key is the line characterDataHandler(handlerArg, &ch, 1);. Since all ampersands go through the character handler as actual ampersands, you can just re-expand them there and the problem is solved, e.g.
static void XMLCALL charhndl( void *userData, const XML_Char *s,
    int len)
{
    size_t  n;
    if ( len == 1 && s[0] == '&' )
    {
        n = fwrite( "&", 1, 5,text_dest );
        current_text_offset += 5;
    }
    else
    {
        n = fwrite( s, 1, (size_t)len, text_dest );
        current_text_offset += len;
        if ( n != len )
        {
            printf( "write error on text file" );
            exit( 0 );
        }
    }
}

Sunday, 15 November 2009

Progress with the rewrite

So it's decided. Digital variants, the Harpur Archive and perhaps part of Hrit (can't say any more) will be done in Joomla! with a C++ version of nmerge with several improvements:

  1. Merging using the list format, not the explicit graph. So no more wasteful conversion to/from the graph.
  2. Support for 'plug-in' alignment modules for corpus linguistics texts, multi-lingual texts, xml-aware alignment. Also a user-accessible API for building their own alignment modules in C++.
  3. Use of a full suffix-tree for the general alignment algorithm. In this way the performance will be linear.

The GUI will become a Joomla! module, extension or whatever that will take over all the current functionality of the wiki and add a manuscript view and a tree-view, which will show the genealogical tree of the work. Maybe each of these views could be designed as modules also, so the site designer can add his/her own. I want this to be as flexible as possible.

Of course, the advantage of using Joomla! is that we leverage all its existing GUI for site management and page editing etc. So we get out of the box something that humanists can already use to build their own website.

But the keyword is: components, components, components! Like Steve Ballmer with his 'Developers! developers! developers!' Let the designer be free to customise the system.

Rahmel's book on Joomla! is fairly comprehensive, but a bit difficult to read. I have nearly finished working my way through Chapter 3. My intention is to go through it all as fast as possible and type in and test all the examples. At the end I hope that I will come out as a Joomla! guru, able to create three websites at the stroke of a key. If the goal of changing the face of digital humanities is ambitious I think it is also achievable given the tools available today.

Sunday, 1 November 2009

Radical Redesign

I have decided after arguing this through with the DV people is that they want a Joomla! or php-based website so they get a nice GUI and can edit it themselves. And no Java. So I have to rewrite nmerge in C++ and develop a Joomla! plugin out of the Alpha wiki web application. This way other humanitites users can get a simple, easy to deploy, web-application without paying for expensive web-hosting.

Monday, 24 August 2009

Some Big changes are Afoot

OK, I've been quiet about this for a bit. But I had other things to do, like attending the Balisage Conference. In the meantime I've had a rethink. I have realised how poorly written Jetspeed is. To create your own Jetspeed website you have to modify an existing website. Yuck. It should just be a product that you ADD things to, like webapps or portlets. Drop them in and away you go. Instead there is all this tinkering with the internals of a complex progam.

So I am returning to Pluto. It's very simple a cleaner. OK, there's no so many features but I can add those. Also, I have decied to use JSPs to define the portlets. I can rewrite the servlet code I have for Alpha and fit it very nicely into Pluto. And the best thing is Pluto is tiny - just 20MB. That sure beats over 200MB for Jetspeed, and that was small.