fogbound.net




Sat, 24 Sep 2005

AJAX

— SjG @ 6:41 pm

So, while the core development of CMS Made Simple is undergoing some interesting (and pervasive) updates as we head towards a 1.0 release, I’ve been fixing modules to work correctly under PHP 4.4 and 5.0.5. Obviously, my understanding of references was weak, and I’m paying the price now. Damn, I wrote a lot of wrong code.

But now I’m playing with making an alternate Admin interface for CMS Made Simple using some of the fine AJAX and Javascript libraries out there.

I’m using xajax to marshall up objects and submit them nicely to PHP, and I’m using the script.aculo.us Web 2.0 and its underlying Prototype library for User Interface and special effects.

Some of it’s silly, like making the login box shake if you incorrectly enter your username or password (imitating Mac OS X login). But some of it is really slick — adding users to groups is now as simple as dragging’n’dropping items between lists. It could use a way of multi-selecting that worked with dragging, but an “add all” and “remove all” button mitigate that somewhat. Of course, the original interface will remain for non-Javascript users or people who prefer it.

I plan to do the same for assigning permissions to users. But the real challenge will be drag’n’drop content reordering. This will require a draggable tree. I haven’t yet found code to make this easy; even with all these great libraries, I have to be careful to select features that work equally well under the Evil of Internet Explorer, as well as Gecko-based browsers and Opera…


Wed, 7 Sep 2005

Build PHP 5.0.5 for Mac OS X 10.4

— SjG @ 8:39 pm

I’m trying to track down a bug in my CMS Made Simple PHP code where I did something stupid with references (a rant on the PHP pass-by-value model available upon request). So it only manifests with PHP 4.4.x or PHP 5.0.5, since that’s where they finally decided to get strict with us idiot slackers. Neither of these are available as binary packages on Mac OS 10.4.

I was dismayed, shocked, stunned, dazed, and confused to learn that PHP was no longer a package for Fink. Dammit! Now I have to figure it out for myself. Crap.

With the help of a variety of pages out there on the web (especially this one), I was able to do it. Here’s how:

Install Fink, if you haven’t already. I use the “unstable” packages. Read the FAQ, and muck around with it for a while until you feel ready to proceed.

Install a wholehellovalotta packages using Fink:

  • libjpeg
  • libtiff
  • libpng
  • libxml2

I also installed the Fink version of MySQL server 4.1, client, and a bunch of shared libraries.

Next, gotta build ZLib:
curl -O ftp://ftp.simplesystems.org/pub/libpng/png/src/zlib-1.2.3.tar.gz
cd zlib-1.2.3
./configure --prefix=/sw
make
(su if necessary)
make install

(I did my install work in /sw/src, but you could do it somewhere else if it pleases you more. Just take note of this other location when you need it later.)

Finally, we get PHP 5 .0.5 from http://us2.php.net/get/php-5.0.5.tar.gz/from/a/mirror

tar xzvf php-5.0.5.tar.gz
cd php-5.0.5
./configure --with-libjpeg=/sw --with-libtiff=/sw --with-libpng=/sw \
--with-gd --with-mysql=/sw --with-xml --with-apxs --with-exif \
--with-jpeg-dir=/sw --enable-exif --with-png-dir=/sw --with-zlib-dir=/sw \
--enable-embedded-mysqli
make
(su if necessary)
make install

Now, I already had a version of PHP installed before this, provided by Marc Liyanage’s excellent binary packages available at his page, so I didn’t need to tweak my php.ini file. If you do, you’d probably do something like:

cp /sw/src/php-5.0.5/php.ini-recommended /usr/local/lib/php.ini

and then edit into submission. You can also use the more general php.ini-dist instead of php.ini-recommended. I don’t know why they provide both — probably to confuse idiots like me. You’ll also need to register the PHP Mime Type with Apache. Edit your /etc/httpd/httpd.conf file, and add either to the general area or to a specific virtual host the line:

AddType application/x-httpd-php .php

Now test it! Create a test file in your web root containing:

<php phpinfo();>

