All too often I see javascript/jQuery written for common task over and over in what I would claim to be an inefficient manner.  For example let’s take a scenario where I have two pages within my site and based upon the site design I need to insert at the top of each page an expanding section that will contain instructions on how to use the tools within the current page. To do this I’ll set my html as follows:

HTML Code

<div>
   <h3>Manage agency shares</h3>
      <br />
        <div class="instructionslide" id="1" >
            Instructions</div>
        <div class="instructions">
           <ul>
               <li>Some instructions</li>
               <li>Some more instructions </li>
           </ul>
        </div>
        <hr />

Fairly basic layout with two DIV elements. The first will serve as my button that the user can click on to expand the second Div element. You’ll notice I alos have CSS classes applied to each DIV element for some basic styling. The CSS looks similar to this:

CSS

.instructions
{
 margin: 5px;
 height: 0px;
 font-size: .9em;
 margin-left: auto;
 margin-right: auto;
}

.instructionslide
{
 font-size: 1.1em;
 font-weight: bold;
 margin-left: auto;
 margin-right: auto;
 cursor: pointer;
}

Notice within the instructions class I have the height set by default to zero. I can manage the animation or height of the panel by injecting into the css a run-time a new height via jQuery via some code similar to this:

$('.instructions').animate({ "height": "200px" }, 'slow');

Do you see the problem developing? If not I’ll give you a hint. What this is leading to is a new jQuery function or call for each new window that has a different height requirement. If   your site has a fixed size and we know for dead certain that the height will never vary then this may not be an issue. But what if you have a page that has a need for the height to be 100px and on the next page 300px. The result could be a bloated js file where the designer is creating a new function to just change one property.

We can correct this by actually creating an array within our js file and then loading the appropriate property based upon a specified ID.

//expander window used for instructions
$(document).ready(function () {

    /*create a string array to store various window sizes then based upon the attribute id of the element
    load the apporaiate array value*/
    var winHeight = ["220px",
                     "100px",
                     "90px"];

    $(function () {
        $('.instructions').hide();
    });

    $('.instructionslide').click(function () {
        var cssProp = winHeight[$(this).attr('id')];

        if ($('.instructions').is(':hidden')) {
            $('.instructions').show();
            $('.instructions').animate({ "height": cssProp }, 'slow');
        }
        else {
            $('.instructions').hide("slow");
            $('.instructions').animate({ "height": "0px" }, 'slow');
        }
    });

    $('.instruction-close').click(function () {
        $('.instructions').hide();
        $('.instructions').animate({ "height": "0px" }, 'slow');
    });
});

For this part I’m not going to focus on the jQuery expansion but more on the Array and how we can reference it.

At the beginning of the js file I created an Array with three properties:

var winHeight = ["220px",
                     "100px",
                     "90px"];

We detect and access the click events within the html by using the class as the selector within our jQuery. By doing this it frees up the Id attribute that I can now use it to carry a value.

<div class="instructionslide" id="1" >

This value is then used within my jQuery file to detect which array value I want to reference.  As a note, remember that an Array always starts with Zero [0, 1, 2, 3 ...]

Now let’s look at the last two parts of the code that makes this work. On the click event of the DIV element  we first create a new variable call cssProp.  cssProp is being set to the current value of the position of our array. This value within the array is determined by looking to the current element (the DIV element) and retreiving the value from the ID attribute.

$('.instructionslide').click(function () {
        var cssProp = winHeight[$(this).attr('id')];

We can now dynamically set the height of our DIV element by simply calling the cssProp value in our code.

$('.instructions').animate({ "height": cssProp }, 'slow');

What we gain by this is a reduction of code we have to write through code re-use. This also supports maintenance of the function down the road as we now have it in one location.

Array’s are incredibly powerful when used in conjunction with css styling for a site and you’re not just limited to a basic one property value as I outlined above.  Let’s take a quick look at how we can set multiple values within the array for our Ui elements.

In this example I want to open a pop-up window within my site.  Based upon my site requirements I may need to manage the various attributes of the pop-up window for different pages (height, width, resizable… etc) Let’s take a look:

var windowPropertyArray = ["width=550, height=600, scrollbars=yes, menubar=no, resizable=no, status=no, toolbar=no",
                               "width=500, height=600"];

    $('.am_LinkButton').click(function (event) {
        var url = $(this).attr("href") + "?ID=" + $(this).attr("rel");
        var windowName = "window";
        var windowProp = windowPropertyArray[$(this).attr("tag")];
        //prevents browser from firing default action for window.open allows js to work
        if (event.preventDefault) {
            event.preventDefault();
        }
        else {
            event.returnValue = false;
        }

        window.open(url, windowName, windowProp);
    });
});

