Many Web Applications these days consist of two main parts: the public facing front-end, and the private, secure administration area. When developing with Ruby on Rails, the convention is to try to write code as DRY (don't repeat yourself) as possible and use one single controller for both the public side and the administration side of the site. For certain circumstances this is fine, but I think there is some flexibility here, and recently I've noticed that many times the Admin logic is quite a bit different that the public facing functionality — enough so to warrant its own set of admin controllers and views.
With Rails 2.0+, you can use namespacing to keep the admin controller logic and views separate from the public controller logic and views. I've come to really like the way this helps to keep both sections of the site separate and organized.
I'll demonstrate a very simple example of a web app that provides a way for an Administrator to create, edit, and delete articles with one controller, and for a visitor to view those articles with a separate controller.
Create Your Controllers
After you've created your new rails app, we can proceed by generating our two controllers to access our articles:
# our private admin controller uses namespacing. Notice the Admin:: prefix ./script/generate controller Admin::Articles
# our public controller is created normally ./script/generate controller Articles
We now have two controllers named articles_controller.rb. The public controller lives in app/controllers/ and the private controller lives in app/controllers/admin/ with its respective views in app/views/admin/articles. Once you've created the necessary views, you should have a file structure similar to the image below. Our public controller only needs two methods at this point: 'index' and 'show', while our admin controller will require all 7 standard REST methods.
Create Your Routes
Before either of these controllers can function, we need to setup our routes in the config/routes.rb file.
map.namespace :admin do |admin| admin.resources :articles end map.resources :articles
Take a second and run rake routes on the command line to view all of your current routes. You'll notice you now have 2 sets of articles routes, one of which targets your admin controller, and one which targets your public controller.
Handling Links and Forms
So how does this change how links are handled in the views? It turns out it's not all that complicated thanks to Rails creating a set of admin specific URL generation methods:
# Create a link to the public article page '/articles/:id' <%= link_to 'View Article', article_url(@article) %> # Create a link to view the article in the Admin area '/admin/articles/:id' <%= link_to 'View Article', admin_article_url(@article) %> # Create a link to edit the article in the Admin area '/admin/articles/:id/edit' <%= link_to 'Edit Article', edit_admin_article_url(@article) %>
The same goes for using forms in the Admin area. Instead of using <% form_for(@article) do |f| %> you simply add in the admin namespace, and voila, your forms submit to the /admin/articles controller:
# Create a form that submits to the /admin/articles controller <% form_for([:admin, @article]) do |f| %> .... <% end %>
Securing and Styling Your Admin Controllers
You will no doubt want to secure all of your Admin controllers and require an Admin user to be logged in. If you use a plugin like the popular RESTUL Authentication, you can simply apply the before_filter :login_required to the top of each Admin controller.
Most of the time the Administration area is also styled differently than the public facing area of the site. Here we can simply put something like layout 'admin' at the top of our Admin controllers to use a separate admin.html.erb layout file instead of the public application.html.erb layout file.
class Admin::ArticlesController < ApplicationController before_filter :login_required layout 'admin' ... REST methods here ... end
Wrapping Things Up...
You should now have the beginnings of a web app with a set of self-contained, password-protected Admin CMS controllers prefixed with /admin, and a set publicly viewable front-end controllers. If you're feeling adventurous, you could even extract the controllers, views, routes, and stylesheets into a plugin or a generator if many of the CMS features will be used throughout a variety of different applications.
A long standing complaint among web designers is the lack of variety in typefaces that can be reliably used and guaranteed to display across all web browsers and operating systems. For the most part, designers are stuck with Arial, Verdana, Georgia, Times, or the standard serif and sans-serif implementations, though this list can be supplemented by expanding the font stack. Granted, the standard typefaces are optimized for web and will render well across the the board at various sizes, with anti-aliasing on or off, but occasionally designers need to spice things up with additional typefaces in an accessible, search-friendly manner without resorting to pre-rendered images. Two options currently exist to help remedy the situation: sIFR and Safari Embedded Fonts.
sIFR (Scalable Inman Flash Replacement)
sIFR has been available for a few years and has had a good reception across the web community. It was created as a way for designers to display any typeface on a web site without requiring the visitor to have that typeface previously installed. It uses a combination of Adobe Flash and Javascript to dynamically replace text, and is completely accessible and search engine friendly. The current stable build of sIFR is version 2, with version 3 currently in development, hopefully to be released in a stable form in the near future.
sIFR requires both Javascript to be turned on and the Flash plugin to be installed. If either of these requirements are not met, the default styles designated by the designer will be used and the visitor will never know the difference. However, the wide adoption of Flash and Javascript will ensure it works for most visitors. sIFR is best used in moderation with elements like headlines, rather than entire blocks of body text.
How to use it
After downloading sIFR, the first step is to open the sifr.fla in Adobe Flash, replace the typeface with one of your choosing, and export the file as a Flash movie. This is explained in more detail in the sIFR Documentation. Next, in the <head> of your HTML document, insert links to the sIFR CSS and Javascript files:
<head> ..... <link rel="stylesheet" href="sIFR-screen.css" type="text/css" media="screen" /> <link rel="stylesheet" href="sIFR-print.css" type="text/css" media="print" /> <script src="sifr.js" type="text/javascript"></script> <script src="sifr-addons.js" type="text/javascript"></script> ..... </head>
Before the the closing <body> tag of your HTML document, insert the Javascript to call the sIFR replacement methods on all the elements you want to transform:
.....
<script type="text/javascript">
if(typeof sIFR == "function"){
sIFR.replaceElement(named({sSelector:"body h1", sFlashSrc:"blackletter.swf", sColor:"#000000", sBgColor:"#dddddd", sFlashVars:"textalign=center"}));
sIFR.replaceElement(named({sSelector:"body h2", sFlashSrc:"blackletter.swf", sColor:"#000000", sBgColor:"#FFFFFF"}));
};
</script>
</body>
.....
The sIFR.replacementElement method takes a number of options such as color, background color, link and hover colors, padding, and several more as described in detail in the sIFR Documentation. You may have to play around with these options and tinker with your CSS to perfect your transformations.
You should see something like:
Pitfalls
sIFR does a good job of working across a variety of browsers and degrades rather gracefully when it can't be used. That said, there are a few issues that arise with its use. Occasionally sIFR can slow the rendering of a web site, and can also create a visible 'flash' as the text is replaced by Flash. Additionally, visitors won't be able to copy and paste a combination of sIFR text and normal HTML text.
Embedding Fonts with @font-face and Safari
With the recent release of Safari 3.1 from Apple comes the ability for a web designer to reliably display any TrueType font of their choosing on a web site without Flash or Javascript, allowing them to style it with CSS as they wish. Visitors' browsers will seamlessly download the typeface and render the design in all its glory as was intended by the designer. Surprisingly, Internet Explorer has actually supported font-face embedding since version 4, but unsurprisingly, Microsoft's implementation only works with a proprietary .EOT font format.
How to use it
Implementing the @font-face property is actually quite simple. It acts just like any other CSS selector as shown in the example code below. Define a name for your font-family and then provide an absolute or relative url() to the typeface file. The url() acts just like url() for background-image. Once you've defined the typeface, simply use the new font-family within any selector as you would normally.
@font-face {
font-family: "OldeEnglish";
src: url(OldeEnglish.ttf) format("truetype");
}
h1 { font-family: "OldeEnglish"; }
View the Example (works only in Safari 3.1+) »
You should see something like:
Pitfalls
One major downfall to using embedded typefaces is that the technique currently only works in Safari 3.1. However, other browsers will degrade gracefully and use the next font in the font stack. Unfortunately, a designer may be using different line-height, font-size, letter-spacing, or word-spacing specific custom typeface, making the next typeface in the stack unreadable. No word yet on whether future versions of Firefox, Internet Explorer, or Opera will join in the font embedding party, but a designer can hope.
Copyright issues also arise with @font-face. Quality typefaces from type foundries often cost hundreds to thousands of dollars and don't generally include licenses that allow for legal distribution to the public. Since the fonts used with @font-face are required to be publicly accessible, they could potentially be downloaded by any user who has a peek inside your stylesheet. There are many freely downloadable fonts available on the web, but a majority of those are rather low quality and should probably be avoided anyways.
With Great Power Comes Great Responsibility…
The two tools are a welcome addition to a designers arsenal, especially when it comes to web typography. However, these new tools do open the door for typeface abuse and potentially illegible, tacky designs. Unless that's specifically what you're going for, as a designer you should still use sound judgement and restraint. Just because you can, doesn't mean you should. With that said, go forth and experiment!
Helpful Resources & References
CATEGORIES
ARCHIVES
BOOKMARKED
