One of the things that was missing from the functional set that I ended up needing was the ability to page the list, but through issuing AJAX requests instead of the typical post back.

So I went off and extended the existing model to support AJAX requests, and thought I would share it in case anyone else needed to do the same thing.

I guess the best place to start would be the use case.  So to start I created a control that encapsulates the Paging UI layout and calls I need.  The use of the original control looks like this:

Html.RenderPartial("AjaxPagination",
    new AjaxPaginationViewData
        {
            PageIndex = Model.PageIndex,
            Action = "CondoPage",
            Controller = "Home",
            AjaxOptions =
                new AjaxOptions { UpdateTargetId = "updatedContent" },
            TotalCount = Model.TotalCount,
            PageSize = Model.PageSize,
            NumberOfPagesToEachSide = 2
        }
);

The new AJAX functionality is called similarly:

<% using (Ajax.BeginForm("SomePage",
        "SomeController",
        new AjaxOptions { UpdateTargetId = "updatedContent" })) { %>

        <% Html.RenderPartial("AjaxPagination",
                new AjaxPaginationViewData {
                        PageIndex = Model.PageIndex,
                        Action = "SomeAction",
                        Controller = "SomeController",
                        AjaxOptions = new AjaxOptions
                                { UpdateTargetId = "updatedContent" },
                        TotalCount = Model.TotalCount,
                        PageSize = Model.PageSize,
                        NumberOfPagesToEachSide = 2
                });%>

<% } %>

A couple things to note. You’ll notice that the AJAX control is rendered inside a Ajax.BeginForm. This is because I’m using the Microsoft.Ajax way of making AJAX calls.  This could also be done using jQuery or something else that can process AJAX calls. I just went this way because the scripts are already included in asp.net mvc app when you first create the project.  The result of the AJAX call will be a partial view, and we’ll need to put that somewhere.  That’s where the UpdatedTargetId comes into play. Other things we include in the AJAX control that are not in the original are the Action and the Controller, and some AjaxOptions. PageActionLink doesn’t work with the AJAX control, because we’ll be using Ajax.ActionLink to build the link, which is why I broke it up into Action, and Controller. For the AjaxOptions, we need those to specify the target of the call.

So now that’s been explained, let’s look at the controls themselves.  Here’s a comparison of the original control and the ajax control.

The original is one this way:

<% if (Model.HasPreviousPage) { %>
    <a href="<%=Model.PageActionLink.Replace("%7Bpage%7D", (Model.PageIndex - 1).ToString())%>">Previous</a>
<% } %>

<% if (Model.GetFirstPageToLink() != 1) { %>...<% } %>

<%for (var page = Model.GetFirstPageToLink(); page <= Model.GetLastPageToLink(); page++) {
    if (page == Model.PageIndex) { %>
        <%=page.ToString()%>
<% } else { %>
    <a href="<%=Model.PageActionLink.Replace("%7Bpage%7D", page.ToString())%>"><%=page.ToString()%></a>
<% } 

    if (page != Model.GetLastPageToLink()) { %>|<% } } %>

<% if (Model.GetLastPageToLink() != Model.PageCount) { %>...<% } %>

<% if (Model.HasNextPage) { %>
    <a href="<%=Model.PageActionLink.Replace("%7Bpage%7D", (Model.PageIndex + 1).ToString())%>">Next</a>
<% } %>

And the AJAX control is done this way:

<% if (Model.HasPreviousPage) { %>

<%= Ajax.ActionLink("Previous", Model.Action, Model.Controller, new { page = (Model.PageIndex - 1).ToString() }, Model.AjaxOptions)%>

<% } %>

<% if (Model.GetFirstPageToLink() != 1) { %>...<% } %>

<%for (var page = Model.GetFirstPageToLink(); page <= Model.GetLastPageToLink(); page++) {
    if (page == Model.PageIndex) { %>
        <%=page.ToString()%>
    <% } else { %>

<%= Ajax.ActionLink(page.ToString(), Model.Action, Model.Controller, new { page = page.ToString() }, Model.AjaxOptions)%>

<% } if (page != Model.GetLastPageToLink()) { %> | <% } } %>

