Category Archives: Software Development

Posts about software development. Generally I use Java, PHP, and Python for development but occasionally I delve into other things as well.

Dataface 0.5.2 released

I have added a Javascript calendar widget to Dataface for editing DATE and DATETIME fields. I have also fixed some issues involved with running Dataface on a shared host in safe mode. These changes are part of version 0.5.2. Check out the latest in Dataface at http://fas.sfu.ca/dataface.

On a side note, I have been very happy with the response for Dataface since releasing it to the public on February 28th. I have received a number of comments from developers around the world saying that they really like the software. It is exciting to be able to contribute something useful to the developer community and I hope that I can continue to contribute. I would love to turn Dataface into a household name, but for now I’ll setting for the slow and steady increase in awareness that seems to be happening right now.

Also, I have to express my amazement at the power of freshmeat.net. Every time I release a new version and post it on freshmeat.net, I get an influx of 300 hits or so, and a large amount of downloads. In addition, it seems to pop up all over the internet on other websites that show freshmeat’s new releases. Freshmeat is an awsome solution for open-source software promotion.

To Plone or not to Plone?

Simple Answer: Don’t go there.

Plone, despite its flashy coat of paint, is still a development work in progress. Upgrades from version to version have no guarantee except that they will be problematic. For now, and for many years to come, content management systems based on a relational database are the way to go.

More details later, but save yourself the hassle, unless your a python hobbyist that likes to mess around with code a lot.

Wash my hands of Plone

This is a notice to any who will listen. I have given Plone ample opportunity to woo me. It is almost there but it suffers from over complexity with version compatibility.

Plone is the type of system that you need to work with every day, or you will find your self getting lost in the complexity. Creating Plone Products with ArchGenXML is one example. 4 months ago I had a system all set up to work with ArchGenXML to develop custom content types. Unfortunately, 4 months later, I find myself back on a 4 day learning curve trying to figure out all of the compatibility issues that have been introduced in the mean time. Making sure that all of the Archetypes libraries have the same version is also a headache.

It is my belief that any attempt to make something more complicated than it need be, should be met with harsh criticism and should be avoided like the plague. Plone falls into this cateogory. And for all of its triumphs (of which there are many), this one vice will prove to be its downfall, unless those in the Plone development community find a way to integrate simplicity and maintainability.

Content management systems (which is what Plone touts itself to be), must offer peace of mind in storing the content in the system. The users of the system must believe that their content is safe, and retrievable when the time comes. They shouldn’t have to worry about mucking with python code and api version conflicts every time an upgrade occurs, to make sure that their data is not destroyed. Unfortunately, development with Archetypes does not yet offer this peace of mind.

I have come to the conclusion, that, for now, Relational Databases, are still the best solution for any kind of data-centric application. They offer multiple, simple retrieval methods, and full independence from api version changes in the CMS of choice.

Oh well.. enough of a rant for now.

Smarty Layered Skinning

The default install of smarty is great but simple. I wanted to be able to have multiple template directories so that Smarty would search all of the directories for the requested template, choosing the first one found to be displayed (similar to a UNIX-style PATH environment variable).

This functionality is built-in to smarty (simply specify the template_dir attribute as an array), but only a single compile directory is specifiable, so compiled versions of templates in different directories will conflict. I created a SkinTool as a subclass of smarty to provide skinning. Its code is as follows:

class SkinTool extends Smarty{

         /**
          * Array of registered skins..
          */
	var $skins = array();
	
	/**
           * Overrides smarty method.  This will place compiled version of the template
           * in a subfolder of the compile_dir named after the skin where the template
           * resides.  If this subfolder does not exist, it is created.
           *
           * @param string $resource_name
           * @return string results of {@link _get_auto_filename()}
           */
         function _get_compile_path($resource_name)
         {
    	    $params = array('resource_name'=>$resource_name, 'resource_base_path' => $this->template_dir);
    	    $name = $this->_parse_resource_name($params);
    	    $template_dir = dirname($params['resource_name']);
    	    $skin = $this->skins[$template_dir];
    	    if ( strlen($skin) > 0 and preg_match('/^[0-9a-zA-Z_]+$/', $skin) ){
    		$compile_dir = $this->compile_dir.'/'.$skin;
    		if ( !file_exists($compile_dir) ){
    			mkdir($compile_dir);
    		}
    		if ( !file_exists($compile_dir) ){
    			trigger_error("Failed to create compile directory '$compile_dir'", E_USER_ERROR);
    		}
    	    } else {
    		$compile_dir = $this->compile_dir;
    	    }
             return $this->_get_auto_filename($compile_dir, $resource_name,
                                         $this->_compile_id) . '.php';
        }

	
	/**
	 * Registers a skin to be used as the default skin.  This skin is added to 
	 * the top of the stack so it has the highest priority.  If a template is
	 * requested and this skin does not contain that template, then the SkinTool
	 * will check the next skin in the stack. And so on...
	 *
          * @param $name The name of the skin
	 * @param $template_dir The directory to the templates for this skin.
	 */
	function register_skin( $name, $template_dir){
		if ( !is_array($this->template_dir) ){
			if ( strlen($this->template_dir) > 0 ){
				$this->template_dir = array($this->template_dir);
			} else {
				$this->template_dir = array();
			}
		}
		array_unshift($this->template_dir, $template_dir);
		$this->skins[$template_dir] = $name;
	
	}

Jakarta Commons FTP Client Deadlock problems

I have been experimenting with Java FTP components in my effort to create a JFileChooser component that will work over FTP. Common concensus seems to be that the best FTP component is the Jakarta Commons FTPClient class. It seems to have all of the necessary functionality, however seems to have multithreading issues. The component continually deadlocks, and I have narrowed it down to the FTPClient class. I found a post at http://www.kaffe.org/pipermail/kaffe/2005-August/103033.html that also talks about deadlocking in the FTPClient. One suggested solution is to disable the separate reader thread by calling setReaderThread(false). This helps me get a little further to the point where it usually works, but nonetheless deadlocking still occurs.

I will keep on searching for another FTP component but in the mean time I have successfully adapted JFileChooser to use SFTP (Secure FTP) using the SSH Tools libraries.

References

Hessian Web Services

I just ran across a great little library for web services, called Hessian. It is a binary web service (ie not xml) so its messages are much more compact and easier to transfer. In addition, the client and server libraries don’t require nearly as large a framework. It looks really easy and there are libraries to support Java, Python, and PHP — and maybe a few others that slipped my mind.

http://hessianphp.sourceforge.net/quickstart.html