In preparing for Lion, I’ve decided to see how the reverse scrolling (i.e your fingers move the page and not the scrollbar) would pan out on my MacBook. For web pages, I took to it immediately and it felt right straight away. As I went a little further, with documents and editing in TextMate, it also felt natural with only a couple of slip ups reverting to previous behaviour, especially when I was editing rather than just viewing. Indeed, when I really needed to get down to some serious editing, reverse scrolling had to be switched off it was such a distraction!
My issues became a lot worse when it came to Finder though. It didn’t “feel right” when I was scrolling the display of folders and documents, and I repeatedly kept following my instincts and found myself trying to scroll with the scrollbar. I wonder if this is because I don’t feel like I’m moving a document or piece of paper, or maybe, I’ve become used to reverse scrolling through the use of my iPhone – which especially make sense when I’m scrolling web pages, but the iPhone lacks any kind of file browser and I’ve never had to scroll through a similar interface. This also might explain my difficulties when editing documents – something I rarely ever do on an iPhone, as I’m just a consumer of media on that device rather than my MacBook Pro where I’m both consuming and creating.
In summary, the reverse scrolling, which will be default in OS X 10.7 Lion, is natural for web pages and for viewing documents but frustrating for Finder windows where, even if I’m using reverse scrolling fine everywhere else, it just doesn’t “feel right”.
What happens is that the SQL statement you pass to prepare is parsed and compiled by the database server. By specifying parameters (either a ? or a named parameter like :name in the example above) you tell the database engine where you want to filter on. Then when you call execute the prepared statement is combined with the parameter values you specify.
The important thing here is that the parameter values are combined with the compiled statement, not a SQL string. SQL injection works by tricking the script into including malicious strings when it creates SQL to send to the database. So by sending the actual SQL separately from the parameters you limit the risk of ending up with something you didn’t intend. Any parameters you send when using a prepared statement will just be treated as strings (although the database engine may do some optimization so parameters may end up as numbers too, of course). In the example above, if the $name variable contains 'Sarah'; DELETE * FROM employees the result would simply be a search for the string “‘Sarah’; DELETE * FROM employees”, and you will not end up with an empty table.
Another benefit with using prepared statements is that if you execute the same statement many times in the same session it will only be parsed and compiled once, giving you some speed gains.
Oh, and since you asked about how to do it for an insert, here’s an example:
$preparedStatement = $db->prepare('INSERT INTO table (column) VALUES (:column)');$preparedStatement->execute(array(':column' => $unsafeValue));
So you can send a lot of stuff over web services, mostly primitive types, but what if you want to send pictures?
I’m not talking about sending the URL to a picture, but sending the actual image data over a web service, so that the client can display it. It’s really very simple, but also a fun addition. On the Web Service side, you need to take the image and encode it into a primitive type that can be handled through SOAP. To do this, I load the image, then convert its contents into a Base64 encoded string. I can then send this string back to the client.
Very simple! Now on the client side, we simply reverse the process.
Here is a synchronous example, for a better asynchronous example, have a look at my Visual Studio solution. This example is for a Windows form application, with a PictureBox object.
If you encounter errors, regarding the max length of strings, simply update the properties: maxBufferSize maxRecievedMessageSize and maxStringContentLength in the app.config file, and set the value to which 2048000 should be big enough!
Last night I found SilverStripe and it is simply amazing. It’s the perfect solution for small simple static websites I find myself building regularly, and with the templates being so well made I can customise them and having a working site in less than 2 hours.
Both of these are customised, and were complete in under an hour. The admin interface is incredibly simple, and the help pages will help novice users a lot. I’m also loving how extendable it is. There may be a lack of modules/widgets (or at least a lack of useful ones) but with SilverStripes modular design it’d be very easy to create new ones.
I’m not sure if it’s issues with our work internet, or firefox, or silverstripe, but I’m coming across occasional bugs – I can only hope they’re ironed out. It will be insteresting to see how simple it is to upgrade/update SilverStripe to newer versions.