<% if (Model.GetLastPageToLink() != Model.PageCount) { %>...<% } %>

<% if (Model.HasNextPage) { %>

<%= Ajax.ActionLink("Next", Model.Action, Model.Controller, new { page = (Model.PageIndex + 1).ToString() }, Model.AjaxOptions)%>

<% } %>

The big difference here is the way that the links are generated. The original control simply creates an anchor tag and passes in the url generated by the Model. The AJAX control uses AJAX.ActionLink() instead, so we can have the link support AJAX.

So knowing how the control looks, this is the Model for the AJAX control itself:

public class AjaxPaginationViewData
{
    public int NumberOfPagesToEachSide { get; set; }
    public int PageIndex { get; set; }
    public int PageSize { get; set; }
    public int TotalCount { get; set; }

    public string Action { get; set; }
    public string Controller { get; set; }

    public AjaxOptions AjaxOptions { get; set; }

    public int PageCount
    {
        get
        {
            return (int)Math.Ceiling((double)TotalCount / PageSize);
        }
    }
    public bool HasPreviousPage
    {
        get
        {
            return (PageIndex > 1);
        }
    }

    public bool HasNextPage
    {
        get
        {
            return (PageIndex * PageSize) <= TotalCount;
        }
    }

    public int GetFirstPageToLink()
    {
        return (PageIndex - NumberOfPagesToEachSide > 1 ? PageIndex - NumberOfPagesToEachSide : 1);
    }

    public int GetLastPageToLink()
    {
        return (PageIndex + NumberOfPagesToEachSide < PageCount ? PageIndex + NumberOfPagesToEachSide : PageCount);
    }
}

That pretty much explains how the control is built.

The only thing left is how the interaction with PagedList happens.  For that we look at the action that the control calls.  In this example, we’re calling SomeAction in SomeController, and it would look something like this:

public ActionResult SomeAction(int page)
{
    CachedPage = page;
    var query = GetSearchQuery(CachedSearchParameters);
    var model = query.ToPagedList(page, DefaultPageSize);
    return PartialView("AjaxResults", model);
}

The ToPagedList performs the functionality that is included with the PagedList classes which you can find here.

Let me know what you think, and if you’d like some demo source to see this in action I can happily provide, just let me know.

Sometimes its just better to get a second opinion!

This is the new concept.  Not much has changed visually, but the behavior will definitely be different.

So the behavior will be by checking off one of the items from the search you’ll be informing the owner that you’re interested in that item.  What happens after that point I’m still working out, but that basically wraps up the behavior for this side.  What we have left to do is get the behavior done for the owner’s side.

Now my problem is I need to design a checkbox that will go on the side so people can just to click on.

So far I’ve come up with this, but I’m not 100% satisfied with it.  The coloring won’t really get nailed down until we put it up on the site and tweak it to make the color scheme, but you get the idea.

Any suggestions?

Let’s start buy throwing up what we currently have so we can see where we’re trying to go.  Here’s a mockup of what a user will see when they search for trades right now.

I have a couple problems with how it works right now.

1. I don’t like that it’s in a grid/table format.  I have to fix that first.  I’m moving more towards something like a list layout.
2. There are some things missing that I would like to be able to do.  For instance, if I just searched for “can of soup”, and I see that Michelle has the one I want, I would like to have a button/link/something to click on that says “I want that!”  Right now the only thing you can do is go look at the trade, or ask a question.
3. Clicking on the owner’s link takes you to their profile, but it doesn’t show you what other trades they have, or trades they are looking for.  That information could really be useful.

I’m sure there are other things I could think of, but for now I’m going to start focusing on these three and build some mockups to illustrate these workflows.

First, getting rid of the grid.

This search list looks a lot better I think.  There are some more features on here then the other one, but we’ll go over those in subsequent posts.

So at this point I’m looking for any feedback.  ANY feedback, good or bad… I’ll take it all.  I really haven’t made up my mind at this point yet, but I think I’m heading in the right direction.

