PHP

You are currently browsing the archive for the PHP category.

Bridging the gaps

December 21, 2005 in .Net, Commercial, Entrepreneur, Free and Open Source, Ideas, PHP, Social Software, Strategy | 2 comments

A long time ago, I got the chance to go to the Grand Canyon. It’s pretty amazing, I don’t really have the words to describe it adequately. It’s just amazing…at points it’s 10 miles from edge to edge, with a near vertical drop-off to the bottom. It’s huge. But at some places you can look across to the horizon and see flat land stretching outwards, then when you take a few more steps and see that there is an enormous chasm between you and the edge of the world.

Software seems like that to me at the moment.

We’ve discovered the power of the Internet, and being connected. We’ve discovered that we can devise new applications for groups of people, that we can aggregate information for something larger than the individual bits. We’ve found out that being able to access information from anywhere is hugely useful.

But our desktops and the Internet are two completely separate software worlds.

If we build a web-based system then it’s accessed through a browser and can’t interact with our desktop.

If we build a traditional bit of software then it has to be installed to be used, and it will be subject to platform quirks and problems with particular configurations.

There’s a chasm between the two worlds.

AJAX and Web 2.0 is better, but at the root it’s an attempt to make the browser behave like the desktop. And it’s subject to it’s own problems. Nevertheless, I think that this is a step towards the solution.

Here’s what I want:

  • I want to be able to make applications that are client-server in nature;
  • They should expose a web interface for when I’m not at my PC;
  • They should have a federated data-store behind them; that is, there is some data I don’t want to expose to the Internet but the data that is exposed to the net should be part of a bigger whole, rather than a copy. Alternatively if the data exposed to the net is a copy, then syncronisation should be 99.9% automatic;
  • I want to be able to run any application without being connected to the Internet, maybe with reduced functionality;
  • I want my applications to enjoy all the benefits of normal desktop interaction; the granularity of actions should be small; I don’t want to think of the world in pages, and I do want to be able to drag and drop;
  • I want to be able to try applications without an install. I’m willing to install if I decide that something is useful.
  • I want security; I don’t want my PC open to crackers.

Mostly, this vision is already achievable. (Microsoft is calling this sort of app a smart client.) But it takes hard work because you have to build the infrastructure by hand. In fact, most of the infrastructure is re-usable and should be abstracted into a tool and framework.

Now there are two or more environments that are partly suitable:

  • Java. Can run on the desktop. Can run on the server. Can run on multiple platforms. Can deliver responsive apps – witness Eclipse. But there’s no easy way to build dual-headed apps that I know of. Do you know of a way? There’s the ability to run from the web with Webstart.
  • .Net. Can run on many versions of Windows. Runs on client. Runs on server. Has good integration. Can build dual-headed apps. But it’s not great for delivering software if you don’t want the source to be readable. Granted you can get an obfuscator, but a industrial-strength obfuscator should be part of the basic package. A big downside: you need the giant 20MB runtimes to be on the client machine. There is no linker available as part of the MS package which would reduce the size of most apps and allow you to ship a single file, but you can buy one from Remotesoft. And lastly, .Net isn’t big on platforms other than Windows.

I’m sure that there are other ways of doing this too; for instance, if you install the PHP and GtK runtime on the client then you could use PHP locally and remotely. But other solutions are less integrated.

Overall, I don’t think that either of these solutions are great. It seems like it’s going to be write-n-times for a while.

Truly crappy coding standards

November 19, 2005 in PHP, Software development | 3 comments

This is a rant. I try not to rant usually, but I’ve been driven to distraction. 

For those who don’t know, Drupal is an open source content management engine. I’ve been working on a web site which has been built using Drupal. I’ve gotten pretty deep into the Drupal code, and for the most part it’s pretty well designed.

For those of you who are interested, it’s built around a callback model that allows you to introduce new modules. When you build a module it must provide a standard set of callback functions named in a particular way.

One thing that makes Drupal good is that it has a set of coding standards for code that is included in core Drupal or accepted as a module. (There are lots of modules to download.)

But what’s driving me crazy is the coding standards are not chosen to be readable.

Consider this:

if ($something) {
  if (DoSomething($something)) {
    DoSomethingElse($something);
  }
}

versus

if ($something)
{
  if (DoSomething($something))
  {
    DoSomethingElse($something);
  }
}

Now, I’m convinced that the second is better for several reasons:

  • Whitespace is your friend
  • It’s easier to match brackets
  • God intended code to be readable. Especially when there’s a lot of it in one place.

