That’s what this post is for.

So on to the nitty gritty details.

Start with the RESTful Authentication Tutorial:

Follow the README to install, but READ THIS FIRST to fix the ExceptionLogger error Then follow these instructions to fix the OpenID plugin error Make sure you get your recaptcha keys for the config.yml, otherwise failed login attempts will bust your application. Fill out the config & database.yml files accordingly, run your database create & migrate rakes, fire up the server and make sure it looks good. Cool? Let’s move on: Define the objects Let’s begin by pointing out what, exactly, we’ll be building this application around: Galleries of Photos that Customers can order with a private Account provided to them by an Admin who can manage the galleries and review the Orders, which are also available to their respective customers. I will go through how to set up the following models like so:

• Galleries
  • has_many :photos
  • belongs_to :customer
  • title
  • acts_as_urlnameable (pretty URLs)
• Photos
  • belongs_to :gallery
  • paperclip attachment: image
• Customers
  • username, password, full name
• Orders
  • has_many :line_items
  • belongs_to :customer
• Line Items
  • belongs_to rder
  • quantity, size, price

So let’s build the Galleries first:

Then edit the Gallery model:

That’ll be fine for now. Let’s add the Photos model with paperclip image attached:

Now edit the Photo model as such:

You should read all about the paperclip gem if you need more info on this model. Basically, we’re telling it to allow image attachments to the Photo model. Customers can be the RESTful Authentication Tutorial User model, just need to add a couple things here:

Let’s worry about Orders and Line Items later. We’ll have to add a cart, too. I’ll cover it, but it is all derived from Agile Web Development with Ruby on Rails Third Edition

Run your rake db:migrate and confirm all is well. Delete the Galleries layout file so it uses the application layout.

Let’s go see http://localhost:3000/galleries and play around. Add a gallery and then go to edit it. This is where we’ll add SWFUpload. Follow Jim Neath’s advice for this.

You’ll want a photos controller:

The create method I use is:

I had no luck getting Jim Neath’s session fix working, so I put skip_before_filter :verify_authenticity_token in the Photos Controller. Bad? Yea, probably. I haven’t found a better way yet.

Add this code to app/views/galleries/edit.html.erb:

Which leads you to add the following partial: app/views/photos/_image.html.erb

We’ll worry about the destroy link later, let’s integrate swfupload. Download the latest copy of SWFUpload. Copy flash/swfupload.swf to public/flash (make directory first). Copy swfupload.js & upload.js (in Jim Neath’s demo app) to public/javascripts. Copy Jim Neath’s swfupload.css file to public/stylesheets. Copy Jim Neath’s images/icons folder to public/images.

Add this code to app/views/galleries/edit.html.erb:

Yep, a lot is going on there. Reload your galleries/edit page and see if it’s still working

Ok, so this gets you to a functioning online photo gallery. Up next will be adding user accounts, a shopping cart, ordering options, customers & paypal integration. Stay tuned!

For now, please find the source here: http://github.com/joemsak/proofs_package

And for help on your project, visit us at http://www.simplifyadvance.com

Using attachment_fu, following Mike Clark’s Tutorial for Uploading / Resizing images in Ruby on Rails, and Rmagick with ImageMagick, I was able to add Categories functionality with featured images.

I also used lightbox and Coda Slider for Admin & Home presentations, respectively.

Enjoy!

http://screencast.com/t/Jli6m3lzL

In this iteration I added drag and droppable table rows and a pricing table for the pricing page.

Since I haven’t figured out how to update the db with the new sort orders reflected after the drag & drop action, this is not considered iteration 2.

Enjoy:

http://screencast.com/t/9bBPFCF3xp

I can truly value Customer Collaboration over contract negotiation now.

Enjoy:

http://screencast.com/t/rGDhWbVru

Ruby on Rails is built on, emphasizes and aides developers in working according to the principles of the Agile Manifesto. I’ve never read anything more inspiring than those 12 principles. Rails has made it possible to skip functional specs, comprehensive documents and all the other garbage that stops us from delivering working software to our customers that gives them a competitive advantage.

Rails allows you to respond to change rather than try to avoid it. Face it: clients change their minds. They forget to tell you some detail until the last week of development. They decide they don’t like their original ideas and want to try something new. In order for them to remain competitive, we need to be able to adapt and respond to those changes. So if you can’t control clients and stop this from happening, why would you continue to beat the dead horse? You write pages and pages of functional specs, scope docs and project plans. But I’ve never seen a single project completed without a change to any of those. It just doesn’t happen. Rails makes it easy to work with change, rather than constantly trying to figure out how to avoid it (you can’t).

Rails makes it possible to work and grow in a dynamic and competitive world. As I learn more, I’ll post more. Until then, I suggest you try Rails and see for yourself how much better your work can be.

I’m proud of this, because I wrote the XHTML that’s been helpful in optimizing enlivensoftware.com for robots like googlebot to understand the site and return it high in the rankings for search results lists.

How did I do it?
 
Header tags, Title attributes and Cross-linking, oh my!

