Debugging CakePhp in Eclipse

I've been getting my hands dirty with some CakePHP programming lately. I'm still doing my share of Rails, but have a cake project going as well.

One of the things that is a must have for me is an integrated debugger in my IDE. I feel a bit like I have a hand tied behind me without it.

So getting going with cakePHP means spending some time getting debugging to work in Eclipse. It seems to be working well enough at this point, so here are the steps that got me where I am now.

1. I personally would recommend downloading the all-in-one PDT download from the zend site.

http://www.zend.com/en/community/pdt

2. Also, from the same page above, download the webserver debugger. Its the last link on that page, at least right now. Download the correct version for your platform.

3. Install eclipse

4. Follow the README instructions found in the debugger archive. This will involve editing your php.ini file.

5. Restart your Apache server

6. In Eclipse, click on the debug button and choose "Open Debug Dialog...". You should see something like this:



7. Right Click on PHP Web Page on the left and Choose new.

8. Server/Debugger should be Zend

9. You shouldn't need to change the PHP Server, unless you are developing on a vhost that is on a port other than 80, like I am. If you are, click on Configure... and add a port in that dialog.

10. Browse the File input to the /app/webroot/index.php of your project.

11. Deselect Auto Generate, and put /index.php in the right hand entry.

12. Save your progress.

At this point, you should be able to click debug and you'll stop at any breakpoints you have set. I also prefer to deselect "Break at first line", but thats your choice.

Long Vacation

Just back from 2 seeks of vacation on the east coast. Lots of fun. Very hectic.

3 of those vacation days were spent in Reston, Virginia attending the Advanced Rails Studio, put on by the folks at Pragmatic Studio.

I had not yet had the chance to mingle with any other Ruby on Rails programmers, other than those I work with. Clearly there is an advantage to taking part and contributing to the Rails community. I'm sure I learned as much in those 3 days as I had during the many months previous.

Thanks to Dave, Mike, and Chad for putting on an excellent training. I highly recommend it to others in the future.

Vacation!

I'm off for two weeks of vacation time, starting tonight. The family and I are taking a red-eye to DC, the moving on to various parts of New York State after that.

When in DC, I'll be attending the Pragmaticstudio's Advanced Rails training in Reston, VA.

Dude, thats a cool tank

Multisite Rails plugin

It seems like almost every site we create around here needs to be 're-brandable'. Affiliates that market our services want to be able to provide their own face on our sites.

Before I came here the rebranding had been hard coded and pretty awkward. I was able to somewhat simplify it through some rails helper functions that at least allowed us to split up new sites fairly easily.

Well, as usual, I didn't search the plugin repository well enough (OK, at all). Given the latest project that will require rebranding to sell to affiliates, I wanted to come up with a better solution than I had been using before. In a general search for plugins that might be useful to me (he learns!), I found multisite. This plugin allows me to provide different views attached to the same controllers.

After installing the plugin, I generate a new site. Assuming one of the sites I'm creating is called 'mysite.com' I do this from RAILS_ROOT:

script/generate site mysite

The first time generate site is run, it creates the RAILS_ROOT/sites directory, and then inside that, in this case, it creates a 'mysite' directory. The 'mysite' directory contains 2 subdirectories, 'views' and 'public', which should be familiar. The contents of the views directory is structured just as the base view directory is. A directory for each of your controllers, plus a layout directory.

So, any view I have need of should be put here.

Much like the 'layout' command, multisite has the 'site' command, which controls which view directory is used. Add the following to your application.rb controller:

site :which_site

private

def which_site
request.host.split(',',[-2])
end

The which_site function can of course use any method you can think up to determine which site to use. It only has to return the site name that appears in the sites directory.

But what if I have two sites, 'mysite.com' and 'yoursite.com', which mostly have seperate pages, but share a few. Maybe the login page is the same, it just puts the same view in its respective layout template. If that is the case, you only need put that particular view in the base views directory. Using multisite, Rails first looks in the base views dir, and then looks in the multisite views dir if it finds nothing. This can make things a bit confusing, but shouldn't be bad after you're used to it.

You'll notice that the sites directory also contains a 'public' subdir. This is where you can put all your static content, just as in the normal public directory. There is an issue with this particular feature that caused me to not use it. This is a great feature for production, but for me is problematic in development. Access to the views directory is not automatically redirected as with the views directory. You must use Apache to serve those static files. I don't want to run apache on my local machine, so that means I can't properly test my sites locally if I use multisite. I chose to use the base public directory and ignore multisite's version.

There's not much to multisite, but its proving very useful to me.

Authentication Database

One of our challenges here is the number of databases that we try to maintain. Some Postgres, some MySQL. The means that our CSRs either have to look multiple places for info about a certain customer, or they simply don't have the needed info about that person.

With one initiative after another that requires a new db, complete with a User table, I've decided to create a centralized "Auth" database, so that we can keep the users in one place. We can then build a dashboard type app for it, which the CSRs can use to find info on a customer when they call in.

The Auth database should have as limited a number of tables as possible. It needs to be kept very generic. Because we'll mostly be using Ruby on Rails to access it, I'll also be creating a plugin that can authenticate against it. I expect to be able to inherit from models in the plugin, so that I can associate user data from the auth database into whatever app I am creating that will use it.

An old post on Dave Thomas' blog Sharing External ActiveRecord Connections has proved very helpful so far.

Speaking of Dave Thomas, I look forward to attending the Pragmatic Programmer's training session in Reston, VA, next month.

More later as the auth database take shape.