为了更好的描述我的意思，我说一件发生在我们第二堂导论课上的事。这节课用 OCaml 语言教，这是一种语法独特的函数式语言。他不得不听着这样让人不着头脑的话：“let rec fib n equals return match n with return pipe one hyphen greater than… semicolon semicolon”等等。并一度在一个不能编译的代码库的上工作。他一遍遍听着大声朗读的荒谬的语法，但是一切听起来都那么正常。直到他在课上想尽办法，一个视力正常的助教才指出，由于这样或那样的原因，屏幕阅读器把数字 “0” 读成了字母 “o” （即“哦”的声音）。而这只是一个全新的，视力正常的程序员无需处理的bug。
值得一提的是，他也对 HTML 辅助规范充满了热情，尤其是 ARIA。而互联网上的大多数网站完全忽略了这件事，尽管要实现它是多么的微不足道。对他而言，网站有与没有 ARIA 功能就像白天与黑夜的区别。
我个人使用的开发工具是 IDE 。而很多盲人朋友并不使用 IDE，最可能是因为 IDE 的界面对于我们的屏幕阅读器来说并不是完全的无障碍。我们的同行有一个问题就是太忙了以致于只照顾到了大多数人而忽视了少数人的声音。举个例子，Jetbrains IDE 的整个系列都不是无障碍的。而版本 IDEA-111425 才是为盲人和有视觉障碍的人准备的无障碍开发工具。
Travis CI makes working in a team for a software project easier with automated builds. These builds are triggered automatically when each developer checks in their code to the repository. In this article, we will go through how we can integrate Travis CI easily with our project, which is hosted on Github. With automation, notification and testing in place, we can focus on our coding and creating, while Travis CI does the hard work of continuous integration!
Hello Travis & CI!
Travis CI is a hosted continuous integration platform that is free for all open source projects hosted on Github. With just a file called .travis.yml containing some information about our project, we can trigger automated builds with every change to our code base in the master branch, other branches or even a pull request.
Before we get started with how we can integrate Travis with our project, the following prerequisites will be helpful:
At the heart of using Travis, is the concept of continuous integration (CI). Let’s say we are working on one feature and after we are done coding, we will typically build the project so as to create the executable as well as other files necessary to run the application. After the build is completed, good practices include running all the tests to ensure they are all passing and everything is working as expected.
The last step is ensuring that whatever we coded is indeed working even after we integrate it into the mainline code. At this point we build and test again. If the integrated build succeeds we can consider that the feature has been fully implemented. Travis CI automates this exact step of triggering a build and test upon each integration to the master branch, other branches or even a pull request, accelerating the time to detection of a potential integration bug.
In the following sections, we will take a simple project and trigger a failing build, correct it and then pass it. We will also see how Travis CI easily works with Github pull requests.
Travis Interface
When we land on the main homepage, we can also see the “busyness” of many open source projects going through automated build. Let’s deconstruct the interface and understand the various parts:
Sidebar: This shows the list of public open source projects on Github currently going through automated builds. Each item has the hyperlinked project name, duration of the build so far and the sequential number of build.
Build in progress [yellow]: A little yellow colored circle beside the project name indicates that the build is in progress.
Build failed [red]: A little red colored circle beside the project name indicates that the build is complete and it has failed.
Build passed [green]: A little green colored circle beside the project name indicates that the build is complete and it has passed.
Project name and links: The title is in the format username/repository and it is linked to the Travis CI build page. The little Octocat symbol beside it links to the Github page of the repository containing its source code.
Types of build: The automated builds can be triggered by committing the code to the master branch, other branches or even a pull request. By visiting the individual tab, we can get more information about the builds.
Build activity: This section will include information about each of the tasks that the build is running.
Step 1: Hello World!
Before we integrate Travis CI, we will create a simple “hello world” project and create some build tasks. Travis supports various programming languages including Python, Ruby, PHP and JavaScript with NodeJS. For the purpose of our demo, we will use NodeJS. Let’s create a very simple file hello.js as defined on the main website of NodeJS:
var http = require('http');
http.createServer(function (req, res) {
res.writeHead(200, {'Content-Type': 'text/plain'});
res.end('Hello World\n') // missing semi-colon will fail the build
}).listen(1337, '127.0.0.1');
console.log('Server running at http://127.0.0.1:1337/');
Do notice that there is a missing semi-colon so that later on JSHint, a JavaScript linter will be able to detect this and raise an error. We will build the project using a task runner called GruntJS that will include JSHint. This is of course an illustration, but in real projects, we can go on to include various testing, publishing, linting and hinting tasks.
To indicate the various packages required for GruntJS, JSHint and others, we will create a second file called package.json. This file will firstly contain the name and the version number of our simple application. Next, we will define the dependencies needed with devDependencies which will include GruntJS related packages including JSHint. With scripts, we will tell Travis CI to start running the test suite and the command grunt --verbose. Let’s see the full contents of the file: package.json:
Next, let’s prepare the Gruntfile.js that will include all the tasks required to run our build. For simplicity, we can include just one task – JavaScript linting with JSHint.
Finally, we will run the build that contains only one task after we download all the related packages with npm install:
$ npm install
$ grunt
As expected, the build will not pass because the JSHint will detect a missing semi-colon. But if we place the semi-colon back into the hello.js file and run the grunt command once again, we will see that the build will pass.
Now that we have created a simple project locally, we will push this project to our Github account and integrate Travis CI to trigger the build automatically.
Step 2: Hello World With Travis CI
The very first step in integrating Travis CI is to create a file called .travis.yml which will contain the essential information about the environment and configurations for the build to run. For simplicity, we will just include the programming environment and the version. In our simple project, it is NodeJS version 0.10. The final contents of the file .travis.yml will be as follows:
language: node_js
node_js:
- "0.10"
Now our project will consist of the following files along with README.md and .gitignore as required:
Next, log in to Travis CI and authorize Travis CI to access your Github account. Afterwards, visit your profile page to turn on the hook for the Github repository to trigger automated builds with Travis CI.
As a final step to trigger our very first build, we will need to push to Github. Let’s remove the semi-colon in the file hello.js to make a failing build and then push to Github. This will trigger the automated build in Travis CI. Let’s visit the URL: https://travis-ci.org/[username]/[repo] to see the first build in progress!
This failing build in the above example is really a simple illustration. But this situation is reflective of something that might happen in our real projects – we try to integrate our code and the automated build fails. By default, after each build is completed, Travis CI will send emails to the commit author and repository owner. In this way, the developer that pushed the code is immediately alerted and can then fix the integration errors. In our case, let’s just insert the missing semi-colon and push to Github one more time.
git add hello.js
git commit -m "added semi-colon to pass the build"
git push
Hurray! The automated build has passed this time. Our code is integrated passing all the required tests. Now each time we try to integrate our changes whether it is to the master branch or even other branches, Travis CI will trigger an automated build.
Pull Requests
Once we have integrated Travis CI into our project, a pull request will also trigger an automated build. This is immensely useful for the repository owner or the developer who is in charge of merging the code base. Let’s see how Travis CI will advise whether the pull request is good to merge or not.
First, using another Github account, let’s fork the original repository and pull request with the following steps:
Fork the original repository
Create a new branch in the forked repository
Make the new changes and commit it
Ensure the feature branch is chosen
Compare and pull request
Merge With Caution
To simulate a failing build in the pull request, we will once again remove the semi-colon in the file hello.js, commit and push the changes and finally pull request.
Upon each pull request, Travis CI will automatically trigger the build. This time, we can also visit the “Pull Requests” tab to see the history of current or past builds triggered due to a pull request.
After Travis CI completes the build, if we visit the pull request page from the original repository, we will see that Travis CI has appended some user-interface changes to alert us that the build has failed.
Good to Merge
This failing build status will be immediately notified to the repository owner as well as the developer who did the pull request. And now, depending on the reason for the failing build, it can be rectified with another commit in the same branch. Hence, let’s add on the semi-colon and pull request one last time. Github will automatically update the pull request page as well.
And finally, when we come back to the original repository’s pull request page, this time we will see a “green” signal to go ahead and do a merge as our build is passing!
Build Configurations
The file .travis.yml defines the build configurations. Our example included just the language type and version, but we can add-on more useful ones as follows:
Notifications in terms of emails or chat alerts are sent as declared by the build configurations. This is an example of turning off emails and sending it to IRC:
As you can see, the file .travis.yml becomes very important in triggering automated builds. If this file in not valid, Travis CI will not trigger the build upon each push to Github. Hence, ensuring that we have a valid file that Travis CI will interpret correctly is important. For this, we will install a gem called travis-lint and run the file .travis.yml
It’s really helpful to include a little image to indicate the current status of the build. The image itself can be accessed from the URL pattern http://travis-ci.org/[username]/[repository-name].png. Another way to quickly access the images embedded in various formats is on the Travis CI project page itself. For example, we can copy the Markdown format and embed in the project’s README.md file.
Another cool way to track the build statuses of various open source projects while surfing around Github is to install one of the browser extensions. This will put the build status images prominently right next to each of the project names.
Resources on Travis CI
Here are some resources on the concept of continuous integration as well as learning and integrating Travis CI into our Github projects:
A fantastic way to learn what and how to include the various build configurations in the .travis.yml file is to actually browse through many of the popular open source repositories that already integrate Travis CI. Here are a few:
I hope this gave you a brief introduction to how we can easily integrate Travis CI in our Github projects. It’s really easy to use, so give it a try and make continuous integration a breeze for your team!
The <table> element in HTML is used for displaying tabular data. You can think of it as a way to describe and display data that would make sense in spreadsheet software. Essentially: columns and rows. In this article we're going to look at how to use them, when to use them, and everything else you need to know.
It is data that is useful across multiple axis. Imagine running your finger across a row (horizontal) to see a single person and relevant information about them. Or up and down a column (vertical) to get a sense of the variety or pattern of data on that point.
Head and Body
One thing we didn't do in the very basic example above is semantically indicate that the first row was the header of the table. We probably should have. That entire first row contains no data, it is simply the titles of columns. We can do that with the <thead> element, which would wrap the first <tr> (it could wrap as many rows as needed that are all header information).
When you use <thead>, there must be no <tr> that is a direct child of <table>. All rows must be within either the <thead>, <tbody>, or <tfoot>. Notice that we also wrapped all the rows of data in <tbody> here.
Foot
Along with <thead> and <tbody> there is <tfoot> for wrapping table rows that indicate the footer of the table. Like <thead>, best for semantically indicating these are not data rows but ancillary information.
What is unique about <tfoot> is the placement in the HTML. It comes after <thead> and before <tbody>! You might think it would be the last thing before the end of <table>, but not so in this case. I believe this is an accessibility concern, as the footer may contain information necessary to understand the table, it should be before the data in the source order.
Despite coming first in the source order, <tfoot> does indeed render at the bottom of the table, making it a rather unusual HTML element.
It can be used, for example, to repeat the header in the case of a visually very tall/long table where it may be easier to see the column titles at the bottom than the top. Although you don't necessarily need to use it that way.
<tfoot> is just begging for clever tricks with layout where the position of elements jumps around from bottom to top depending on needs. For instance a nav bar along the bottom of a screen, but with the HTML source toward the beginning where navigation should be.
The Cells: td and th
The individual cells of a table are always one of two elements: <td> or <th>. You can put whatever you want inside a table cell, but these are the elements that make them a table cell. <th> elements are "tabular headers" and <td> elements are "tabular data".
Using our existing simple demo, the top row is all headers. Not data, just titles for the data. All the rest of the rows are data. So:
<th> elements are not necessarily limited to being within the <thead>. They simply indicate header information. So they could be used, for instance, at the start of a row in the <tbody>, if that was relevant. We'll cover a case like that later.
Basic Styling
Most tables you will ever see use colors and lines to distinguish different parts of the table. Borders are very common. By default, all table cells are spacing out from one another by 2px (via the user-agent stylesheet), like this:
Notice the slight extra gap between the first row and the rest. That is caused by the default border-spacing being applied to the <thead> and <tbody> pushing them apart a bit extra. This isn't margins, they don't collapse. You can control that spacing like:
table {
border-spacing: 0.5rem;
}
But far more common is to remove that space. That property is completely ignored and the space collapsed if you do:
table {
border-collapse: collapse;
}
Just a little padding, borders, and making those <th> elements be left-aligned goes a long way to make for a simple, styled table:
There are two important attributes that can go on any table cell element (<th> or <td>): colspan and rowspan. They accept any positive integer 2 or larger. If a td has a colspan of 2 (i.e. <td colspan="2">) it will still be a single cell, but it will take up the space of two cells in a row horizontally. Likewise with rowspan, but vertically.
You'll have to do a bit of mental math everything you start working with connected cells. Colspan is fairly easy. Any table cell is "worth" one, unless it has a colspan attribute and then it's worth that many. Add up the values for each table cell in that table row to get the final value. Each row should have exactly that value, or else you'll get an awkward table layout that doesn't make a rectangle (the longest row will stick out).
Rowspan is similar, it's just a little harder and more of a mental leap, because columns aren't grouped like rows are. If a table element has a rowspan attribute, it spans across two rows vertically. That means the row below it gets +1 to it's table cell count, and needs one less table cell to complete the row.
It can be awkward to work out in your head, but we're developers here, we can do it =).
Often these attributes are used in really simple ways like connecting a few related table headers:
As Wide As They Need To Be... Or fill the container... Or beyond
The table element itself is unusual in how wide it is. It behaves like a block-level element (e.g. <div>) in that if you put one table after another, each will break down onto its own line. But the actual width of the table is only as wide as it needs to be.
If the amount of text in the tables widest row only happens to be 100px wide, the table will be 100px wide. If the amount of text (if put on one line) would be wider than the container, it will wrap.
However if text is told to not wrap (i.e. white-space: nowrap;) the table is happy to bust out of the container and go wider. Table cells will also not wrap, so if there are too many to fit, the table will also go wider.
I might skip a <thead> in this situation even though that first row is all header. It's just no more important than the vertical column of headers so it feels weird to group that top row alone. Just make on row of all <th> and then each subsequent row with the first cell only as <th>.
When To Use Tables
It's a good time to take a break and discuss the when of tables. Perhaps you've heard the generic advice: tables are for tabular data (see the first sentence of this blog post). The "would this make sense in a spreadsheet?" test is usually appropriate.
What kinds of things are appropriate in tables? Here are some: a plan/pricing/features comparison, bowling scores, an internal grid of employee data, financial data, a calendar, the nutrition facts information panel, a logic puzzle solver, etc.
You might occasionally hear: tables are unsemantic. That's not true - they semantically indicate tabular data. Tables are the right choice when that is the case.
When NOT To Use Tables
An inappropriate use for tables is for layout. That may seem counter-intuitive. At a glance at how tables work may make them seem ideal for layout. Easy to control, extremely logical, predictable, and not-at-all fragile.
There are some significant problems with using tables for layout though. First, HTML tags mean things. As we covered, table elements semantically describe tabular data. Using them for anything else is a breach of semantic duty. You aren't going to get a fine in the mail, but you aren't getting as much value from your HTML as you could.
Talking about semantics is a little difficult sometimes (some reads: 1, 2, 3, 4, 5), so let's talk about something we all generally agree on (even if we aren't as good as it as we want to be): websites should be accessible. One part of accessibility is screen readers. Screen readers read tables from top to bottom, left to right. That means the order of how your site is presented is dictated by the table structure, which is dictated by visual choices not accessibility choices. Not to mention a screen reader may even announce the start of tabular data which would be worse than useless.
Speaking of source order, that affects more than accessibility. Imagine a "sidebar on the left" layout. A table would dictate that table comes first in the source order, which while also being bad for accessibility, is likely bad for SEO as well, potentially valuing your ancillary content above primary content.
Could you fix the SEO issues by using semantic tags within the table tags? Possibly somewhat, but now you're using double the HTML. If you really need the layout abilities of a table but want to use semantic tags, see the next section. If you are somehow absolutely stuck using table tags for layout, use the ARIA role="presentation" on the table to indicate it as such.
As I write this in the latter half of 2013, tables have become far less prevalent and even appealing as a layout choice. We're seeing a lot more use of fixed and absolute positioning which you cannot do inside a table. We're seeing flexbox being awesome and being right on the edge of mainstream usability. We're seeing grid layout starting to grow up. We're seeing inline-block be used powerfully. We're seeing the fragility of floats in the olden days fade away.
Rarely do you see modern websites touch tables for layout. The last holdout is HTML emails. The landscape of what renders emails is super wide. It is everything we deal with on the web, plus the world of native apps on both mobile and desktop on operating systems new and ancient. You can do some progressive enhancement for emails, but the layout itself is still generally regarded as being safest done in tables. That is substantiated by the fact that the major email sending services still all offer templates as tables.
Making Semantic Elements Behave Like a Table
CSS has properties to make any element you wish behave as if it was a table element. You'll need to structure them essentially as you would a table, and it will be subject to the same source-order-dependency as a table, but you can do it. I'm not crapping on it either, it's genuinely useful sometimes. If that layout style solves a problem and has no negative order implications, use it.
Don't use inline styles, but just for understanding here's how that would go:
A handy trick here is that you don't even need the table-row element in there if you don't want. A bunch of display: table-cell; elements that are children of a display: table; element will behave like they are all in one row.
You always alter the display property of the element to get the table-style behavior. Here's the values:
Notice there is no <th> alternative. That is for semantic value only. It otherwise behaves just like a <td>, so, no need to replicate it in CSS.
There is also display: inline-table; which is pretty interesting. Remember we talked about how weird table elements widths are above. They are only as wide as they need to be, yet break onto new lines. It's almost like they are inline-block elements which happen to break. This makes them literally like inline-block elements, without the breaking.
I've never been a huge fan of that title as it suggests that using this table style layout is the right way and any other layout technique you use is the wrong way. But as I've said, this can be tremendously useful and I'm glad it's in CSS. Just be acutely aware that no matter what kind of elements you use to create a table-based layout, it still subject to the same problems (largely source order dependency).
All Table Related Elements
There is a few elements above we haven't touched on yet. Let's look at all the HTML table related elements. You know what, we might as well use a table to do it:
Element
What it is
<table>
The table itself
<caption>
The caption for the table. Like a figcaption to a figure.
<thead>
The table header
<tbody>
The table body
<tfoot>
The table footer
<tr>
A table row
<th>
A table cell that is a header
<td>
A table cell that is data
<col>
A column (a no-content element)
<colgroup>
A group of columns
All Table Related Attributes
There are suprisingly few attributes that are specific to tables. Of course you can use class and ID and all the typical global attributes. There used to be quite a few, but most of them were specific to styling and thus deprecated (as that is CSS's job).
Attribute
Element(s) Found On
What it does
colspan
th, td
extends a cell to be as wide as 2 or more cells
rowspan
th, td
extends a cell to be as tall as 2 or more cells
span
col
Makes the column apply to more to 2 or more columns
sortable
table
Indicates the table should allow sorting
headers
td
space-separated string corresponding to ID's of the <th> elements relevant to the data
scope
th
row | col | rowgroup | colgroup (default) - essentially specifies the axis of the header. The default is that a header is heading a column, which is typical, but a row might start with a header also, where you would scope that header to the row or rowgroup.
Deprecated Attributes
Don't use any of these. The are deprecated. While they may work in some browsers today, there is a chance they stop working in the future.
Deprecated Attribute
What to use instead
align
Use float property instead
valign
Use vertical-align property instead
char
The correct answer is to use text-align: "x"; where x is the character to align on, but it's not implemented anywhere yet. But this attribute isn't supported either, so no big loss.
charoff
See above
bgcolor
Use background property instead
abbr
"consider starting the cell content by an independent abbreviated content itself or use the abbreviated content as the cell content and use the long content as the description of the cell by putting it in the title attribute"
axis
Use the scope attribute instead
border
Use border property instead
cellpadding
Using padding property instead
cellspacing
Use border-spacing property instead
frame
Use border property instead
rules
User border property instead
summary
Use <caption> element instead
width
Use width property instead
The Table Stack
There is an implied vertical stacking of table elements, just like there is in any HTML parent > descendent scenario. It is important to understand in tables because it can be particularly tempting to apply things like backgrounds to the table itself or table rows, only to have the background on a table cell "override" it (it is actually just sitting on top).
Here's how that looks (using Firefox 3D feature in its dev tools):
Important Style Rules for Tables
You can use most CSS properties on table elements. font-family works on tables just like it does on any other element, for example. And the rules of cascade apply. Apply font-family to the table, but a different font-family on the table cell, the table cell wins because that is the actual element with the text inside.
These properties are either unique to table elements or they behave uniquely on table elements.
CSS Property
Possible values
What it does
vertical-align
baseline
sub
super
text-top
text-bottom
middle
top
bottom
%
length
Aligns the content inside a cell. Works particularly well in tables, although only the top/bottom/middle make much sense in that context.
white-space
normal
pre
nowrap
pre-wrap
pre-line
Controls how text wraps in a cell. Some data may need to be all on one line to make sense.
border-collapse
collapse
separate
Applied to the table to determine if borders collapse into themselves (sort of like margin collapsing only bi-directional) or not.
border-spacing
length
If border-collapse is separate, you can specify how far cells should be spaced out from each other. Modern version of cellspacing attribute. And speaking of that, padding is the modern version of the cellpadding attribute.
width
length
Width works on table cells just about how you would think it does, except when there is some kind of conflict. For instance if you tell the table itself to be 400px wide then the first cell of a three-cell row to be 100px wide and leave the others alone, that first cell will be 100px wide and the other two will split up the remaining space. But if you tell all three of them to be 10000px wide, the table will still be 400px and it will just give each of them a third of the space. That's assuming white-space or elements like an image don't come into play. This is probably a whole post in itself!
border
length
Border works on any of the table elements and just about how you would expect. The quirks come in when you collapse the borders. In this case all table cells will have only one border width between them, rather than the two you would expect them to have (border-right on the first cell and border-left on the next cell). In order to remove a border in a collapsed environment, both cells need to "agree" to remove it. Like td:nth-child(2) { border-right: 0; } td:nth-child(3) { border-left: 0; } Otherwise, source order/specificity wins which border is shown on which edge.
table-layout
auto
fixed
auto is the default. The width of the table and its cells depends on the content inside. If you change this to fixed, the table and column widths are set by the widths of table and col elements or by the width of the first row of cells. Cells in subsequent rows do not affect column widths, which can speed up rendering. If content in subsequent cells can't fit, the overflow property determines what happens.
This list isn't exhaustive. There are other CSS quirks that are relevant to tables. For instance, you can't relatively position a table cell in which to either nudge it around or absolutely position things within it. There are ways though.
If you can think of more CSS weirdness with tables, share in the comments below.
I inspected each element in Chrome Dev Tools too, which is now on Blink, and it's still the same.
It's funny though. For sure, the text in <th>s is centered (text-align: center;) by default. But that's not in the UA stylesheet. Not a huge deal but rather mysterious and makes you wonder what other mysterious things happen in rendering.
The UA stylesheet for tables differs from browser to browser. For example, in Firefox (here's 3.6's UA Stylesheet, but this is true in v23 too) table cells have this:
Most notably, 1px of padding that WebKit doesn't have. Not a huge deal in most cases, surely, but it is different. That's what CSS resets (and related projects) are all about: removing the differences. So let's check those out.
Resetting Default Table Styles
The most popular CSS reset in the world, the Meyer Reset, does this to tables:
There is an alternative to CSS resets though, Normalize.css. The philosophy is slightly different. Rather than zero out all styles, it specifically sets known-to-be inconsistent styles to a reasonable default. My general advice on using Normalize.css is: don't remove anything from it. If it's in there, it needs to be for consistency. But feel free to change anything in there.
I'll have to dig into the reasoning here a little deeper because it seems unusual...
I'm a fan of border-collapse: collapse because spacing between cells is usually way awkward, but, the default in every browser I know of is border-collapse: separate; so isn't in need of normalization.
If border-collapse is collapse, border-spacing doesn't matter.
Table cell elements are in need of normalization (e.g. Firefox padding difference) but that isn't there.
Not a hugely big deal.
This is the kind of thing I would probably normally do:
This may be weird to look at, but it's valid. What's going on here?
The <col> tag is just one of those no-content elements that doesn't ever need a closing tag. Like <br> / <br />
The <td> element doesn't need to be closed in certain circumstances: "The end tag may be omitted, if it is immediately followed by a <th> or <td> element or if there are no more data in its parent element."
The missing closing </tr> tag is the same story: "The end tag may be omitted if the <tr> element is immediately followed by a <tr> element, or if the parent table group (<thead>, <tbody> or <tfoot>) element doesn't have any more content."
If we inspect the rendered table in the browser, we can see that the tags that were missing their closing tags are shown with closing tags. Those are automatically added for us. But there are also some brand new elements in there:
One thing to notice is the <col> is wrapped within a <colgroup> automatically. Even if we were to do:
You would think the second cell would be red, not the first, because the "first" colgroup only affects the second cell. But when rendered, both of those columns get wrapped in a colgroup, so the CSS selector will select the first one.
The <tbody> element is also implied. If you don't use any of tbody, thead, or tfoot, the whole guts of the table will be wrapped in tbody. If you use a thead, the whole table will be wrapped in that until it find a tbody, then it will auto-close the thead if you don't, and wrap the rest in tbody (also optional to close). If if finds a tfoot, you can imagine what happens (although remember tfoot should come before tbody).
You can actually use these elements in CSS selectors even though you didn't put them in your actual HTML. I probably wouldn't advise it just because that's weird, confusing, and styling tag selectors usually isn't advisable anyway.
Making a Table Not a Table
A situation may arise someday where you need to force a table element to not exhibit its table-style layout behavior and behave more like a regular element.
The trick is essentially to reset the display property of the table cells:
This is primarily useful in responsive design where the traditional table layout makes sense on large screens but needs significant shifts to make sense on smaller screens. There is a whole section on that below.
Table Accessibility
We already talked about the problems with using tables for layout and accessibility. But assuming table is being correctly used for tabular data, there are still quite a few accessibility concerns.
If you don't set a background-color on the table cell elements, you can set them on the table rows themselves. So at the most basic, you can do:
tbody tr:nth-child(odd) {
background: #eee;
}
We're using the tbody in the selector because it's unlikely you'd want to stripe header and footer rows. Set the even rows as well if you want to be specific about it instead of let what is underneath show through.
If you need to support browsers that don't understand :nth-child() (pretty damn old) you could use jQuery to do it.
Highlighting a column is a bit trickier. One possibility is to use the <col> element, which does allow us to set styles for cells that appear in that column. It's weird to wrap your head around, because the cells that are affected by <col> aren't actually descendants of it. The browser just kinda knows what you mean.
A table with four columns in each row would have four <col> elements:
However this is rarely useful. If you set the background of a row element or table cell element, that will always beat a background of a column element. Regardless of specificity.
You're probably better off setting a class name on each individual table cell element that happens to match that column position in the row. Like:
If you do set a background on the table cells, you can always just to tr:hover td, tr:hover th { } so still pretty easy.
Column highlighting is tricker. You can't use col:hover because those columns aren't actual elements that take up pixel space on the screen that you could hover over. The only option is JavaScript.
I wrote it up in Vanilla JavaScript here, just for fun:
Bind a mouseover and mouseout event to all those cells
When the mouseover event fires, get the position in the row of that cell
Loop through all rows and add a highlighting class to each cell in that row that matches that position
When the mouseout event fires, remove the highlighting class from all cells
And here I've combined both row and column highlighting. I used jQuery to make it all 12 lines of code (the raw JavaScript was getting pretty exhausting).
When the table is hovered, only the current row highlighted stays dark text, the others fade back. Also note on this one: the roundered corners on the table itself are only possible while you have border-collapse: separate;
Where table sorting can be quite complicated, table search can be quite easy. Add a search input, and if the value in there matches text anywhere in a row, show it, and hide the others. With jQuery that might be as easy as:
The most modern way of handling fixed headers is position: sticky; Here's an article on that. I'm honestly not quite sure the recommended way to use it with tables though. It doesn't work on <thead> under normal circumstances. That kinda makes sense because you can't absolutely position table innards. But it does work on <th>. Anyway if someone wants to figure that out, that'd be a good update to this article (or something).
Here's a live demo of a jQuery plugin that does the trick. I'd probably go for something like this these days until sticky shakes out more.
Emmet is a great tool for a bunch of reasons. One of which is writing HTML abbreviations and having them expand out into real HTML. Since tables are so repetitive and verbose, Emmet is perfect for them. Emmet works on CodePen too =)
JavaScript provides some very specific methods for dealing with tables through the HTMLTableElement API. Louis Lazaris wrote a little about it recently. You can use it to create tables with JavaScript, access sub-elements, and change properties in very specific ways. Here's the MDN page with the scoop.
Imagine a table with two columns. One for Employee ID's and another for Employee Email Address. There are headers for each column. It would be handy to be able to click those headers and sort the table by the data inside. For instance, numerical order, alternating between ascending and descending, for the ID's and alphabetical for the email addresses. That's what table sorting is all about. Making the data more useful.
This is such a common and generic need, that there is actually specification ready for it. Just put the sortable attribute on the table and it will automatically do it as long as you follow a couple of rules laid out in the spec.
At the time of this writing, I don't know of any browsers supporting table sorting natively. But there are lots of third-party options!
And those are all JavaScript solutions. It's certainly possible to sort data on the back-end and display the table already sorted in the HTML. That might be required in the case of paginated tables where all the data isn't available right in the DOM.
In this article we’ll be building a complete website with a front-facing client side, as well as a control panel for managing the site’s content. As you may guess, the final working version of the application contains a lot of different files. I wrote this tutorial step by step, following the development process, but I didn’t include every single file, as that would make this a very long and boring read. However, the source code is available on GitHub and I strongly recommend that you take a look.
Introduction
Express is one of the best frameworks for Node. It has great support and a bunch of helpful features. There are a lot of great articles out there, which cover all of the basics. However, this time I want to dig in a little bit deeper and share my workflow for creating a complete website. In general, this article is not only for Express, but for using it in combination with some other great tools that are available for Node developers.
I assume that you are familiar with Nodejs, have it installed on your system, and that you have probably built some applications with it already.
At the heart of Express is Connect. This is a middleware framework, which comes with a lot of useful stuff. If you’re wondering what exactly a middleware is, here is a quick example:
var connect = require('connect'),
http = require('http');
var app = connect()
.use(function(req, res, next) {
console.log("That's my first middleware");
next();
})
.use(function(req, res, next) {
console.log("That's my second middleware");
next();
})
.use(function(req, res, next) {
console.log("end");
res.end("hello world");
});
http.createServer(app).listen(3000);
Middleware is basically a function which accepts request and response objects and a next function. Each middleware can decide to respond by using a response object or pass the flow to the next function by calling the next callback. In the example above, if you remove the next() method call in the second middleware, the hello world string will never be sent to the browser. In general, that’s how Express works. There are some predefined middlewares, which of course, save you a lot of time. Like for example, Body parser which parses request bodies and supports application/json, application/x-www-form-urlencoded, and multipart/form-data. Or the Cookie parser, which parses cookie headers and populates req.cookies with an object keyed by the cookie’s name.
Express actually wraps Connect and adds some new functionality around it. Like for example, routing logic, which makes the process much smoother. Here’s an example of handling a GET request:
app.get('/hello.txt', function(req, res){
var body = 'Hello World';
res.setHeader('Content-Type', 'text/plain');
res.setHeader('Content-Length', body.length);
res.end(body);
});
Setup
There are two ways to setup Express. The first one is by placing it in your package.json file and running npm install (there’s a joke that npm means no problem man :)).
The framework’s code will be placed in node_modules and you will be able to create an instance of it. However, I prefer an alternative option, by using the command line tool. Just install Express globally with npm install -g express. By doing this, you now have a brand new CLI instrument. For example if you run:
express --sessions --css less --hogan app
Express will create an application skeleton with a few things already configured for you. Here are the usage options for the express(1) command:
Usage: express [options]
Options:
-h, --help output usage information
-V, --version output the version number
-s, --sessions add session support
-e, --ejs add ejs engine support (defaults to jade)
-J, --jshtml add jshtml engine support (defaults to jade)
-H, --hogan add hogan.js engine support
-c, --css add stylesheet support (less|stylus) (defaults to plain css)
-f, --force force on non-empty directory
As you can see, there are just a few options available, but for me they are enough. Normally I’m using less as the CSS preprocessor and hogan as the templating engine. In this example, we will also need session support, so the --sessions argument solves that problem. When the above command finishes, our project looks like the following:
If you check out the package.json file, you will see that all the dependencies which we need are added here. Although they haven’t been installed yet. To do so, just run npm install and then a node_modules folder will pop up.
I realize that the above approach is not always appropriate. You may want to place your route handlers in another directory or something something similar. But, as you’ll see in the next few chapters, I’ll make changes to the already generated structure, which is pretty easy to do. So you should just think of the express(1) command as a boilerplate generator.
FastDelivery
For this tutorial, I designed a simple website of a fake company named FastDelivery. Here’s a screenshot of the complete design:
At the end of this tutorial, we will have a complete web application, with a working control panel. The idea is to manage every part of the site in separate restricted areas. The layout was created in Photoshop and sliced to CSS(less) and HTML(hogan) files. Now, I’m not going to be covering the slicing process, because it’s not the subject of this article, but if you have any questions regarding this, don’t hesitate to ask. After the slicing, we have the following files and app structure:
/public
/images (there are several images exported from Photoshop)
/javascripts
/stylesheets
/home.less
/inner.less
/style.css
/style.less (imports home.less and inner.less)
/routes
/index.js
/views
/index.hjs (home page)
/inner.hjs (template for every other page of the site)
/app.js
/package.json
Here is a list of the site’s elements that we are going to administrate:
Home (the banner in the middle – title and text)
Blog (adding, removing and editing of articles)
Services page
Careers page
Contacts page
Configuration
There are a few things that we have to do before we can start the real implementation. The configuration setup is one of them. Let’s imagine that our little site should be deployed to three different places – a local server, a staging server and a production server. Of course the settings for every environment are different and we should implement a mechanism which is flexible enough. As you know, every node script is run as a console program. So, we can easily send command line arguments which will define the current environment. I wrapped that part in a separate module in order to write a test for it later. Here is the /config/index.js file:
There are only two settings (for now) – mode and port. As you may guess, the application uses different ports for the different servers. That’s why we have to update the entry point of the site, in app.js.
...
var config = require('./config')();
...
http.createServer(app).listen(config.port, function(){
console.log('Express server listening on port ' + config.port);
});
To switch between the configurations, just add the environment at the end. For example:
node app.js staging
Will produce:
Express server listening on port 4000
Now we have all our settings in one place and they are easily manageable.
Tests
I’m a big fan of TDD. I’ll try to cover all the base classes used in this article. Of course, having tests for absolutely everything will make this writing too long, but in general, that’s how you should proceed when creating your own apps. One of my favorite frameworks for testing is jasmine. Of course it’s available in the npm registry:
npm install -g jasmine-node
Let’s create a tests directory which will hold our tests. The first thing that we are going to check is our configuration setup. The spec files must end with .spec.js, so the file should be called config.spec.js.
describe("Configuration setup", function() {
it("should load local configurations", function(next) {
var config = require('../config')();
expect(config.mode).toBe('local');
next();
});
it("should load staging configurations", function(next) {
var config = require('../config')('staging');
expect(config.mode).toBe('staging');
next();
});
it("should load production configurations", function(next) {
var config = require('../config')('production');
expect(config.mode).toBe('production');
next();
});
});
Run jasmine-node ./tests and you should see the following:
This time, I wrote the implementation first and the test second. That’s not exactly the TDD way of doing things, but over the next few chapters I’ll do the opposite.
I strongly recommend spending a good amount of time writing tests. There is nothing better than a fully tested application.
A couple of years ago I realized something very important, which may help you to produce better programs. Each time you start writing a new class, a new module, or just a new piece of logic, ask yourself:
How can I test this?
The answer to this question will help you to code much more efficiently, create better APIs, and put everything into nicely separated blocks. You can’t write tests for spaghetti code. For example, in the configuration file above (/config/index.js) I added the possibility to send the mode in the module’s constructor. You may wonder, why do I do that when the main idea is to get the mode from the command line arguments? It’s simple … because I needed to test it. Let’s imagine that one month later I need to check something in a production configuration, but the node script is run with a staging parameter. I won’t be able to make this change without that little improvement. That one previous little step now actually prevents problems in the future.
Database
Since we are building a dynamic website, we need a database to store our data in. I chose to use mongodb for this tutorial. Mongo is a NoSQL document database. The installation instructions can be found here and because I’m a Windows user, I followed the Windows installation instead. Once you finish with the installation, run the MongoDB daemon, which by default listens on port 27017. So, in theory, we should be able to connect to this port and communicate with the mongodb server. To do this from a node script, we need a mongodb module/driver. If you downloaded the source files for this tutorial, the module is already added in the package.json file. If not, just add "mongodb": "1.3.10" to your dependencies and run npm install.
Next, we are going to write a test, which checks if there is a mongodb server running. /tests/mongodb.spec.js file:
describe("MongoDB", function() {
it("is there a server running", function(next) {
var MongoClient = require('mongodb').MongoClient;
MongoClient.connect('mongodb://127.0.0.1:27017/fastdelivery', function(err, db) {
expect(err).toBe(null);
next();
});
});
});
The callback in the .connect method of the mongodb client receives a db object. We will use it later to manage our data, which means that we need access to it inside our models. It’s not a good idea to create a new MongoClient object every time when we have to make a request to the database. That’s why I moved the running of the express server inside the callback of the connect function:
MongoClient.connect('mongodb://127.0.0.1:27017/fastdelivery', function(err, db) {
if(err) {
console.log('Sorry, there is no mongo db server running.');
} else {
var attachDB = function(req, res, next) {
req.db = db;
next();
};
http.createServer(app).listen(config.port, function(){
console.log('Express server listening on port ' + config.port);
});
}
});
Even better, since we have a configuration setup, it would be a good idea to place the mongodb host and port in there and then change the connect URL to:
Pay close attention to the middleware: attachDB, which I added just before the call to the http.createServer function. Thanks to this little addition, we will populate a .db property of the request object. The good news is that we can attach several functions during the route definition. For example:
So with that, Express calls attachDB beforehand to reach our route handler. Once this happens, the request object will have the .db property and we can use it to access the database.
MVC
We all know the MVC pattern. The question is how this applies to Express. More or less, it’s a matter of interpretation. In the next few chapters I’ll create modules, which act as a model, view and controller.
Model
The model is what will be handling the data that’s in our application. It should have access to a db object, returned by MongoClient. Our model should also have a method for extending it, because we may want to create different types of models. For example, we might want a BlogModel or a ContactsModel. So we need to write a new spec: /tests/base.model.spec.js, in order to test these two model features. And remember, by defining these functionalities before we start coding the implementation, we can guarantee that our module will do only what we want it to do.
var Model = require("../models/Base"),
dbMockup = {};
describe("Models", function() {
it("should create a new model", function(next) {
var model = new Model(dbMockup);
expect(model.db).toBeDefined();
expect(model.extend).toBeDefined();
next();
});
it("should be extendable", function(next) {
var model = new Model(dbMockup);
var OtherTypeOfModel = model.extend({
myCustomModelMethod: function() { }
});
var model2 = new OtherTypeOfModel(dbMockup);
expect(model2.db).toBeDefined();
expect(model2.myCustomModelMethod).toBeDefined();
next();
})
});
Instead of a real db object, I decided to pass a mockup object. That’s because later, I may want to test something specific, which depends on information coming from the database. It will be much easier to define this data manually.
The implementation of the extend method is a little bit tricky, because we have to change the prototype of module.exports, but still keep the original constructor. Thankfully, we have a nice test already written, which proves that our code works. A version which passes the above, looks like this:
Here, there are two helper methods. A setter for the db object and a getter for our database collection.
View
The view will render information to the screen. Essentially, the view is a class which sends a response to the browser. Express provides a short way to do this:
res.render('index', { title: 'Express' });
The response object is a wrapper, which has a nice API, making our life easier. However, I’d prefer to create a module which will encapsulate this functionality. The default views directory will be changed to templates and a new one will be created, which will host the Base view class. This little change now requires another change. We should notify Express that our template files are now placed in another directory:
app.set('views', __dirname + '/templates');
First, I’ll define what I need, write the test, and after that, write the implementation. We need a module matching the following rules:
Its constructor should receive a response object and a template name.
It should have a render method which accepts a data object.
It should be extendable.
You may wonder why I’m extending the View class. Isn’t it just calling the response.render method? Well in practice, there are cases in which you will want to send a different header or maybe manipulate the response object somehow. Like for example, serving JSON data:
var data = {"developer": "Krasimir Tsonev"};
response.contentType('application/json');
response.send(JSON.stringify(data));
Instead of doing this every time, it would be nice to have an HTMLView class and a JSONView class. Or even an XMLView class for sending XML data to the browser. It’s just better, if you build a large website, to wrap such functionalities instead of copy-pasting the same code over and over again.
Here is the spec for the /views/Base.js:
var View = require("../views/Base");
describe("Base view", function() {
it("create and render new view", function(next) {
var responseMockup = {
render: function(template, data) {
expect(data.myProperty).toBe('value');
expect(template).toBe('template-file');
next();
}
}
var v = new View(responseMockup, 'template-file');
v.render({myProperty: 'value'});
});
it("should be extendable", function(next) {
var v = new View();
var OtherView = v.extend({
render: function(data) {
expect(data.prop).toBe('yes');
next();
}
});
var otherViewInstance = new OtherView();
expect(otherViewInstance.render).toBeDefined();
otherViewInstance.render({prop: 'yes'});
});
});
In order to test the rendering, I had to create a mockup. In this case, I created an object which imitates the Express’s response object. In the second part of the test, I created another View class which inherits the base one and applies a custom render method. Here is the /views/Base.js class.
The '/' after the route, which in the example above, is actually the controller. It’s just a middleware function which accepts request, response and next.
Above, is how your controller should look, in the context of Express. The express(1) command line tool creates a directory named routes, but in our case, it is better for it to be named controllers, so I changed it to reflect this naming scheme.
Since we’re not just building a teeny tiny application, it would be wise if we created a base class, which we can extend. If we ever need to pass some kind of functionality to all of our controllers, this base class would be the perfect place. Again, I’ll write the test first, so let’s define what we need:
it should have anextend method, which accepts an object and returns a new child instance
the child instance should have a run method, which is the old middleware function
there should be a name property, which identifies the controller
we should be able to create independent objects, based on the class
So just a few things for now, but we may add more functionality later. The test would look something like this:
var BaseController = require("../controllers/Base");
describe("Base controller", function() {
it("should have a method extend which returns a child instance", function(next) {
expect(BaseController.extend).toBeDefined();
var child = BaseController.extend({ name: "my child controller" });
expect(child.run).toBeDefined();
expect(child.name).toBe("my child controller");
next();
});
it("should be able to create different childs", function(next) {
var childA = BaseController.extend({ name: "child A", customProperty: 'value' });
var childB = BaseController.extend({ name: "child B" });
expect(childA.name).not.toBe(childB.name);
expect(childB.customProperty).not.toBeDefined();
next();
});
});
And here is the implementation of /controllers/Base.js:
Of course, every child class should define its own run method, along with its own logic.
FastDelivery Website
Ok, we have a good set of classes for our MVC architecture and we’ve covered our newly created modules with tests. Now we are ready to continue with the site, of our fake company, FastDelivery. Let’s imagine that the site has two parts – a front-end and an administration panel. The front-end will be used to display the information written in the database to our end users. The admin panel will be used to manage that data. Let’s start with our admin (control) panel.
Control Panel
Let’s first create a simple controller which will serve as the administration page. /controllers/Admin.js file:
var BaseController = require("./Base"),
View = require("../views/Base");
module.exports = BaseController.extend({
name: "Admin",
run: function(req, res, next) {
var v = new View(res, 'admin');
v.render({
title: 'Administration',
content: 'Welcome to the control panel'
});
}
});
By using the pre-written base classes for our controllers and views, we can easily create the entry point for the control panel. The View class accepts a name of a template file. According to the code above, the file should be called admin.hjs and should be placed in /templates. The content would look something like this:
(In order to keep this tutorial fairly short and in an easy to read format, I’m not going to show every single view template. I strongly recommend that you download the source code from GitHub.)
Now to make the controller visible, we have to add a route to it in app.js:
Note that we are not sending the Admin.run method directly as middleware. That’s because we want to keep the context. If we do this:
app.all('/admin*', Admin.run);
the word this in Admin will point to something else.
Protecting the Administration Panel
Every page which starts with /admin should be protected. To achieve this, we are going to use Express’s middleware: Sessions. It simply attaches an object to the request called session. We should now change our Admin controller to do two additional things:
It should check if there is a session available. If not, then display a login form.
It should accept the data sent by the login form and authorize the user if the username and password match.
Here is a little helper function we can use to accomplish this:
First, we have a statement which tries to recognize the user via the session object. Secondly, we check if a form has been submitted. If so, the data from the form is available in the request.body object which is filled by the bodyParser middleware. Then we just check if the username and password matches.
And now here is the run method of the controller, which uses our new helper. We check if the user is authorized, displaying either the control panel itself, otherwise we display the login page:
run: function(req, res, next) {
if(this.authorize(req)) {
req.session.fastdelivery = true;
req.session.save(function(err) {
var v = new View(res, 'admin');
v.render({
title: 'Administration',
content: 'Welcome to the control panel'
});
});
} else {
var v = new View(res, 'admin-login');
v.render({
title: 'Please login'
});
}
}
Managing Content
As I pointed out in the beginning of this article we have plenty of things to administrate. To simplify the process, let’s keep all the data in one collection. Every record will have a title, text, picture and type property. The type property will determine the owner of the record. For example, the Contacts page will need only one record with type: 'contacts', while the Blog page will require more records. So, we need three new pages for adding, editing and showing records. Before we jump into creating new templates, styling, and putting new stuff in to the controller, we should write our model class, which stands between the MongoDB server and our application and of course provides a meaningful API.
The model takes care of generating a unique ID for every record. We will need it in order to update the information later on.
If we want to add a new record for our Contacts page, we can simply use:
var model = new (require("../models/ContentModel"));
model.insert({
title: "Contacts",
text: "...",
type: "contacts"
});
So, we have a nice API to manage the data in our mongodb collection. Now we are ready to write the UI for using this functionality. For this part, the Admin controller will need to be changed quite a bit. To simplify the task I decided to combine the list of the added records and the form for adding/editing them. As you can see on the screenshot below, the left part of the page is reserved for the list and the right part for the form.
Having everything on one page means that we have to focus on the part which renders the page or to be more specific, on the data which we are sending to the template. That’s why I created several helper functions which are combined, like so:
var self = this;
...
var v = new View(res, 'admin');
self.del(req, function() {
self.form(req, res, function(formMarkup) {
self.list(function(listMarkup) {
v.render({
title: 'Administration',
content: 'Welcome to the control panel',
list: listMarkup,
form: formMarkup
});
});
});
});
It looks a little bit ugly, but it works as I wanted. The first helper is a del method which checks the current GET parameters and if it finds action=delete&id=[id of the record], it removes data from the collection. The second function is called form and it is responsible mainly for showing the form on the right side of the page. It checks if the form is submitted and properly updates or creates records in the database. At the end, the list method fetches the information and prepares an HTML table, which is later sent to the template. The implementation of these three helpers can be found in the source code for this tutorial.
Here, I’ve decided to show you the function which handles the file upload:
handleFileUpload: function(req) {
if(!req.files || !req.files.picture || !req.files.picture.name) {
return req.body.currentPicture || '';
}
var data = fs.readFileSync(req.files.picture.path);
var fileName = req.files.picture.name;
var uid = crypto.randomBytes(10).toString('hex');
var dir = __dirname + "/../public/uploads/" + uid;
fs.mkdirSync(dir, '0777');
fs.writeFileSync(dir + "/" + fileName, data);
return '/uploads/' + uid + "/" + fileName;
}
If a file is submitted, the node script .files property of the request object is filled with data. In our case, we have the following HTML element:
<input type="file" name="picture" />
This means that we could access the submitted data via req.files.picture. In the code snippet above, req.files.picture.path is used to get the raw content of the file. Later, the same data is written in a newly created directory and at the end, a proper URL is returned. All of these operations are synchronous, but it’s a good practice to use the asynchronous version of readFileSync, mkdirSync and writeFileSync.
Front-End
The hard work is now complete. The administration panel is working and we have a ContentModel class, which gives us access to the information stored in the database. What we have to do now, is to write the front-end controllers and bind them to the saved content.
Here is the controller for the Home page – /controllers/Home.js
module.exports = BaseController.extend({
name: "Home",
content: null,
run: function(req, res, next) {
model.setDB(req.db);
var self = this;
this.getContent(function() {
var v = new View(res, 'home');
v.render(self.content);
})
},
getContent: function(callback) {
var self = this;
this.content = {};
model.getlist(function(err, records) {
... storing data to content object
model.getlist(function(err, records) {
... storing data to content object
callback();
}, { type: 'blog' });
}, { type: 'home' });
}
});
The home page needs one record with a type of home and four records with a type of blog. Once the controller is done, we just have to add a route to it in app.js:
Again, we are attaching the db object to the request. Pretty much the same workflow as the one used in the administration panel.
The other pages for our front-end (client side) are almost identical, in that they all have a controller, which fetches data by using the model class and of course a route defined. There are two interesting situations which I’d like to explain in more detail. The first one is related to the blog page. It should be able to show all the articles, but also to present only one. So, we have to register two routes:
They both use the same controller: Blog, but call different run methods. Pay attention to the /blog/:id string. This route will match URLs like /blog/4e3455635b4a6f6dccfaa1e50ee71f1cde75222b and the long hash will be available in req.params.id. In other words, we are able to define dynamic parameters. In our case, that’s the ID of the record. Once we have this information, we are able to create a unique page for every article.
The second interesting part is how I built the Services, Careers and Contacts pages. It is clear that they use only one record from the database. If we had to create a different controller for every page then we’d have to copy/paste the same code and just change the type field. There is a better way to achieve this though, by having only one controller, which accepts the type in its run method. So here are the routes:
module.exports = BaseController.extend({
name: "Page",
content: null,
run: function(type, req, res, next) {
model.setDB(req.db);
var self = this;
this.getContent(type, function() {
var v = new View(res, 'inner');
v.render(self.content);
});
},
getContent: function(type, callback) {
var self = this;
this.content = {}
model.getlist(function(err, records) {
if(records.length > 0) {
self.content = records[0];
}
callback();
}, { type: type });
}
});
Deployment
Deploying an Express based website is actually the same as deploying any other Node.js application:
The files are placed on the server.
The node process should be stopped (if it is running).
An npm install command should be ran in order to install the new dependencies (if any).
The main script should then be run again.
Keep in mind that Node is still fairly young, so not everything may work as you expected, but there are improvements being made all the time. For example, forever guarantees that your Nodejs program will run continuously. You can do this by issuing the following command:
forever start yourapp.js
This is what I’m using on my servers as well. It’s a nice little tool, but it solves a big problem. If you run your app with just node yourapp.js, once your script exits unexpectedly, the server goes down. forever, simply restarts the application.
Now I’m not a system administrator, but I wanted to share my experience integrating node apps with Apache or Nginx, because I think that this is somehow part of the development workflow.
As you know, Apache normally runs on port 80, which means that if you open http://localhost or http://localhost:80 you will see a page served by your Apache server and most likely your node script is listening on a different port. So, you need to add a virtual host that accepts the requests and sends them to the right port. For example, let’s say that I want to host the site, that we’ve just built, on my local Apache server under the expresscompletewebsite.dev address. The first thing that we have to do is to add our domain to the hosts file.
127.0.0.1 expresscompletewebsite.dev
After that, we have to edit the httpd-vhosts.conf file under the Apache configuration directory and add
# expresscompletewebsite.dev
<VirtualHost *:80>
ServerName expresscompletewebsite.dev
ServerAlias www.expresscompletewebsite.dev
ProxyRequests off
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
<Location />
ProxyPass http://localhost:3000/
ProxyPassReverse http://localhost:3000/
</Location>
</VirtualHost>
The server still accepts requests on port 80, but forwards them to port 3000, where node is listening.
The Nginx setup is much much easier and to be honest, it’s a better choice for hosting Nodejs based apps. You still have to add the domain name in your hosts file. After that, simply create a new file in the /sites-enabled directory under the Nginx installation. The content of the file would look something like this:
Keep in mind that you can’t run both Apache and Nginx with the above hosts setup. That’s because they both require port 80. Also, you may want to do a little bit of additional research about better server configuration if you plan to use the above code snippets in a production environment. As I said, I’m not an expert in this area.
Conclusion
Express is a great framework, which gives you a good starting point to begin building your applications. As you can see, it’s a matter of choice on how you will extend it and what you will use to build with it. It simplifies the boring tasks by using a few great middlewares and leaves the fun parts to the developer.