and browse on over to it. With any luck, you’ll be greeted with ahappy PHP 5.0.5 banner.
Celebrate this with red wine. Preferably good red wine. Then get back to coding. As should be obvious, I decided to document instead of code, but I didn’t skip that vital red wine step.

Enjoy!


Thu, 3 Mar 2005

Feedback Form Module, Newbie Software Engineering

— SjG @ 12:12 am

So I’ve just finished version 0.4 of a module for handling user feedback for CMS Made Simple. It allows users with administrator rights to create reasonably complex forms, with all the user interface objects that we’ve come to expect, and handle the submission of those forms in a variety of ways.

It’s been an interesting experience. Version 0.1 was your standard naive PHP implementation of an application within a framework. It was all one big script in one big file. It would do fairly simple database queries, stuff all the results into a big array, and then process array elements with big switch statements when it needed to customize output based upon UI object type.

Version 0.2 ported this basic functionality into an Object Oriented model. I found that there were a couple of complex decisions to make — should I handle the database storage and retrieval in an OO manner? And if I query a bunch of Input Objects from the database, how do I know what specific kind of object to instantiate since that data is contained in the database record? I guess the truly OO approach would be to use an OO database, or, next best approach, to have a separate table in the database for each kind of input object. But that’s not how I did it, probably to the detriment of my code (I instantiate a superclass object, then use the type details from the general object to create a new object which is the correct specific class.)

Still, this showed how a procedural approach could save a lot of database activity over an OO approach. The data model comprises forms, which contain one or more fields, which have one or more options. In the procedural approach, I denormalize the database so that fields contain the form id, and field options contain both the field id and the form id. I could then grab everything I needed for a form in three queries. With the OO model, the number of queries is proportional to the number of fields. What’s more, there’s been a massive proliferation in the number of files required. While I worry about the web server having to load and parse all that stuff each time, I should probably have more faith in the PHP engine and the OS caching. As a number of people have said to me, I’m not playing on a TRS-80 with 4k RAM anymore. But I still feel like I should be programming as if resources were seriously limited.

Similarly, when it came time (for version 0.4) to add localization of the code, it required some somewhat unpleasant contortions: each Input object needs to have access to a global collection of text strings (stored in a big hash) so they can present localized versions of messages. And I still need to go in and make sure that I’m actually handing around references rather than the copies that PHP likes to pass.

Maybe this is just the yammerings of someone who should understand software design better. Clearly, there were some bad decisions made in the code, although I could argue about how bad they really are.

Another aspect that took me by surprise was how I could test code and have it perform perfectly, while other users reported errors and bugs immediately. In this case, the main culprit was not inattentiveness (in testing, anyway), but my PHP configuration. If you allow output buffering, PHP gracefully handles output before the headers have been sent. Not so, if output buffering is disabled. So when my code would generate errors, my test configuration would blithely allow error codes to be output but then clobber that output with the expected page output. So while I thought output buffering was only involved in performance, it seems that for development, it should be disabled. That way, those bugs cannot be so easily overlooked.

Filed in:

Tue, 22 Feb 2005

Why Tritton NAS sucks

— SjG @ 5:15 pm

Gonna buy a Network Storage Device?

Here’s my recommendation: avoid Tritton’s NAS at pretty much all costs.

The device is flaky at best, even with the latest firmware. Samba-mounted connections don’t always get properly updated when there are filesystem changes. User permission settings seem to work based on the values you enter … but only when the moons of Jupiter are aligned.

Some people claim that they’ve been able to get the NFS implementation to work; I have failed from both Mac OS and from Linux. I don’t claim to be an NFS wizard, but I’ve been able to get it to work with many an operating system in the past. No dice here.

Tritton’s tech support is useless (but does contain priceless FAQs like “You may notice that folders begin to reproduce, disappear, or rename themselves on the storage device. This may also result in data loss that is unrecoverable,” with the solution to upgrade the firmware).

The device is only configurable through a web interface, which would be OK if they didn’t use a lot of un-necessary proprietary crap that prevents it from working with anything other than IE 5 or 6 on a Windows PC. Got a network with only Macs and Unix machines? Sorry, you’re just out of luck.