Within this example I am passing an entire string of parameters to my window.open function. As a result this allows me to control the window size and properties for various click events.

Happy Coding!

Well I am happy to say that in reading a recent newsletter from ( a personally respected and favorite resource) Ken Hamady http://kenhamady.com/cru/ I saw mention of a third-party viewer which supports the refreshing of data / parameters within the Viewer.  The viewer mentioned is the Data Link Viewer.  Which allows users to run reports without having the ability to open the RPT files in the designer.  I found this was a great and much welcome feature as the DLV also  the report by creating in essence a read only file which protects proprietary business calculations, as well as prevents unwanted tampering of the report.

More info on the DLV and other cool crystal report add-in’s can be found at:  http://www.milletsoftware.com/

Happy Reporting!

 Where did I place that reference?

I started out by using masterpages to store some of the common elements such as the header and footer of the page, CSS files etc. However in this project UI designer had used JQuery to dictate the look navigation of the sites main toolbar. As I added my references to the JS files and compiled the site I found that at run time the references to the paths were being lost in the masterpage.The end result… broken nav aka no access to the JQuery library from master pages.

The solution:

The solution lies within the use of the ASP.NET Script manager tags. When working with ASP.NET remember that server-side controls are renamed as they are rendered this is why when we view source we see ct100_text….. Through the use of the scriptmanager we can help to ensure that the references to library files or other resources is not lost during the compiling of the page. 

In my example I was able to point to the JQuery libraries by using the ScriptManager  as follows:

<asp:ScriptManager ID="ScriptManager" runat="server">

<Scripts>

<asp:ScriptReference Path="~/Scripts/jquery-1.4.2.min.js" />

<asp:ScriptReference Path="~/Scripts/jquery-ui-1.8.6.custom.min.js" />

</Scripts>

</asp:ScriptManager>

Be sure to remember that the script manager tag has to be placed within side of a FORM tag. So don’t add this to the header place it within the body of the html.

Of course there are many other uses for the script manager especially with regards to AJAX. However for those of you who have tried to use JS files or other scripting syntax within masterpages to no avail. Hopefully this will help.. Happy coding!

For more information on the ScriptManager check out: http://msdn.microsoft.com/en-us/magazine/cc163354.aspx#S5

1. From within the ASP.NET solution right-mouse click on the solution title nd select properties
2. Navigate to the Web tab within the properties window
3. Ensure that the Silverlight check box is enabled in the Debugger section
4. Save the project properties
5. Happy De-bugging

With that being said, I’m including in this post a short pdf file that will help get most people started with a few basic (need to know) formulas.  While there are a ton of formulas available and the manner in which we use the formulas can seem to be endless I always feel as if there are a few basic formulas and operators that everyone should know.   Of course there’s always more to come and if you have questions or comments feel free to shoot them my way. I’ll respond as time allows and attempt to address most questions through the blog in an effort to help the community as a whole.

Useful formulas for reports

Happy reporting!

So really… what’s the rush?

The first step in designing a professional report is to not rush into the development stage.  That’s right, put the mouse down, step away from the computer and think about what you are getting yourself into. Seriously, when creating a report you need to understand that there are multiple stages (similar to an applications life cycle) of the report creation process. I often describe this “report life cycle” in four stages. They are as follows:

Design – this is the most crucial stage. At this point you collect and gather all resources needed for the report. At this stage you shouldn’t even touch your report writing application. Here you’re doing good old investigative work to collect all the requirements of the report.

Development – At this stage you begin building the report. You’ve successfully collected all the information needed and now you are simply putting the pieces in place to generate the report. 

Review/Revisions – If you can develop a report and submit it to the requesting originator and not receive any corrects or request for change then one of three things has happened. 1) They have not looked at the report, 2) You where the person requesting the report, or 3) you got extremely lucky.   While it can and does happen you need to prepare yourself for the fact that the first version of your new report will be just that “Revision 1”. Change requests will come in; people will want to see different slices of data or variations of the original report. This stage can in some instances be indefinite if you don’t properly plan for them. Don’t worry I’ll show you how to mitigate this stage as well.

Maintenance – At this stage the report has been deployed and you may only need to conduct occasional maintenance on the visual elements of the report or make a minor tweak here or there.  

Where first time report designers usually gets into trouble is they often skip the design stage. We receive a request for a report and lickety-split we just head right into development mode in an effort to start cranking out that report. As a result, we can only hope for hours of frustration, and numerous revisions since we did not take the time to properly understand the report requirements.

Ask why… Ask why once more … and then Ask Why Again!