Use the proper hierarchy of Header tags in your code. On the home page, H1 belongs to your logo and company name. H2 belongs to the main headline of the page and maybe your company’s motto if you have one. H3 and H4 can be headers of sections, like News or Events.

On your subpages, make your logo/company name a regular anchor tag linking back to the home page. Now H1 goes to your page name and H2 becomes a sub-header for dividing content. H3 and H4 can still designate page sections. It helps if your H1 matches your Page Title

Then you should put titles on those tags and on your navigation menu links. Hell, you can even put titles on divs! These titles should differ from the text in the tag itself. For example, you could have a link named “Events” and its corresponding title could be “Calendar of Events at Company ABC”. This is cross-linking and keyword density rolled into one swift move without overloading the user with too much fluff in the words they see.

Also, a good friend of yours can be the ABBR tag. It’s the tag you use to define abbreviations. In a real-world example, here’s the code I used for the logo for the new MHSAA web site we’re working on:

<h1 id=”logo” title=”Michigan High School Athletic Association”><abbr title=”Michigan High School Athletic Association”>MHSAA</abbr></h1>

Now Google and other robots will know what MHSAA means. That should help in future searches. It also helps that their domain is mhsaa.com.< You can submit your sitemap to google and use webmaster tools and google analytics, as well.

So these are simple ways you as a programmer can help your company and clients succeed in SEO. Don’t forget that you should start with a kick-ass writer, too.

I just wanted to say I appreciate the feedback and I’m interested in the advancements and improvements being considered in upcoming versions of the platform. Thanks for putting up with my candor and overt angst in these past few bitch posts.

I’d be particularly interested in knowing about any plans to move forward with .Net 3.5 and its ability to allow designers to define all the HTML in the controls. I’d like to see DNN reach the point where all rendered HTML is controlled by the front-end engineer, and we can achieve W3C compliance and simpler control over themes and content generation.

The “default.css” included with all installs of DNN has this (and more CSS for other stuff like it) in it:

H1
{
font-family: Tahoma, Arial, Helvetica;
font-size: 20px;
font-weight: normal;
color: #666644;
}

H2
{
font-family: Tahoma, Arial, Helvetica;
font-size: 20px;
...

(I think you get the point)

Excuse me, DotNetNuke core team, but isn’t stuff like this up to the Designers and Developers? Why are you including a default stylesheet with definitions for HTML elements that would be used by Web developers? I can’t tell you how many times default.css has left me absolutely baffled about the smallest details not being quite right according to our design specs because it has these random “defaults” in it. It’s not up to DNN Core team to define my font families, sizes, and colors. And seriously, stop using pixel font sizing.

It’s becoming clearer to me almost on a daily basis, that DNN is not the right CMS for a professional Web shop to be using. They probably have this default.css for people who don’t make skins or know anything about Web development. And if you remove default.css, it completely hoses all the Admin pages and Control Panel. It takes way too much time and effort to figure out what’s removable and what’s not, and you always end up surprised when some random element isn’t positioned or styled correctly later on down the road.

It’s time for us to move on to a CMS that gives the developer full control over the theme, and not put a bunch of defaults in it that you can’t get rid of. 

1. Forced Registration to Download their Software
When you go to DNN’s web site and sister sites, like the new DNN Events site, the first thing you have to do before you can download anything is register an account. Now, it’s not all bad because it’s free and I guess they just want to track popularity (ever heard of Google Analytics?), but the registration process takes too long. I registered an account to download the new Events Module beta about 10 minutes ago and still haven’t received my “verify your account” email. Sorry, DNN team, I’ve now lost all interest in your beta.

Not only that, but it’s not clearly obvious you have to register. They bury the instruction to register in their rather long and boring content. If I go to wordpress or drupal’s site, I see big freakin links to download (no registration required of course). It wouldn’t be so bad if they had a big link that said “Register and Download” but no, of course they don’t.

Which leads to my next point,

2. They really don’t support or discuss usability and accessibility
DNN modules and the DNN platform itself are so hard to use. Their website is hard to navigate, most of the icons don’t make sense, and the forums are cluttered and don’t work in all browsers. You can’t make a post in their forums in Safari. Sorry, Safari users, outta luck. Get firefox, I guess. No one seriously talks about how to make the admin screens and layouts of their modules more functional, faster, and easier to understand.

Most of the modules we have to buy (another point) are riddled with awful and outdated front-end code, and have the absolute worst Admin screens.

3. You have to pay for most of the modules
Now this isn’t that bad. I mean, a software developer’s gotta make money, and some people run their business solely off of DNN modules, right? Ok, but step up your game and make a module worth paying for. Refer to point #2.

More later, I have to get back to work.

I googled and searched everywhere and couldn’t find a single solution. I couldn’t just reinstall MAMP because I had a client’s database on there that I couldn’t afford to lose.

Then it hit me… TIME MACHINE! I could just restore to yesterday at 4:30 (my last known working copy) and everything would be all set.

In 2 clicks and 3 minutes, I was back in business!