Blog

Posts written in August 2013.

  • Published on
    -
    2 min read

    A Jump Into Building A Kentico Site Using MVC!

    As of late, I've been attempting to expand my .NET web application development skills by learning MVC and now have the understanding on how it all works. By Jove, I think I’ve got it!

    After building a few small custom websites, I decided to utilise what I've learnt and start building a Kentico site in MVC. Ever since Kentico supported MVC Razor, I've been itching to try it out.

    The main drive to build a Kentico site in MVC for me has been the ability to easily build a complex site by separating an application into the model, the view, and the controller to give me a lot more control over how I want the application to be built. But the best part has to be the clean unadulterated HTML mark up that rendered on the page!

    I think the mark of a good web developer is based on not only how clean their HTML markup is but also (more importantly) their programming skills. But when visiting sites, we only get exposure to the HTML markup. Unfortunately, there's only so far you can go in cleaning the markup when building a site using Web Forms. Even with View state completely disabled and selectively using .NET controls the output can still be quite mucky.

    As a web developer, whenever I visit a site that interests me from a technical level, I often look at the HTML mark up just to see how clean it is. I'm always intrigued to see if a site that looks and functions great is built just as well as it looks.

    But I digress...

    Kentico's support for MVC is definitely impressive. I felt quite at home when moving from a custom MVC web build to a Kentico build. Of course, there are some differences in terms of where your Models, Views and Controllers reside within the file structure of your website.

    If you plan on building a Kentico site using MVC, take a look at this post by Martin Hejtmanek who gives a basic overview on the steps required to get you up and running.

    From what I have built so far, I haven't noticed any limitations in the MVC framework. Just workarounds are required for some features (which I'll detail in future blog posts).

    Question Raised...

    As much as I like having the option of building an MVC site in Kentico, I ask myself the question: In reality, how many sites I build will actually be in MVC?

    The reason why I ask this is because Kentico provides many useful ready to use features out-the-box, a website could be built in half the time of an MVC build. Just think of the number of web parts Kentico has freely available to use!

    You couldn't justify to a paying client the additional time and cost will create a more scalable website that produces cleaner HTML markup. For smaller websites, an MVC site in Kentico could potentially be viable and any custom controls you do make (such as pagination and login controls) could be rolled out across future sites.

    Nevertheless, I'm hoping to do more MVC in Kentico moving forward.

  • Ever since Twitter ditched version 1 of their API to version 1.1, an additional hurdle created when attempting to get any data from Twitter. Authentication (using OAuth) is now required on all API request endpoints. I can see why Twitter decided to go down this route but it does add a little headache when carrying out the most simplest requests.

    In all the sites I have worked on, I've always relied on third party libraries to help me interact with Twitter, such as Twitterizer (no v1.1 support) and TweetSharp. But due to the increased complexity on some of the sites I've been working on, third party libraries don't seem to cut the mustard any more. A more scalable solution is required...

    I came across a really simple and expandable class library called OAuthTwitterWrapper that stemmed from a StackOverflow question I found. Out-of-the-box, this library contains calls required to retrieve a user's timeline and return searches which is great to get you up and running quickly.

    The OAuthTwitterWrapper provided me a really good basis to add further Twitter features, for example a list of users favourite tweets.

    If you don't plan on doing anything too complex when interacting with the Twitter API, third party libraries such as TweetSharp will meet your everyday needs. However, if you want more control over how you make requests, the OAuthTwitterWrapper provides a good foundation.