Next post will be about the “I want it!” feature.  Stay tuned!

Here’s an example of the kind of thing you can build with it.

Balsamiq Demo

Now, the caveat to all of this was that you had this thing called an interface that actually allowed you to define declarations of behavior that could later be implemented. This could be done any number of times. This also made a lot of sense, and they would do some simplistic model that illustrates the concept. I imagine for purposes of this article we should probably illustrate something as well just to drive home the point. Let’s say you have a Coin. A Coin is a kind of Currency. So the simple inheritance chain would dictate that Coin inherits from Currency, and everything is fine. Of course, in order for this to matter at all, there needs to be some benefit to having Coin inherit from Currency. So let’s say that Currency has some behavior called CalculateBuyingPower that actually figures out what kind of buying power that particular Currency has. Ok, so now we have an inheritance chain, and we have a direct benefit, figuring out the buying power of the Coin.

If that’s as far as you take it, then everything’s all fine and dandy, and Single Inheritance is great. The problem is, that in the Real World, what we call Objects can legitimately “be” multiple things. This is equally true in the Software World. So, going back to the Coin, not only is the Coin a Currency, but the Coin is also a MetalConstruct. A MetalConstruct is just my way of saying something that is made of metal. Why do I care? Simple. At some point during the life of a Coin, it is entirely possible that the buying power of the Coin will reach a point that it would actually be better to melt down the Coin because the value of the Metal in the coin is much higher (look at what a penny is made of nowadays and you’ll see what I mean). Now, a lot of you are going to say, “That’s fine, just define a MetalConstruct interface and you should be good to go.” In a lot of cases that might be true, but in this example we fine a very big problem. The point of the MetalConstruct is to normalize the behavior of melting down the Coin. No matter what kind of MetalConstruct you have, the melting process for it is always going to be the same. Sure there are variations in melting temperature and what not, but the overall process is the same. The point being, that an interface can only declare that behavior MeltDown should exist, but not define the implementation of it. This is the problem with Single Inheritance. I now need a way for the Coin to be both a Currency and MetalConstruct, which provides the Coin with behaviors CalculateBuyingPower and MeltDown. Coin shouldn’t have to define how to do either of those behaviors, because that’s not it’s responsibility.

During software development, when you’re working on defining your domain, this can come up quite often, actually. With the advent of extension methods in .NET, you’re able to ease the pain a bit in C#, but the fundamental problem is really still there. What I would like to see would be one of two things. It would be nice if you could inherit from multiple abstract classes, which would allow you to define Contracts at the abstract class level. Another idea would be to bring forward the construct of a contract as a first-class citizen, it would be similar to an abstract class and an interface in the sense that you could not create one directly, but would allow for definition of behavior while still being able to have a class implement numerous contracts. It would be a totally new way of defining an object, apart from class, struct, or interface entirely perhaps.

So now I’m looking back at C++ and I’m thinking it would be really nice if I had Multiple Inheritance so I can just get past this ridiculous wall I’m having to climb. Possibly with .NET 4.0, Microsoft is bringing forth the idea of Code Contracts , which might help when you’re trying to get around Single Inheritance issues when dealing with Design by Contract, but for real domain model issues, I think the problem still remains.

Food for thought.

On a personal note, I’ve been working with Edward for the past 6 or so months, and he’s a really great guy.  The next time I buy my wife something of this caliber I’m definitely going to be going to him.

Even if you’re not in the market right now, go check out the site anyway.  He has a wealth of knowledge about diamonds and rings: what to look for in a diamond or setting, and other information about how the entire certification process works.  He’ll be updating his site regularly to keep people informed of his industry, so if you’re into diamonds you might want to consider registering on his site just for informational reasons.

Anyway, that’s my two cents, take care guys!

I read this blog a few weeks back, and while the principles that the author was trying to convey I don’t disagree with, I did have a hard time stomaching the idea that Swiss army knives made for bad OOP design.  Why?  Because I really like Swiss army knives!  I mean come on, what other device lets you have 100+ different kinds of knives, a compass, a light, a magnifying glass, and a USB drive all in one “disappears in your pocket” size container???