Unfortunately, Drupal uses the former style. It borrows the styling from the Pear standards. (Pear is a library of PHP functionality.)

I posit that one of the reasons that Pear usage has not exploded has to do with truly crappy coding standards for blocks. 

Using MySQL or other databases as a file system

May 12, 2005 in PHP, Uncategorized | 1 comment

I’ve just come up against a problem; I want to use the very nice Dokuwiki to start to track the functional requirements of a project. Dokuwiki works on plain text files: it needs to be able to read and write to web server space.

Most ISPs are very wary of this sort of thing. But many provide MySQL. So wouldn’t it be nice to have a set of drop-in replacement funtions for the PHP file commands, to let you use MySQL (or another database) as the the filesystem.

Now, I know that there are a bunch of reasons to do with speed and memory usage why this is a bad idea. And I know it’s a huge hack to get around open access to the file system. But it would be ever so useful in this situation.

I’m imagining something like:

$dconnection = /* fill in your database connection code here */
$filehandle = dopen ($dconnection, $filename);
$data = dread($filehandle, 1024);
dclose($filehandle);

It would have to do ghastly things to manipulate the data, especially if you were writing at byte level, but it would work well on a certain class of i/o; when it’s input or output as a block.

Someday.

MVC for web sites considered non optimal

April 11, 2005 in PHP, Software development | No comments

[Originally written in Janauary 2004]
Tanasity invested in building an MVC framework that we’ve used on a series of sites for clients.

It features:

- MVC of course – on a per page or module basis

- Centralised routing of requests to page/module handlers – a Dispatcher

- Fit for use with Dreamweaver to hand build the look

- An architecture that encourages use of Data Access Objects to encapsulate database interaction.

Of course it will never be complete, but now that we’ve got enough experience using it, we are starting to reflect on the suitability of MVC in a web setting….

Firstly – MVC was invented for a different use. It was designed for for an interactive environment, where the system needed to be responsive to each action that the user took. However, the stateless client-server page-at-a-time nature of web means that there is always an interlude and a page (and model) reload between the user seeing it and the server responding.

Secondly, MVC is often used where there is a core model which has several views – different representations of the model. This isn’t often the case for web applications given the stateless nature and limited user interface expressible in HTML/XHTML/XML.

Thirdly, applications built around a database aren’t usually directly models of something. They are usually data stores. It’s possible that you want more than 1 view on the data store… a table perhaps, and a graph, but remember that web applications are not interactive in the sense that the user can change the model at the click of a mouse; the events that the server responds to are typically much sparser than the interaction that the user has with the page.

Lastly, there’s at least a server component which operates on a per page basis, but there may also be a client component to the page (in JavaScript usually) which has to mesh with the server side. This isn’t a feature of the original MVC, which assumes only a single layer.

I don’t yet know what a more fit-for-purpose pattern for a framework is, or a better way to structure the framework. But I’ve got some ideas..

It should keep page View (the design) and the response in close proximity. That is, it should be obvious where to find the code that responds to any page. (In the Tanasity framework they are usually kept in the same file.)

The close proximity in our MVC framework – achieved by keeping page setup and response in the same class – has made it easier to track impacts when changes happen. But it also has a flaw in that because different parts of the framework built around a page are executed before or after the page is displayed to the user, there’s a sort impedance mismatch. The object that handles page setup isn’t the same object that handles page validation despite the class structure giving that impression- the HTTP reply separates them and so if you want to transfer info between the two it needs to be passed as part of the View.

The pattern should keep page logic (Model)separate from page display (View), but there’s probably no need to separate the Model and the Controller at the page level. I can’t recall a case where the Controller has been much more than a passthru mechanism triggering the Model.

I like the ability to integrate graphic design into an application. That’s because applications that exude quality have good graphical design. Pages are individuals rather than cookie-cut using a central template. (Granted this is a factor for the framework and not the underlying patterns used.)

I like the separation of the pages from the link logic. It makes it possible to approach the system design in a structured way if the page transitions are not directly encoded in each page. You have a central list of application flow.

Perhaps the Client side is more suited to an MVC treatment than the server side because the client has the possibility of being much more responsive to events. This doesn’t address the fact that often the client is a more responsive validator for a page than the server, and but usually it’s untrusted and even if there is client-side validation, it needs to be repeated on the server. Consequently there’s the possibility for shared code, and a good framework would allow this.

If you’ve got ideas on what you think a good web application framework should include, how it should work, or the patterns that should underlie it, then you can reply here, but it would be best to put your response in the conversation at phpPatterns which triggered me into writing these thoughts down. There’s also some discussion at PHPArchitect.

Jeff Veit