The first version had a pretty basic component, used SOAP to communicate and had no in-built schema check to always produce valid WAPL code.

PHP Package as a Vendor

But now there is a PHP package available that handles the schema check and communication can be done by either REST or SOAP (the preferred method would now seem to be REST seeing as it has better error handling and doesn’t trigger a fatal error if a soap client can’t be created).

Plugging that package in as a vendor should be dead easy (although it does need a few little mods and upgrades of its own first) and then it’ll be just a case of writing a component and helper to make use of it.

Hopefully I’ll have something ready this week so you’ll be able to mobilize your real world cake apps!

Let me know if you have any ideas for how it should be built – as a component & helper? Maybe a plugin? Or just keep it as a vendor.. or maybe all of the above!

Related posts:

1. REST or SOAP? Or don’t care?

The setup you’d probably go for is some sort of load balanced setup, with multiple web servers and possibly a couple of database servers behind the scenes. You should also be thinking about the wonders of virtualization and all the benefits that brings but that’s for another day.

Having multiple web servers brings about its own set of issues. Your blog code needs to be deployed to all web servers (preferably at the same time) so that if you get visitors that happen to hit different machines, you give them the same experience.

Deployments and Uploads

But that’s not so much of a problem – you could deploy code to all servers with Ant or Capistrano, or even write your own system to do it exactly to your requirements.

However, in this kind of setup, you’re going to come unstuck with plugins, themes and uploads. WordPress has an awesome upload utility, but the file you select from your local computer will get uploaded to a location on a single machine in your server farm. When a visitor lands on a different machine, they won’t see the upload. If you’re using the automatic add plugin or theme wizard built into the newer version of WordPress then it’s the same situation.

Link to NFS locations

But the situation is not nearly as dire as you may think though. There are loads of ways to combat it – and it’s a piece of cake if you’re using Linux! The easiest way is to create an NFS share on web server 1 and link to it on web server 2 so that the “/plugins” directory on 2 actually points to the location on 1. Easy!

If you’ve got a file server, even better – create your NFS on there and link to that location instead so that content really is separate from your code!

With windows it’s just as easy with shared directories – same principle, just a different terminology.

The only issue you’ve got left is that some plugins may have the paths to their files built slightly oddly so that they load the wrong files. But then, if you’ve got errors with the plugins, it may be time to look for alternatives!

Have you had any problems with WordPress on load balanced servers? How did you solve it or did you choose another setup?

No related posts.

His reckoning was down to the fact that most specifications for functionality aren’t tight enough. For example, if the spec for an adding function was to add two numbers together, adding 5 and 9 together and returning a value of 162 was acceptable. Even returning nothing, or null, or a gazillion was also ok. The specification should have said that the function had to add two numbers and return the correct mathematical result.

For a developer, this is great news. You don’t have bugs anymore, you have “undocumented features”. Feature specifications get better and it’s easier to write code that satisfies the requirements.

It’s a bug!

But I personally think blaming bugs, and they are bugs, on the specification writers is lazy. Bug reporters, whether they are developers or not can get quickly hacked off with being told that an error they’ve found isn’t actually a bug, but it’s the fact that it’s actually been implemented exactly to spec.

A bit of common sense in all of this is definitely required. If you need an adding function, it’s obvious to anyone that it should return the result. If the spec doesn’t say so, just do it and move on.

And if you need a function to return the results of whether a visitor is a mobile device or not, it’s probably wise to actually return the value rather than store it in a cookie. Oops!

No related posts.

Take my Wapple Architect Mobile Plugin for WordPress for example, and the way it used to communicate with Wapple’s web services. It used to use SOAP simply because that was the protocol we chose to employ as our means for delivering web services.

SOAP is not always available!

Now don’t get me wrong, what we’ve got is a really smart, well-designed and developed web service that’s both extensible and easy to use. But the fact was that if you hadn’t got SOAP, you wouldn’t be able to use it. And if you’d only got a shared host available, you might not be lucky enough to have a decent one like me (Evohosting) who allow you to install SOAP on your server.

So what we’ve done is to create corresponding REST web services so you can use Wapple Architect and your dev key, but either request data through a URL by modifying a query string, or through a POST request with something like curl.

Nothing can stop you now!

This is fantastic news all round. For developers who are experimenting with Architect, it’s even easier to develop. And as we’ve already incorporated this new technology into our plugins for WordPress and Joomla, you can use it even if you don’t want to delve into code!

The latest release of the WordPress mobile plugin is out now (version 1.4) – have a read of the full feature list and the new REST web service support in an article over at Mobile Web Junkie.

On a more general note, what do you prefer to use, SOAP or REST? Or maybe XMLRPC? If you haven’t got a clue about any of this but would still like to have a go at leaving a suitably technical comment, here’s a few words you may want to include: “combobulating”, “aerodynamics” and “flux capacitor”.

Related posts:

1. Mobile CakePHP Apps

Unfortuntely, the powers that be decided that the new version didn’t need them, so rather than sulk about it (ok I did sulk a bit) I’ve turned those hand crafted cumulo nimbii into a WordPress plugin!

All that work designing the clouds, making sure they appear at random locations and animating them so they move across the screen as if blown by a category 5 hurricane. None of it has gone to waste now it’s available for everyone!

Best of all, there’s a hot air balloon that appears at a random time and moves across your site from bottom-right to top-left!

Clouds on WordPress

Any day now, WordPress will approve my plugin (and lets face it – who wouldn’t want clouds on their site!) and you’ll be able to search for clouds when installing a plugin! But in the mean time, all of that cloud goodness is available for all to see on here! (They’re the white fluffy things at the top of the page incase you missed them).

By the way, keep your eyes peeled for any other flying objects appearing (other than the balloon) – if you spot them feel very privileged as they only appear to a chosen few!

If you’ve got any suggestions for other things that fly – Elliot on his bicycle with ET in the basket or a bi-plane are 2 that spring to mind – let me know and I’ll try and include it!

No related posts.