Ok so I know what most of you are thinking… I’m just PROVING that they violate SRP right?  Not actually.  In case you’re not familiar with the principle of SRP, check out this wiki.  The reason why I believe the Swiss army knife does NOT violate SRP is because my general rule of them is, if I can state the responsibility of the object in question in one single statement, then I have identified it’s SINGLE responsibility.  So I have to ask myself, what is the SINGLE thing that a Swiss army knife does?

Responsibility statement: A Swiss army knife is responsible for allowing it’s user to be able to use any tool that has been installed into it.

Short, simple, and to the point.  Now, that sounds all fine and dandy, but if I don’t implement the code the way I’ve dictated in my statement, then I will violate SRP, so how is it that I build a Swiss army knife while preserving my responsibility statement?  Enter code.

   1: public interface SwissArmyKnife

   2: {

   3:     ITool PullOutTool(ITool tool);

   4:     void PutAwayTool(ITool tool);

   5: 

   6:     IList Tools { get; }

   7: 

   8:     ITool ToolBeingUsed { get; set; }

   9: }

My interface defines any type of Swiss army knife I ever wish to make.  It’s only responsibility is to be able to use a tool that it has.  So then how do you use the Tool?  Well here’s how an ITool might look like:

   1: public interface ITool

   2: {

   3:     void Use();

   4: }

Now you can get any tool from the Swiss army knife and then use it.  Notice that it’s NOT the responsibility of the Swiss army knife to know HOW to USE the tool, only to get it out or put it away.

So what would violate SRP then?  Why did the author choose this particular product to harp on?  I think it was a matter of perspective really.  The article I read had numerous pictures of knives all decked out such as this one. Here is where I believe the real trickery is.  The author shows the pictures of all the swiss army knives with all the tools exposed.  If you really tried to use the knife like this, you would probably really screw up your hand!  That’s my point.  The knife is not of any use to anyone unless you’re using ONE tool at a time.  This is why SRP is not being violated.

You might take this a step further and say that you have a Swiss army Factory that would actually build the Swiss army knives, but that would be a discussion for another day.

Anyway, I hope everyone has found this interesting, till next time!

I just finished watching a variety of videos from Mike Taulty about learning Silverlight.  These are exceptionally good videos and I would suggest anyone that is trying to learn Silverlight OR Windows Presentation Foundation (WPF) to take a look at them. 

Here are links to all the videos.

1. Silverlight – Hello World
2. Silverlight – Anatomy of an Application
3. Silverlight – The VS Environment
4. Silverlight – Content Controls
5. Silverlight – Built-In Controls
6. Silverlight – Width, Height, Margins, Padding, Alignment
7. Silverlight – Using a GridSplitter
8. Silverlight – Grid Layout
9. Silverlight – StackPanel Layout
10. Silverlight – Canvas Layout
11. Silverlight – Databinding UI to .NET Classes
12. Silverlight – Simple Styles
13. Silverlight – Custom Types in XAML
14. Silverlight – Binding with Conversion
15. Silverlight – List Based Data Binding
16. Silverlight – Simple User Control
17. Silverlight – Templating a Button
18. Silverlight – Resources from XAP/DLL/Site Of Origin
19. Silverlight – Animations & Storyboards
20. Silverlight – Uploads with WebClient
21. Silverlight – Downloads with WebClient
22. Silverlight – Calling HTTPS Web Services
23. Silverlight – Calling Web Services
24. Silverlight – Making Cross Domain Requests
25. Silverlight – Using HttpWebRequest
26. Silverlight – File Dialogs and User Files
27. Silverlight – Using Sockets
28. Silverlight – Using Isolated Storage
29. Silverlight – .NET Code Modifying HTML
30. Silverlight – Using Isolated Storage Quotas
31. Silverlight – Calling JavaScript from .NET
32. Silverlight – Evaluating JavaScript from .NET Code
33. Silverlight – Handling HTML Events in .NET Code
34. Silverlight – Handling .NET Events in JavaScript
35. Silverlight – Calling .NET from JavaScript
36. Silverlight – Displaying a Custom Splash Screen
37. Silverlight – Passing Parameters from your Web Page
38. Silverlight – Loading Media at Runtime
39. Silverlight – Dynamically Loading Assemblies/Code
40. Silverlight – Reading/Writing XML
41. Silverlight – Multiple Threads with BackgroundWorker
42. Silverlight – Insert/Update/Delete with the DataGrid
43. Silverlight – Getting Started with the DataGrid
44. Silverlight – Embedding Custom Fonts

 Here are 5 common mistakes you should avoid when building sites that need to be Search Engine Optimized (SEO).

