IronShay

Ironing code, geek t-shirts and even presentations!

NAVIGATION - SEARCH

My Chrome Developer Tools Interview at .NET Rocks! is Available

Hi!

During NDC London I did an Interview with Carl Franklin and Richard Campbell from .NET Rocks! regarding Chrome Developer Tools. It was a fun experience for me and hopefully an enriching one for the audience!


And go download OzCode!

All the best,
Shay.

Code Snippet: Find an Element in Page By its Angular Scope ID

Recently I was working on one of my projects and ran into a very illusive scope - I needed to know to which element it belonged but just couldn't find it on through the Elements Panel. So I wrote a small code snippet that you can paste to the console, or put somewhere in your code - it searches the DOM stating from a root element that it's given and looks for an element that has an angular scope with a specific ID attached to it.

function findScope(id, el) {
  if (angular.element(el).scope().$id == id) { return el; }
  for (var i = 0; i < el.childNodes.length; i++) {
    var result = findScope(id, el.childNodes[i]);
    if (result) { return result; }
  }
}

// Example usage:
findScope('05W', document.body);
Enjoy!
Shay.

Using Inline Templates for Directives

When writing angular directives you usually use two kinds of templates - a string that goes into the template property, or a path to a file containing the template which goes into the templateUrl property. The less known brother of these is the inline template option, which is what this blog post is about.

What are Inline Templates?

Inline templates are templates that you define inside your HTML pages within <script> tags. This is an "in-between" approach between the string template and the file template - on the one hand, you don't have to define the template as a string (who loves doing that?? it's such a horrible experience) and on the other hand, angular doesn't need to request the template from the server because it already loads with the page.

What Is It Good For?

A lot!
Well, a few use cases that this approach will make sense for:
  • Instead of using the template property which forces you to write the template as a string.
    If you're a fan of concatenating strings, then this might not appeal to you. But if you are, hmmm, well, you probably have other problems :)
  • When you create a DSL for your application which involves a bunch of directives which will, for sure, be loaded - put all the templates on the main page. This will eliminate the calls to the server for fetching the templates.
  • The last bullet works for every directive that will certainly be loaded at some point.
In my applications I usually create a single partial page which gets loaded with the master layout page and put there all the directive templates I need.

How do You Define Inline Templates?

It's very simple!
To define the template, just add a <script> tag with type="text/ng-template" and a unique id, for example, id="/templates/my-head.html":


On the directive side, use the templateUrl property and set its value to the script tag id. In our case, that would be "/templates/my-head.html":
m.directive("myHead", function() {
  return {
    templateUrl: "/templates/my-head.html"
  };
});

Why Not, Then?

There a few disadvantages for using inline templates that you should be aware of:
  • Some IDEs will not provide autocompletion inside <script> tags. 
  • People usually prefer to have the template file on its own because it's easier to find on the file tree.
    This is pretty true. However, you can continue working with separate file and then write a simple build script that will take all the template files and bundle them into a single file before going to production.

Summary

Inline directive templates is a super simple and powerful solution that makes a lot of sense for various use cases. For some reason the documentation on this feature is pretty much not existing so I hope now it will get the acknowledgment it deserves :)

Write Angular and prosper!
Shay.

Printing Web Pages – the Cool Way!

When developing web applications we often run into a request to print one or more pages within the applications. In most cases, these pages will contain some type of report.
There are tons of ways to do that. Most of them I don’t like, especially the trivial one that pops to mind - “open a new window with a printer-friendly version of the page and set onload=’window.print()‘”. I find it quite irritating for the user.

There is another solution, which is less popular than its fellow window.open solution, but IMHO is much more user friendly and also might save you a few lines of code. It’s the CSS @media print solution!

What’s it all about?

  1. You get to have a single page that prints in slightly a different way than it’s presented on the browser.
  2. The magic lies within a special CSS block where you define CSS classes that will be used when the page is printed.
  3. This way you can hide parts of the page that don’t need to be printed, change the background image, increase/decrease font size, etc.

 

How to use it

The idea is to declare a different set of CSS styles for the page’s print mode. The great thing about that is that you can also, via CSS, hide elements that are unnecessary for printing.

For example, assuming you have the next HTML document:

<html>
<head>
    <title></title>
</head>
<body>
  <h1>REPORT</h1>
  <form><input type="button" id="printButton" value="Print" onclick="window.print()"/></form>
  <table border="1">
    <thead>
      <tr>
        <td>Column A</td><td>Column B</td><td>Column C</td>
      </tr>
    </thead>
    <tbody>
      <tr><td>1</td><td>2</td><td>3</td></tr>
      <tr><td>4</td><td>5</td><td>6</td></tr>
      <tr><td>7</td><td>8</td><td>9</td></tr>
    </tbody>
  </table> 
</body>
</html>
  1. This page will be presented as follows:
  2. image

Great UI indeed. However, printing this page will be a bit ugly (surprise surprise!), but really, in terms of printing the page, the header shouldn’t be that big and the print button shouldn’t be visible at all.

To do so, all we have to do is to define the styles for printing mode:

<style type="text/css">
  @media print
  {
    /* Here goes all styles to be used when printing */

    #printButton { display: none; } /* hide the print button */
    h1 { font-size: 12px; } /* make the header 12 pixels */
    body, td { 10px; } /* make regular text 10 pixels */
  }
</style>  

That’s it. Now if we print-preview the page, the header will be smaller and the Print button will be hidden:

Print Preview with @media print

Voila! No window.open is needed!

[Side note: I know this approach might be problematic sometimes because the user wouldn’t know what to expect when the page is printed. However, I still think this is a much more elegant way than the window.open approach. Use it wisely though].

ASP.NET developers: be careful when using CSS’s ‘#’ symbol with element IDs. Remember that ASP.NET changes the final HTML element ID of your controls that have the runat=”server” attribute.

All the best,
Shay.

Full source:

<html>
<head>
  <title></title>
  <style type="text/css">
    @media print
    {
      /* Here goes all styles to be used when printing */

      #printButton { display: none; } /* hide the print button */
      h1 { font-size: 12px; } /* make the header 12 pixels */
      body, td { 10px; } /* make regular text 10 pixels */
    }
  </style>  
</head>
<body>
  <h1>REPORT</h1>
  <form><input type="button" id="printButton" value="Print" onclick="window.print()"/></form>
  <table border="1">
    <thead>
      <tr>
        <td>Column A</td><td>Column B</td><td>Column C</td>
      </tr>
    </thead>
    <tbody>
      <tr><td>1</td><td>2</td><td>3</td></tr>
      <tr><td>4</td><td>5</td><td>6</td></tr>
      <tr><td>7</td><td>8</td><td>9</td></tr>
    </tbody>
  </table> 
</body>
</html>