Everyone knows that when you have a text box which accepts a number, it should automatically right-align the text content. Well maybe not everyone, but accountants certainly do and if you’re writing an application for an accountant it just won’t look right unless the values are right-aligned.
Simple, I thought - text-align:right in the CSS and the jobs a good ‘un. Well yes, you would think so. The fact of the matter is that text-align:right is only supposed to apply to block level elements (according to the CSS2 specs), although it isn’t quite implemented that way in all browsers. So, add display:block in there as well just to be on the safe side:
Right Align: <input style=”padding: 0px; display: block” type=”text” />
Job done! Well, not quite if you are viewing this in Internet Explorer 7. Click in the input field which is aligned to the right and no cursor displays at all! I must be tired today because this took me ages to work out and I found no reference to it anywhere in the web. For some reason the cursor is there - it’s just off to the right a little too far. I say ’some reason’ when I now know that the actual reason is that the padding is set to 0px. The reason for this happens to be because it has inherited the property from other elements in my form layout, but in this example I have added it specifically. Add a little padding to the right and hey presto:
These days I always seem to find myself writing installers for clients using WiX. What usually happens is I get there to find they are really struggling to maintain their current installers, more often then not in InstallShield. So I go and tell them they should try WiX since it has so many advantages over certain other products. For a start it’s actually maintained by several Microsoft guys and enjoys a big support community. Also since the source code is written in XML it is much easier to check in to source control and maintain.
Anyway, to cut a long story short, my evangelising on the subject usually ends in the words ‘here you go then, write an installer for that’. And so I end up with the job yet again.
That’s not to say it doesn’t have its issues like so many other things in the world of software development, especially when you end up writing some monster installer that installs a web-client, web-services, windows-services and the odd database or two.
Today’s issue was ConfigureIIS which is a custom action executed if you are creating a <WebVirtualDir>. Unfortunately even if you are not installing the web component that needs IIS to be configured it will still attempt to execute ConfigureIIS which causes an error to appear if IIS is not installed. Just having a web component in your installer is enough to fire it off.
Looking on the WiX mailing lists it seems that it is a known issue and the only way around it currently is by modifying and recompiling the source code for WiX itself. Not a lot of fun when you just want to write an installer and it takes you away from the currently released code, which I find it is best to avoid when working for other clients.
However, in the process of modifying the source I found the property SKIPCONFIGUREIIS. Set this to true and it no longer runs the ConfigureIIS custom action. Obviously you need to make sure it’s only turned off for the relevant features of your installer. It’s just a shame they didn’t make it a little more widely known!
To be honest I could have kicked myself since I already knew of the SKIPINSTALLSQLDATA for turning off the database activity when not required. That one is a little more published though.
Since I got the Mac a couple of months ago there is one thing that keeps bugging me; connecting to my server is not particularly reliable. Dropped connections seemed to be pretty much guaranteed half way through a job that involves anything more than a couple of Mb of data. Since I tend to use the server for automated backups of my other machines it just hasn’t been happening for the Mac. Slowly I’ve got more and more concerned about having no regular backups.
A chance comment I came across whilst Googling for something else seems to have cleared up the issue. It seems my technique of using the Network utility in the Finder was the main issue. It is certainly the simplest option and most people seem to use it for that very reason. The trouble is it doesn’t always get the protocol right. You can check this by creating a connection to your server (in the finder choose Network and then browse to your server and connect to a share), selecting the new connection and then checking the info (Apple key and I). Mine shows up as:
cifs://my_server/backup
Since my Linux server uses Samba for the network shares it’s far better to connect using the Samba protocol:
smb://my_server/backup
The easiest way to set this up is through the ‘Connect to Server’ utility in the Finder. This also stores your server connections for easy future access. You should be able to simply type the connection string in and then connect at will. Hopefully you’ll see a much more stable connection in future.
(An extra tip - once you have the connection set up you can automatically connect at login by adding it to the list in System Preferences->Accounts->Login Items)
Now don’t get me wrong - I love CakePHP and I know there’s a good reason for the controller/action format of urls. In fact I often find it helps to have a framework that forces that sort of thinking on me all the time since most of the sites I write are more application than website. It’s a bit like the good old days when I was struggling to get my head around the concept of OO after coming from a very procedural background. I could probably have done with a framework then too.
So I do think that it’s great for web applications, but not necessarily for web sites. Clean urls have many touted advantages over controller/action urls for a web site. I’m not sure how many are true (things like Google favouring them seem like a good reason, if that is actually the case) but for me it’s best simply because they are not controller actions. A ‘contact me’ page is a ‘contact me’ page. It’s not really an action on a particular controller in your application. An ‘about’ page is similar - it just seems wrong to say ‘about’ is an action on ‘pages’. Well, it does to me anyway. Whilst I usually write web applications there is almost always a web site component like this to them and I think it’s fine to seperate those two concepts even when they’re on the same site.
Now it’s true that you can write static pages directly to the webroot, but my clients almost always want some management control over those pages. As much as I’d like them to have to come back to me every time they want to change a word it just doesn’t seem particularly fair and just harms my chances of repeat business! All of the other solutions I came across just seemed rather complex and often slightly dodgy. So I came up with a simple solution of my own that works fine.
Basically you add an entry to routes.php for each of these pages:
$Route->connect('/contact/*', array('controller' => 'pages', 'action' => 'contact'));
This will redirect any call to ‘/contact’ to ‘/pages/contact’, but without giving that fact away to the user. It’s true that you can’t now have a controller called ‘contact’ but then you wouldn’t want one anyway (the main reason being controller names should be plural when following the Cake conventions!). You can add as many of these lines as you like. If you end up with more than 2 or 3 you might want to question whether those pages should have been part of a controller!
Something that’s had me confused for a couple of hours today is using a checkbox in my CakePHP application. I’ve been using the html helper to create the relevant html and was initially confused by the fact that it not only creates the input element but also a preceding hidden input element.
<input type="hidden" name="data[Item][big_rock]" value="0" id="ItemBigRock_" />
<input type="checkbox" name="data[Item][big_rock]" id="ItemBigRock" value="1" />
So I did the best thing I could think of and ignored it, but when I came to creating the form to edit existing values I just ended up getting strange results. The checkboxes seemed to have a life of their own, checking and un-checking at will between post-backs. Google came up with several posts about the general problem most people come across with checkboxes - the fact that they post back nothing if they are not checked, but it took me far too long to actually put the strange hidden input field and this standard behaviour together. In my defence, there is very little documentation on this (that I could find) for CakePHP. (more…)
I’ve been using CakePHP for quite a while now with no .htaccess issues at all, either running locally or on hosted sites. That all changed last night when I couldn’t get it to work at all on one of my budget hosting sites. Instead of my application all I saw were 500 Internal Server Errors.
I found that the issue was definitely down to one line in the root .htaccess (which was unmodified from the original CakePHP download):
RewriteRule (.*) app/webroot/$1 [L]
Unfortunately my cheaper hosting doesn’t allow me access to the error logs so it was difficult to diagnose the problem. By 11:00 last night I was certainly not in a good mood and no closer to an answer. I managed to Google plenty of references to similar issues but none solved my problem.
This morning I resorted to the hosting company themselves and within an hour they came up trumps! My thanks to Rob at VirtualNames support who not only worked it out, he even changed the file for me!
It looks like the problem is that the mod_rewrite rules don’t like fastcgi, which is the preferred option for this hosting account - it seems to try and redirect the internal URLs for fast cgi causing a rewriting loop. VirtualNames support felt it would probably work if the PHP mode is switched back to module mode, but they also came up with a fix to the .htaccess in the domain folder to (the root .htaccess for the CakePHP installation):
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_URI} !^/cgi-bin/
RewriteRule ^$ app/webroot/ [L]
RewriteCond %{REQUEST_URI} !^/cgi-bin/
RewriteRule (.*) app/webroot/$1 [L]
</IfModule>
This stops it trying to redirect the fastcgi internal access urls, and appears to cure the problem. It looks like the other .htaccess files do not need changing. .htaccess and rewrite rules are still a bit of a black art to me. After this they are going on my list of things to pick up!
I can also recommend VirtualNames as a budget hosting solution should you need one. Their support people actually do…erm…’support’
I’ve been slowly working through all of the bits I usually use for web development on my MacBook, attempting to get it set up in a similar way to my PC. No particular reason for that, it’s just what works for me and means I can swap between machines whenever I like - PC for the working week and Mac for out-of-hours seems to be my pattern…
On the whole it has gone fairly smoothly, though it hasn’t been entirely without problems. Here is the detail of what I have set up and where I came across issues. It might help someone if they come from a similar background to me of PC development. (more…)
I’ve spent a lot of time recently using Google and Google based technologies (Google Earth, Google Mail, Google Home Pages, Google Analytics, Google Spreadsheets, etc, etc) and I just never fail to be impressed. I didn’t even mention creating my own modules for my Google Home Page which is just a joy. Being a developer of SharePoint Web Parts from time to time I have a view of the ‘other side’ and just how hard it is to get things to work as you want. It’s always too complicated - people just want information and my job of getting that to them is far harder than it should be.
But Google stuff just works! It’s simple, and it JUST WORKS! The way they get to work results in people creating stuff that other people want. It must be the way they work, I can’t see anything else that would cause that effect.
I’ve been using CakePHP for quite a while now with no .htaccess issues at all, either running locally or on hosted sites. That all changed last night when I couldn’t get it to work at all on one of my budget hosting sites. Instead of my application all I saw were 500 Internal Server Errors.