To make matters worse, they’re violating the GPL, and not releasing the source to their kernel modifications. So even if you want to fix the problems yourself, you can’t.

Getting a Snap appliance is certainly more expensive than a Tritton. But at least it’ll support RAID (and you should use raid. Really. Trust the sad voice of experience.). And Snap appliances actually work as advertised.


Sat, 19 Feb 2005

Content Management

— SjG @ 6:56 pm

Content Management. Seems like that’s what everyone wants for their web sites these days, and it’s no wonder. You can keep your site up to date. You can change things in response to your users, your boss, or that fellow with all the crazy ideas over in marketing. You can change things according to the season, or according to your mood. And lastly, at least in theory, you don’t get “locked in” to a specific vendor for maintenance.

So Content Management’s a good thing. But people mean different things when they use these words.

  • If you’re a gamer and want a portal site for your gaming group, you mean one thing: a place where you can post news and images, list members, hook in a discussion board, and maybe post game rankings; this is also probably what you want if you have a web site for your cooking club, your neighborhood, or perhaps your local political organization.
  • In the other extreme, you’ll mean something else entirely. If you’re, say, the marketing director for a publicly-traded company, you want each department head to be able to edit the section of the company web site that pertains to their work, but you want work-flow management so that the marketing and legal departments can have final say on what goes live. You’d probably like revision control, fine-grained access control (who gets to upload or edit what, and who can reject or approve it), and other similar features. You may well want the site to be able to get content from other back-end business systems.
  • Then there’s the middle ground, which includes some of the features from each of the former. If you run a small agency, you’ll want to be able to post comps and scripts to your clients, you want to update your awards page each time you win something, and you probably want to put those award-winning ads online for people to view. You might want some access control, but you don’t need revision control or interfacing with back-end systems.

For the first case, the community site, there are dozens of PHP-based Open Source solutions. There’s PHP-Nuke, Post-Nuke, Drupal, Mambo, Xoops, Typo3, Xaraya, and countless others. All of them are well adapted for this specific niche, and most of them are pretty horrible if you want to extend them or use in a way that’s not part of the original design. Call me an elitist, but the bar to entry here is very low; there are a lot of programmers who don’t know what they’re doing, and they’re doing it very publicly. There’s a strong emphasis on cool and futuristic visuals, and something of a shortage of solid architecture. Few of them create HTML that will validate, and even fewer make proper use of cascading style sheets (CSS). Fortunately, you can road test them all at OpenSourceCMS.com, and see if any work for you.

For the second case, the corporate solution, there are a multitude of commercial packages which vary in price from the low 5-figures on up to as far as you want to go. We use Enonic VerticalSite for this kind of corporate site. It’s Java/EJB based, and uses widely-accepted standards like LDAP, XML, and XSLT, so it can integrate into a vast array of other back-end systems. XSLT allows the developer total freedom in the templating so, page sizes can be reduced through the use of CSS. It’s a solid solution, and affordable for its class.

I’m pleased to say that there is finally a reasonable contender for the last case, the middle option. In the past, we’d tried to adapt projects from the PHP Portal group to serve in this capacity, and, frankly it was not a very good experience. Now, however, there is CMS Made Simple. It’s a straightforward framework, that provides a developer with a lot of basic functionality: group-based permission system, hierarchical content management, and support for XHTML templates and CSS. But what’s best about CMSMS is that it’s a lightweight framework that doesn’t come with a lot of unnecessary extras, yet it supports an object-oriented API for adding modules, so you can add in any functions you find lacking.

I’ve been madly developing menuing systems and a flexible Feedback Form submission system for CMSMS (you can find ’em on the Project Wiki). The new API seems pretty solid, and it’s certainly easy to develop for. I’ve found the developers to be personable, helpful, and very positive when I’ve communicated with them on IRC.

My next project, which I plan to implement using CMSMS, is a portfolio tool for artists. The tool should enable artists to create web sites to showcase their work.