I can’t recall where I originally heard this statement but I can tell you that you can apply it to a number of things in life both personal and professional. Of course, you need to use some common sense when asking this question (say around your spouse or boss) but I have found that when someone asks you to do something for them if you ask them why they need it, AND you ask them why three times you’ll actually learn the real reason which may be different from their initial request.

Let’s go through a quick scenario….

Someone comes to you and asks you to create a report that shows all sales for last month. Do you jump right in and start building that report? NO, you should say “Okay, you want a report for last month’s sales, why? Normally, you’ll get a funny look and THEN you’ll get a different answer… Well I was just in a meeting, and Jane wanted to know how the sales from last month compared to the prior month.  Ah ha! Asking why twice has resulted in a different answer. At this time you may feel safe to start building the report but I’ll tell you, ask why one more time…. “Okay so you don’t need just the data from last month you want to see a comparison to the prior month’s sales. And why do you need to see that data?” *

*Note: be aware that at this time the originator of the request could become agitated.  If it is a person of high authority they may turn red and then begin to yell. Just remember to stand strong and weather the storm.

Upon being asked a third time chances are someone (and it’s not you) is getting irritated. However, you’ll probably also get a different reply (something along these lines)…. “Just create the #*&@ report! Jane has a meeting coming up with the executive team and we need to see where sales are at for the past three months! Jane needs to know which stores are meeting the monthly sales quota and which ones are exceeding the quota.  Whoa! Did that just happen? Yeah, it did and I can guarantee you that if you continue to ask why you’ll continue to drill down into the real cause and need for the report.

I cannot tell you the times I have seen this happen. From the law enforcement side I’ve heard the same request/ and similar scenario:

Tom I need you to create an arrest report.

-          Why do you need an arrest report?

I need to see how many arrests occurred last month.

-          Why do you need to see the number of arrests that occurred last month?

I need to see how many misdemeanors and felony arrests occurred in the downtown area last month.

While it won’t always be this straight forward, the point I am trying to stress is that before you begin planning the development of any report “Ask Why” the person needs the report. The more information (aka requirements) you can collect, the better chances you will have of actually developing a report that they need or more importantly, developing the report that they want.

Details, details, details…

Learning the true nature of the report is only the first part of the design process. Next we need to actually plan the layout of the report. Now let me preface this by stating that the planning stage does take some time and it is a process that you will refine and develop to suit your own needs over time. The main thing is to be consistent and start out with a basic template or set of guidelines that you can follow when planning the design of the report.

When planning the report here are a few useful questions that you can incorporate into your planning process. Remember you are the investigator trying to understand the nature,  purpose and even layout of the report.

• Who is the report for? – Is this report for internal or external use? Will it be viewed by the executive team or will it be used for quick analytical tasks. Is this a media report that will be distributed to the public?
• What data elements need to be in this report? – Given, most of these fields can be determined based upon asking “Why do they want you to create the report”. It may also help to ask:
• Would you like to group anything?
  • Date range ( week, bi-weekly, monthly yearly)
  • Names
  • Departments
  • Codes
  • Would you like the groups to be in ascending or descending order?
  • Do you need to print this report out? If so, landscape or portrait or do you have another format in mind?
  • Do you need to count or summarize anything?  (Hint: If so, you must have a group )
  • Do you need to see grand totals? (Does not need a group as it counts the total number of records in a report)
  • Should there be any headers or logos on this report?
  • Do you want to visually identify certain values? (Example: change the font color or background color on a section if a value is too high or too low or of a certain type)
  • Do you want to see data represented in a chart or graph?
  • Would you like to be able to filter date within the report (Hint: you may filter by any element in the database. The field does not necessarily be visible or used within the report… more on this in later posts)?
  • How should this report be delivered (native report format, PDF, TXT, HTML, etc.)

Questions you as the designer need to ask yourself:

• Do you know what data source you are going to reference when building the report?
• Do you have access to this data source?
• What database fields should be used?
• Do you need to make the form dynamic so that the user may change their search criteria?
• Will this report require the user of more than one report (sub-reports)?

Once you have all this information collected the last and final step that I would suggest is that you sketch out a rough outline of what the report should look like. Do this on a piece of paper, use a word processing application to mock-up something etc. The more visual layout you can address up front the better off you will be.  In some instances you may find through the sketch you may find that a certain layout just will not work or that you need to create additional groups based upon the requirements.

Summary

I’ll hold off on drilling into the last two sections of the report life cycle for now as I wanted this to stress the importance of planning our your report. While this may initially seem as a tedious and almost juvenile process to follow I can assure that the more planning and investigative tactics you can apply before you even begin connecting to data sources the more time you will gain on the back-end during the actual development of the report.

For those new to report creation I’ll leave you with this one statement. No failed attempt at a report was ever the result of a well-planned report. 

Happy report writing!