1. Overuse of Button Controls

The Button and LinkButton controls are handy for running server-side logic when a link or push button is clicked, but keep in mind that search engines can’t follow these links. These controls cause a postback via Javascript code that search engines are unable to execute.  I’ve seen more than one developer who’s standard method of linking from one page to another was to drag a LinkButton control onto the page and then place a Response.Redirect in the event handler, making the entire site completely uncrawlable by search engines.

2. Duplicate Page Titles

With any dynamically generated site, it can be difficult to generate unique page titles for each and every page, but it really is important.  If you have a quality site, then the search engines are working hard to drive traffic to your site.  After all, that is their core business – to provide links to the best resources on whatever the searcher is looking for. 

So you need to make it easy for the search engines to figure out exactly what your pages are about, and the page title is an important part of that.  Not only that, but once the search engine does rank your page highly, the title is the primary text that searchers will be seeing and using to determine whether to click on your listing or not!  

3. Duplicate Meta Descriptions

Much like the duplicate page title issue, the meta description tag should not be duplicated across your pages either.  Like the page title, this text is used (although to a lesser extent) by the search engines to determine the content of your page and also appears underneath your title in the search engine listing.  Depending on the number of pages of dynamic content on your site, it might not be practical to add multi-sentence descriptions for every single page.  In this case, simply remove the meta description tag altogether.  The major search engines are pretty good at improvising when the description tag is missing by displaying portions of the page body that match the user’s search keywords instead.

4. State-Dependent Pages

Search engines rely heavily on the idea that every unique page has it’s own unique URL.  That means that if you are basing a page’s content on session variables or viewstate parameters, you are probably going to have problems getting that content indexed.  Once a search engine finds a URL, Google will continue spidering that page, but you can bet that the search engine robot will not navigate through your site again to get there.  So you need to make sure that any content you want indexed by search engines can be accessed by simply opening your browser and typing in the URL of that content.  That means unique URLs for every product in your ecommerce store, ever category in your directory, etc. 

5. Duplicate Content When Rewriting URLs With ASP.NET

When you rewrite a URL, the browser is displaying a keyword-rich URL, but internally the URL of the page being displayed is still the ugly URL with the querystring parameters.  In technical terms, the Request.RawURL value might be something like:

1. http://www.store.com/products/coffee-cup.aspx

but the Request.Url value would still be something like:

1. http://www.store.com/products.aspx?productID=15  

All of that is just fine, but a problem can arise if you have a Button or LinkButton control that posts back on that page.  By default, the button control will post back to the Request.URL value. causing the URL to change after postback.  This can be a problem if some users end up linking to your ‘ugly’ URLs, because the search engines will find that link and spider it.  To the search engine the two different URLs signify two different pages and both will be indexed seperately, causing a pretty ugly duplicate content problem.  

 The original article that I read this from was on this blog

Have you ever found yourself lost inside some sort of block statement, wondering when the beginning of the block began or ended?  I just found this awesome feature in Visual Studio that allows me to jump to the beginning or ending of a block. 

To do this, put your cursor before or after the brace (your choice) and then press Ctrl+]. It works with either curly or round braces.

I originally found this nifty little feature from another blog ]]> http://josephbulger.com/technology/visual-studio-tip-jump-between-braces/feed/ 0