Undisciplined Bytes http://www.undisciplinedbytes.com Web Application Development Tips, Tricks and Techniques Tue, 09 Mar 2010 14:56:18 +0000 http://wordpress.org/?v=2.8.4 en hourly 1 AJAX call using an ASP.NET web page http://www.undisciplinedbytes.com/2010/03/ajax-call-using-an-asp-net-web-page/ http://www.undisciplinedbytes.com/2010/03/ajax-call-using-an-asp-net-web-page/#comments Tue, 09 Mar 2010 14:56:18 +0000 Oliver Mezquita http://www.undisciplinedbytes.com/?p=336 We already saw what an AJAX call is and the different types there are. Today we’re going to see how to perform an AJAX call using a regular web page at the server. The page will be the connection between the client’s web browser and the server. It will take care of performing the operations at the server (let it be some kind of processes or calculations, or just a regular database access).

I’ll be using jQuery in this example. jQuery is a superb Javascript framework, and is the one I use the most. If you don’t know what it is yet, then the first thing you should do is getting acquainted with it. This JavaScript framework has many convenient functions to make an AJAX call. These functions hide much of the complexity of an AJAX call: you can forget about the XMLHttpRequest object if you wish, and only worry about what to do with the data once you get it back from the server.

So, in order to perform an AJAX request, we’ll follow these steps:

  1. We’ll perform an AJAX call from the client, using Javascript. As I said before, we’ll be using jQuery. It makes the process much easier.
  2. We’ll construct some way for the server to receive the request: in this example we’ll use a regular .aspx web page.
  3. We’ll fetch the data to be returned to the client. This example is just a proof of concept, so we’ll leave this task to the reader. We’ll just return the server time.
  4. We’ll convert that data into JSON notation.
  5. Once the data gets back to the client, the jQuery library takes care of the conversion of the string received from the server to a Javascript object.
  6. In this point we’ll have the data available to us. We’ll do something with it to show it on screen, for example.

Ok, we already have the theory covered. Now, let’s get to work! Start a new Visual Studio project, and get to the newly created page. On the C# codebehind of the new page we won’t be changing anything. Leave everything by default. We’ll be doing our work in the .aspx part. First, we’ll need a little bit of HTML to draw our page:

<body>
   <form id="form1" runat="server">
     <h2>jQuery AJAX call test page</h2>
     <button type="button" onclick='ExecuteAJAXCall()'>Get server time</button>
     <br /><br />
     <div id="DataContainer" ></div>
   </form>
</body>

This is a very simple page. We’ll just have a heading, a button to perform the AJAX call, and an empty DIV to hold the data retrieved from the server.

Now we need some actual code to make the AJAX call:

<script type="text/javascript">

    function ExecuteAJAXCall() {
        $.ajax({
            url: "AJAXCall.aspx",
            dataType: 'json',
            success: Callback_AJAXCall
        });
    };

    function Callback_AJAXCall(data) {
        document.getElementById("DataContainer").innerHTML = "The time at the server is: " + data;
    };

</script>

Note that the first function is invoked when the button is pressed. This function is in charge of performing the AJAX call by using the jQuery framework. We’re passing three parameters to the function: the URL of the page that will get called, they type of data we’re expecting back (JSON in this case) and the javascript function to execute once the data gets back to the client. The jQuery ajax function has many more parameters, but we didn’t need them this time since the example is not very complicated.

The function called when the data is returned is very simple: its only purpose is to take the string returned from the server and write it in the container we previously created for this purpose. Note that the parameter it receives, data, is already a javascript object. The AJAX call returned a simple string from the server, but the jQuery function is smart enough to convert that string to a javascript object and pass it to the function we indicated.

Ok, so now that we have the test page in place, let’s deal with the AJAX call server-side. The AJAXCall.aspx page is the link between the client web browser and the server. Here we’ll process everything we need and we’ll return a string to the client with the data requested.

Here is the C# codebehind from the AJAXCall.aspx page:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.Script.Serialization;

namespace jQueryAJAXCall
{
    public partial class AJAXCall : System.Web.UI.Page
    {
        protected void Page_Load(object sender, EventArgs e) // Returns the server current date and time
        {
            JavaScriptSerializer JSSerializer = new JavaScriptSerializer();
            string CurrentDate = DateTime.Now.ToString();
            Response.CacheControl = "no-cache";
            Response.Write(JSSerializer.Serialize(CurrentDate));
        }
    }
}

Note the System.Web.Script.Serialization class we’re importing. This class takes care of converting the object we want to return to JSON format.

This page is very simple: it just takes the current date and time from the server, converts it to JSON format and returns it. Nothing more is needed. Simple enough, right? Be aware that this page must not return anything else than the JSON string: if you’re using Visual Studio be careful when creating this new webpage, as VS adds a bunch of HTML code by default in the .aspx page. Erase all HTML code, otherwise your javascript won’t be able to understand the data sent back.

Note the line in which we deactivate the cache. If you don’t do this, the AJAX call will always seem to return the same data, as the web browser will have kept a copy of it the first time it was executed. Most AJAX calls need the cache disabled in order to work properly.

So this is it! Nothing else is required. Donwload the Visual Studio project and play with it as much as you want:

jQueryAJAXCall.zip

Related posts:

  1. Different ways to use AJAX in ASP.NET

]]> http://www.undisciplinedbytes.com/2010/03/ajax-call-using-an-asp-net-web-page/feed/ 0 Different ways to use AJAX in ASP.NET http://www.undisciplinedbytes.com/2010/02/how-to-make-an-ajax-call-using-jquery-and-asp-net-i/ http://www.undisciplinedbytes.com/2010/02/how-to-make-an-ajax-call-using-jquery-and-asp-net-i/#comments Tue, 23 Feb 2010 14:53:34 +0000 Oliver Mezquita http://www.undisciplinedbytes.com/?p=314 Today’s web applications are unthinkable without AJAX techniques. These techniques provide an improved user experience, and tighten the gap between traditional desktop applications and web applications. This means that mastering AJAX technologies is a must for anyone who’s doing serious web application development. In this article I’ll explain the basics of AJAX, and I will show how to program some AJAX calls using ASP.NET technology.

First things first: the basics

AJAX is a set of web application development techniques used to create RIA (Rich Internet Applications). These techniques are used in the web browser at the client’s computer, while an asynchronous communication with the web server is held in the background. Thus, it is possible to make changes in the pages without the need to reload them, increasing interactivity, speed and usability in these applications, compared to traditional click-and-wait web pages.

An AJAX call is nothing more than a request to the server for some data. It is the same thing as when you type in a web page address in your browser’s address box and hit Enter: your browser requests the server the HTML code representing that webpage. The only difference is that with an AJAX call, all this process takes place in the background, without the user’s knowledge. It is performed programmatically, using JavaScript.

AJAX stands for Asynchronous JavaScript and XML, which means that in its first conception XML was used to transmit data from the server to the client. But XML is not used much anymore, JSON is the preferred notation for this task. JSON is a lighter notation as it uses less characters, and follows the natural syntax of the JavaScript language. This means that, once you’ve received the data from the server in your JavaScript code, it is much simpler and faster to process it if it’s in JSON notation.

Let’s see a couple of examples to understand it better. This would be XML:

<Person firstName="John" lastName="Smith">
    <address>
      <streetAddress>21 2nd Street</streetAddress>
      <city>New York</city>
      <state>NY</state>
      <postalCode>10021</postalCode>
    </address>
    <phoneNumber type="home">212 555-1234</phoneNumber>
    <phoneNumber type="fax">646 555-4567</phoneNumber>
    <newSubscription>false</newSubscription>
    <companyName />
</Person>

And this would be the same data transmitted in JSON notation:

{
       "firstName": "John",
       "lastName": "Smith",
       "address": {
           "streetAddress": "21 2nd Street",
           "city": "New York",
           "state": "NY",
           "postalCode": 10021
       },
       "phoneNumbers": [
           { "type": "home", "number": "212 555-1234" },
           { "type": "fax", "number": "646 555-4567" }
       ],
       "newSubscription": false,
       "companyName": null
}

As you can see XML is lengthier to transmit. Besides, as it is not natural to JavaScript, the data must be interpreted and translated to a JavaScript object once it gets to the client, whereas JSON must not. Don’t worry though, you won’t have to deal with converting data to JSON and back, all this is done automatically.

Different ways of requesting data from the web server

There are several different techniques used to retrieve data from the server using ASP.NET technology. The most common ones are:

  • URL. This is the most used technique to provide data through AJAX. Most JavaScript plugins are designed to work this way, so it can be considered the most important technique as well. At the server, this type of request can be processed using two different approaches:
    • The request is processed as if it was a regular web page
    • The request is processed through an HTTP Handler
  • Page method. Server methods can be easily called just by using an attribute.
  • Web service. Web services can be consumed from JavaScript, providing for an easy way to request data to the server.
  • Web sockets. Not quite AJAX itself, web sockets are here to revolutionize the logic behind traditional client-server communication. Web sockets bring full-duplex and server-initiated communications, two techniques not possible in the web till now. They belong to the new HTML5 specification, and as such must be treated, meaning there’s not much support for it yet.

We’ll be taking a look at each of these techniques. Stay tuned!

Related posts:

  1. AJAX call using an ASP.NET web page
  2. jQuery Grid plugin: jqGrid

]]> http://www.undisciplinedbytes.com/2010/02/how-to-make-an-ajax-call-using-jquery-and-asp-net-i/feed/ 0 PHP or ASP.NET? http://www.undisciplinedbytes.com/2010/02/php-or-asp-net/ http://www.undisciplinedbytes.com/2010/02/php-or-asp-net/#comments Tue, 09 Feb 2010 14:58:22 +0000 Oliver Mezquita http://www.undisciplinedbytes.com/?p=234 The other day a friend of mine was telling me he was going to start a new project. He wanted to develop a new web app from scratch, and was telling me he was going to use PHP. He did have experience with ASP.NET from some other projects, so I told him to use this technology. But he still preferred PHP. The reasons he gave me were:

  1. PHP is free. You do not have to pay to use it. With ASP.NET you need to pay a whole bunch of licenses.
  2. PHP runs faster than ASP.NET.
  3. PHP hosting is cheaper.
  4. Out there on the internet, you can see more PHP than ASP.NET applications.
  5. There’s more CMS on PHP than on ASP.NET.

Ok, he had his reasons, but I didn’t fully agree with him. So I discussed some of those ideas with him:

  1. Yes, PHP is free, like ASP.NET. Well, at least for basic stuff. I mean, the core of ASP.NET is standardized, which means that anyone can develop a compiler/server for these specifications. As a matter of fact, the Mono Project aims to develop alternative components to replace Microsoft’s products. So far, they have released an implementation of the .NET runtime, a .NET development environment, and much more stuff. You can read more about this on Mono FAQ.
    Besides, if you don’t like MonoDevelop, you can still use the free version of Microsoft’s Visual Studio: Visual Web Developer. It’s pretty much the same thing, only designed to be used just by one person coding by himself.
  2. PHP is an interpreted script, while ASP.NET applications are compiled. This means that ASP.NET is way faster than PHP. Yes, you could still use some techniques to accelerate PHP (like caching), but those same techniques can be applied to ASP.NET as well, making it even faster. If you want facts, you can take a look at this comparison.
  3. Well, it depends. If you’re talking about installing your application in your own server, then you might need to install some windows server and IIS, and both of them cost money. Actually, Windows does cost money, but IIS is already included in the most recent versions. But, as I said before, the Mono Project provides some free alternative to that.
    If you’re talking about deploying your web app in some external hosting and paying a monthly fee, then it is not more expensive at all. I’ve found similar offers in both technologies… it’s not even hard to find free external hosting for both platforms – although that might not be the best experience, depending on your needs.
  4. So? Other people might have some other different reasons. Or maybe they want to adopt the cheapest platform and they just don’t know that ASP.NET is standardized and that there’s open source solutions for this technology as well.
  5. He might be right, the number of CMS implemented with PHP might be greater than those that use ASP.NET. But that doesn’t mean they’re better. In order to choose a CMS for your project, you should compare some of them and decide which one better fits your needs. And you can find almost identical functionality on CMS from both platforms.

But I still had some more points to add:

  • Although many of them are not free, there’s a bunch of pre-programmed controls and components you can incorporate in your web app in ASP.NET (some of them are really impressive). And many of them don’t require much effort from your part… just drag&drop the component on your web app and you’re done. You can even develop your own highly-complex, highly-reusable web app controls and share them among many different apps in just a matter of minutes. This is especially useful for GUI widgets.
  • By having full access to the .NET Framework, your ASP.NET application can have all the power of any Windows app.
  • PHP is a single threaded application, while .NET framework supports multi-threading. In a highly loaded app, this can make a huge difference.

I know this discussion has been going on ever since ASP.NET was first released… but I’d say that asking whether PHP or ASP.NET is better just doesn’t make sense. There’s no such thing as the best language. The language you should use is the one that fits your needs best in the least amount of time. For some people it will be ASP.NET, and for others it will be PHP.

Still, I consider the ASP.NET platform an important skill every web application developer should have. But still, the whole point here is that you can find enough reasons to prefer or dislike any of these platforms… so it just comes down to personal preferences and project requirements.

]]> http://www.undisciplinedbytes.com/2010/02/php-or-asp-net/feed/ 0 Sluggish database view? Materialize it! http://www.undisciplinedbytes.com/2010/01/sluggish-database-view-materialize-it/ http://www.undisciplinedbytes.com/2010/01/sluggish-database-view-materialize-it/#comments Tue, 26 Jan 2010 14:59:29 +0000 Oliver Mezquita http://www.undisciplinedbytes.com/2010/01/sluggish-database-view-materialize-it/ The other day we were having some slow database view at our project. It was the main view of the new module we were developing, and it was slowing down the whole application to an unacceptable point. It was a rather complex view and could not be optimized much more. So, what was the solution we adopted? We materialized the view.

Regular views store just the SQL script needed to retrieve the data, and every time they are consulted the stored SQL query is executed. However, materialized views not only store the script, but the retrieved records as well, making it much faster.

As with regular views, the SQL script defines which data is to be retrieved. However, with materialized views this script is executed when the view is first created, and the result is physically stored in a real table. From then on, when the materialized view is accessed, the DBMS transforms the SQL sentence targeting this table instead of the more expensive procedure of actually querying all elements involved in the SQL sentence.This table can be defined with the same storage parameters used for regular tables (tablespace, etc.). Indexes can be used for materialized views as well, improving the performance even more.

Obviously, the greater the number of tables used, the more benefits we’ll get by using a materialized view. In our project, we were accessing 15 tables: we cut the execution time from 4 seconds to 100 ms by implementing a materialized view… this means that execution was 40 times faster!!! Now, that’s what I call optimization!

However, when designing a materialized view you need to keep in mind that it’s actually going to become a table with static data… and you need to specify when and how that data is going to be updated. Not taking this into account might lead the application to display outdated or incorrect data. This means that we need to evaluate the benefits and drawbacks we’ll get by using a materialized view: it might as well turn out that it slows down the whole system. So I encourage you to do some design and testing before actually deploying the view into production environment.

How to build a Materialized view in Oracle

This is the command used to create materialized views:

CREATE MATERIALIZED VIEW materialized_view_name
 [TABLESPACE ts_name]
 [PARALELL (DEGREE n)]
 [BUILD {INMEDIATE|DEFERRED}]
 [REFRESH {FAST|COMPLETE|FORCE|NEVER|ON COMMIT}]
 [{ENABLE|DISABLE} QUERY REWRITE]
AS SELECT ... FROM ... WHERE ...

The Build parameter

If you choose the BUILD INMEDIATE option, the table associated with the materialized view will be populated with data at creation time. On the contrary, if you’d rather have the table populated in the moment when the first access to the view is performed, then use the BUILD DEFERRED option.

The Refresh parameter

This option indicates the mechanism Oracle will use to update the table representing the materialized view. There quite a few options here, and I would say it’s one of the most important considerations when building a materialized view. I will write a new article explaining the different updating approaches we can use to implement these views.

The Query Rewrite parameter

The ENABLE/DISABLE QUERY REWRITE option indicates whether the Oracle optimizer is allowed to rewrite SQL sentences in a way in which the materialized view will be used in the execution phase instead of the base tables included in the original SQL sentence. This is a rather complex subject, and I will dedicate a post dealing with it.

Other DBMS

This article focused on Oracle’s Materialized Views. But most DBMS implement some kind of view optimization these days. In case you’re using some other DBMS, you might be interested in searching for:

  • Microsoft SQL Server: Indexed views.
  • DB2: Materialized query table.
  • Some other DBMS (for example MySQL and PostgreSQL) don’t have such a feature, but you can implement your own manually using triggers.

Further reading

]]> http://www.undisciplinedbytes.com/2010/01/sluggish-database-view-materialize-it/feed/ 0 Software design patterns (IV): behavioral patterns http://www.undisciplinedbytes.com/2010/01/software-design-patterns-iv-behavioral-patterns/ http://www.undisciplinedbytes.com/2010/01/software-design-patterns-iv-behavioral-patterns/#comments Tue, 12 Jan 2010 15:01:57 +0000 Oliver Mezquita http://www.undisciplinedbytes.com/?p=298 We’ve already been through a brief introduction to design patterns, and a description of the most important creational design patterns and structural design patterns. In this article we’ll take a look at the last category of design patterns: behavioral patterns.

Behavioral design patterns are concerned with the relationships among communications using different objects. They identify common communication patterns and provide a well-known solution to implement this communication, offering a higher degree of flexibility.

The most used behavioral patterns are:

Chain of responsibility

The Chain of responsibility Pattern can be used when there is a potentially high number of processing elements, and a stream of requests must be handled in different ways. Each request will be processed by different elements.

This pattern is implemented by encapsulating the processing elements inside a pipeline abstraction, and have objects launch and leave their requests at the entrance to the pipeline. The pattern chains the receiving objects together, and then passes any request messages from object to object until it reaches an object capable of handling the message.

Chain of Responsibility simplifies object interconnections. Instead of senders and receivers maintaining references to all candidate receivers, each sender keeps a single reference to the head of the chain, and each receiver keeps a single reference to its immediate successor in the chain

Command

The Command Pattern can be used when there is a need to issue requests to objects without knowing anything about the operation being requested or the receiver of the request.

Command decouples the object that invokes the operation from the one that knows how to perform it. To achieve this separation, the designer creates an abstract base class that maps a receiver (an object) with an action (a pointer to a member function). The base class contains an execute() method that simply calls the action on the receiver. All clients of Command objects treat each object as a “black box” by simply invoking the object’s virtual execute() method whenever the client requires the object’s “service”.

Command objects can be thought of as “tokens” that are created by one client that knows what needs to be done, and passed to another client that has the resources for doing it.

Interpreter

The Interpreter Pattern can be used when we’re facing a class of problems that occurs repeatedly in a well-defined and well-understood domain. If the domain were characterized with a “language”, then problems could be easily solved with an interpretation “engine”.

The Interpreter pattern discusses: defining a domain language (i.e. problem characterization) as a simple language grammar, representing domain rules as language sentences, and interpreting these sentences to solve the problem. The pattern uses a class to represent each grammar rule. And since grammars are usually hierarchical in structure, an inheritance hierarchy of rule classes maps nicely.

An abstract base class specifies the method interpret(). Each concrete subclass implements interpret() by accepting (as an argument) the current state of the language stream, and adding its contribution to the problem solving process.

Iterator

The Iterator Pattern can be used when there’s a need to “abstract” the traversal of very different data structures so that algorithms can be defined that are capable of interfacing with each transparently.

An aggregate object such as a list should give you a way to access its elements without exposing its internal structure. Moreover, you might want to traverse the list in different ways, depending on what you need to accomplish. But you probably don’t want to bloat the List interface with operations for different traversals, even if you could anticipate the ones you’ll require. You might also need to have more than one traversal pending on the same list. And providing a uniform interface for traversing many types of aggregate objects (i.e. polymorphic iteration) might be valuable.

The Iterator pattern lets you do all this. The key idea is to take the responsibility for access and traversal out of the aggregate object and put it into an Iterator object that defines a standard traversal protocol.

Mediator

When you have a big number of objects interacting among them, a rather complex structure might be formed. It can become so complex that trying to reutilize some functionality might show the spaghetti code phenomenon: trying to scoop a single serving results in an all or nothing clump. To avoid this, the Mediator Pattern encapsulates the behavior of the whole group in a single object.

Partitioning a system into many objects generally enhances reusability, but proliferating interconnections between those objects tend to reduce it again. The mediator object encapsulates all interconnections, acts as the hub of communication, is responsible for controlling and coordinating the interactions of its clients, and promotes loose coupling by keeping objects from referring to each other explicitly.

In this pattern, peers are not coupled to one another. Each one talks to the Mediator, which in turn knows and conducts the orchestration of the others. The many to many mapping between colleagues that would otherwise exist, has been promoted to full object status. This new abstraction provides a locus of indirection where additional leverage can be hosted.

Memento

The Memento Pattern can be used when you need to restore an object back to its previous state (undo or rollback operations).

The client requests a Memento from the source object when it needs to checkpoint the source object’s state. The source object initializes the Memento with a characterization of its state. The client is the “care-taker” of the Memento, but only the source object can store and retrieve information from the Memento (the Memento is “opaque” to the client and all other objects). If the client subsequently needs to “rollback” the source object’s state, it hands the Memento back to the source object for reinstatement.

An unlimited undo and redo capability can be readily implemented with a stack of Command objects and a stack of Memento objects.

Observer

The Observer Pattern can be used when a large monolithic design does not scale well as new graphing or monitoring requirements are requested.

Define an object that is the “keeper” of the data model and/or business logic (the Subject). Delegate all “view” functionality to decoupled and distinct Observer objects. Observers register themselves with the Subject as they are created. Whenever the Subject changes, it broadcasts to all registered Observers that it has changed, and each Observer queries the Subject for that subset of the Subject’s state that it is responsible for monitoring.

This allows the number and “type” of “view” objects to be configured dynamically, instead of being statically specified at compile-time.

Further reading

]]> http://www.undisciplinedbytes.com/2010/01/software-design-patterns-iv-behavioral-patterns/feed/ 1 Software design patterns (III): structural patterns http://www.undisciplinedbytes.com/2010/01/software-design-patterns-iii-structural-patterns/ http://www.undisciplinedbytes.com/2010/01/software-design-patterns-iii-structural-patterns/#comments Tue, 05 Jan 2010 18:58:16 +0000 Oliver Mezquita http://www.undisciplinedbytes.com/?p=261 We already saw what design patterns are and took a look at creational patterns in earlier articles. Today we’ll deal with the second category: structural patterns.

These design patterns are all about class and object composition. Class-creation patterns use inheritance to compose interfaces, whilst object patterns define ways to compose objects to obtain new functionality. All of these patterns aim to ease the design by identifying a simple way to realize relationships between entities.

The most common structural patterns are:

Adapter

An off the shelf component may offer interesting functionality that you may want to reuse, but its view of the world is not compatible with the philosophy and architecture of the system currently being developed. This is where the Adapter Pattern steps in.

This pattern is about creating an intermediary abstraction that translates, or maps, the old component to the new system. Clients call methods on the Adapter object, which redirects them into calls to the legacy component.

Bridge

The Bridge Pattern decomposes the original component’s interface and implementation into different class hierarchies. The interface class contains a pointer to the abstract implementation class. This pointer is initialized with an instance of a particular implementation class, but all subsequent interaction from the interface class to the implementation class is limited to the abstraction maintained in the implementation base class. The client interacts with the interface class, and it in turn “delegates” all requests to the implementation class.

The interface object is the handle known and used by the client. The implementation object, or body, is encapsulated to ensure that it may continue to evolve, or be entirely replaced.

Composite

The Composite Pattern might be used when an application needs to manipulate a hierarchical collection of objects of different types: different types of objects are handled in different ways, and querying the type of each object before processing it is not desirable.

This pattern is implemented by defining an abstract base class that specifies the behavior that needs to be performed upon all primitive and composite objects. Then, primitive and composite classes must be subclassed off of the Component class. Each composite object couples itself only to the abstract type component.

This pattern should be used when you have composites that contain components, each of which could be a composite.

Decorator

The Decorator Pattern can be used when a particular behavior or state must be applied to individual objects at run-time – in this case inheritance cannot be used because it is static.

The original object must be encapsulated inside an abstract wrapper interface, from which both the core and the decorator object inherit. The interface then uses recursive composition to allow an unlimited number of decorator layers to be added to each core object.

Note that this pattern allows functionality to be added to an object, not methods to an object’s interface. The interface presented to the client must remain constant as successive layers are specified.

Facade

When a segment of the client community needs a simplified interface to the overall functionality of a complex subsystem, you can use the Facade Pattern: this kind of software design encapsulates a complex subsystem within a single interface object.

The Facade Pattern defines a unified, higher level interface to a subsystem that makes it easier to use. This way, the learning curve necessary to successfully leverage the subsystem is reduced. It also promotes decoupling the subsystem from its potentially many clients. On the other hand, if the Facade is the only access point for the subsystem, it will limit the features and flexibility that power users might need.

Flyweight

The Flyweight Pattern is designed to solve problems related to granularity and performance: use it when designing objects down to the lowest levels of system granularity, with those objects being extremely expensive in terms of performance.

This pattern describes how to share objects to allow their use at fine granularities without prohibitive cost. Each Flyweight object is divided into two pieces: intrinsic (stateless) and extrinsic (state-dependent). Intrinsic state is stored in the Flyweight object. Extrinsic state is stored or computed by client objects, and passed to the Flyweight when its operations are invoked.

Flyweights are stored in a Factory’s repository. The client doesn’t create Flyweights directly, but requests them from the Factory. Each Flyweight cannot stand on its own. Any attributes that would make sharing impossible must be supplied by the client whenever a request is made of the Flyweight. The Flyweight uses sharing to support large numbers of objects efficiently.

Proxy

If you need to support resource-hungry objects, and you do not want to instantiate them unless and until they are absolutely necessary, you can use the Proxy Pattern.

The Proxy object instantiate some real object the first time the client makes a request of the proxy, remembers the identity of this real object, and forwards the request to it. Then, all subsequent requests are simply forwarded directly to the encapsulated real object. Implemented as an interface, the presence of the Proxy object standing in place of the real object is transparent to the client.

Continue reading Software design patterns (IV): behavioral patterns »

Further reading

Related posts:

  1. Software design patterns (II): creational patterns
  2. Software design patterns (IV): behavioral patterns
  3. Software design patterns (I)

]]> http://www.undisciplinedbytes.com/2010/01/software-design-patterns-iii-structural-patterns/feed/ 1 Software design patterns (II): creational patterns http://www.undisciplinedbytes.com/2009/12/software-design-patterns-ii-creational-patterns/ http://www.undisciplinedbytes.com/2009/12/software-design-patterns-ii-creational-patterns/#comments Tue, 15 Dec 2009 15:01:42 +0000 Oliver Mezquita http://www.undisciplinedbytes.com/?p=246 In an earlier article we saw what design patterns are and how they can help us. Today we’re going to take a look at the first category: creational patterns.

Creational design patterns deal with class creation and instantiation, and how to use those instances. Basic class creation could result in design problems or added complexity to the design. These patterns solve these problems by controlling this object creation.

Some examples of creational design patterns:

Abstract factory

The Abstract Factory Pattern implements a new level of abstraction in charge of creating families of related or dependent objects without directly specifying their concrete classes. The Factory object provides creation services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them.

This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application – where it is instantiated. The application can replace the entire family of products simply by instantiating a different instance of the abstract factory.

Builder

The Builder Pattern separates the algorithm for interpreting a stored persistence mechanism from the algorithm for building and representing one of many target products. The focus is on creating highly-complex objects.

This pattern affords finer control over the construction process. Unlike creational patterns that construct products in one shot, the builder pattern constructs the product step by step.

Factory Method

The Factory Method pattern is the standard way to create objects. It is similar to the Abstract Factory, but without the emphasis on families. This pattern defines an interface for creating an object, but defers the actual creation to subclasses. A superclass specifies all standard and generic behavior, and delegates the creation details to subclasses that are supplied by the client.

Factory Methods are routinely specified by an architectural framework, and then implemented by the user of the framework.

Object Pool

The Object Pool pattern lets others “check out” objects from its pool, and when those objects are no longer needed by their processes, they are returned to the pool in order to be reused.

We don’t want processes to be idle waiting for a particular object to be released, so the Object Pool also instantiates new objects as they are required. Furthermore, this pattern must also implement a facility to clean up unused objects periodically.

Prototype

The Prototype pattern creates new instances of an object by cloning others already in used, rather than by actually creating a new one. To do so, an abstract class must be declared specifying a pure virtual clone() method. Any class that needs a polymorphic constructor capability derives itself from the abstract base class, implementing the clone() operation.

The client then, instead of writing code that invokes the new() operator, calls a clone() operation on the abstract base class, indicating the particular concrete derived class desired.

Singleton

The Singleton pattern is used when the application needs one, and only one, instance of an object. By using this pattern, a global access point to the instance is provided, and the instance is created when the first access is made.

When choosing which ones to use, keep in mind that sometimes creational patterns are complementary, so you might be able to use more than one of these.

Further reading

Related posts:

  1. Software design patterns (III): structural patterns
  2. Software design patterns (I)
  3. Software design patterns (IV): behavioral patterns

]]> http://www.undisciplinedbytes.com/2009/12/software-design-patterns-ii-creational-patterns/feed/ 5 Software design patterns (I) http://www.undisciplinedbytes.com/2009/12/software-design-patterns-i/ http://www.undisciplinedbytes.com/2009/12/software-design-patterns-i/#comments Tue, 08 Dec 2009 15:01:03 +0000 Oliver Mezquita http://www.undisciplinedbytes.com/?p=243 Design patterns are solutions to common software development problems, and aim to facilitate the development of a software project. A solution must have proven effectiveness and be highly reusable (can be applied to different design problems in different circumstances) to become a design pattern.

A pattern describes a problem that happens over and over again in our environment, and then explains the core of the solution to that particular problem. Since it is just a scheme of the solution, the application of this pattern is not literal: it requires adaptation. You could use the same pattern a thousand times, and never repeat the way you applied it.

Software design patterns aim to:

  • Provide reusable elements in the design of software projects
  • Avoid spending time in the search of a solution to well-known and previously solved problems
  • Standardize the process of designing software applications
  • Facilitate the learning process of new generations of software developers and designers

Software design patterns are not used for:

  • Imposing some alternatives against others: there are plenty of design patterns out there, and the software engineer must compare all of them and choose the one that best suits the needs of the project, if any at all.
  • Erase the creativity inherent to software design: these patterns are a just a guide to an easier design process, a set of advices to follow. Developers can choose to either follow these rules or adapt them to better fit requirements.

These patterns are only recommended in case we’re facing a similar problem that the pattern addresses, having always in mind that it could just not be applied to our particular case. Abusing or forcing the use of design patterns can be a mistake.

In brief, a pattern is a common structure that similar applications have. This happens in all levels of life. For example, in our ordinary life we apply the pattern “greeting – introduction– message – farewell” in many different occasions. If you don’t think patterns are useful, then try to use the scheme “farewell – message – introduction – greeting” and see what happens.

The most widespread catalogue of design patterns can be found in the book Design Patterns: Elements of Reusable Object-Oriented Software, from Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides (1995, Addison-Wesley), AKA GOF (Gang-Of-Four). According to this book, design patterns can be categorized regarding the purpose they have been defined for:

  • Creational patterns: solve instance creation problems. They help in encapsulating and abstracting these creations.
  • Structural patterns: solve class and object composition problems.
  • Behavioral patterns: solve problems about interaction and responsibilities among classes and objects.

Software design patterns are usually easy to understand. What might get you more headaches might be using them. They really help and make software development less problematic, so it is very important to get to know some of them. I’ll mention some of them in the next few posts.

Further reading

Related posts:

  1. Software design patterns (II): creational patterns
  2. Software design patterns (III): structural patterns
  3. Software design patterns (IV): behavioral patterns

]]> http://www.undisciplinedbytes.com/2009/12/software-design-patterns-i/feed/ 5 CSS 3: one more step in the evolution of the web http://www.undisciplinedbytes.com/2009/12/css-3-one-more-step-in-the-evolution-of-the-web/ http://www.undisciplinedbytes.com/2009/12/css-3-one-more-step-in-the-evolution-of-the-web/#comments Tue, 01 Dec 2009 15:01:41 +0000 Oliver Mezquita http://www.undisciplinedbytes.com/2009/12/css-3-one-more-step-in-the-evolution-of-the-web/ CSS 2 was released in 1997, and after more than 10 years it needs to be updated to reflect the new uses and trends we’ve been seeing in the web. This new version of Cascading Style Sheets brings new features long awaited that will make web development easier. Alongside with HTML 5, this new version represents the evolution of the web, and aims to take the concept of semantics into the core of the web.

CSS 3 has quite a few new concepts. Let’s take a look:

New properties

  • Borders: border-color, border-image, border-radius, box-shadow.
  • Backgrounds: background-origin, background-clip, background-size, layering multiple background images.
  • Color: HSL colors, HSLA colors, RGBA colors opacity.
  • Text: text-shadow, text-overflow.
  • Interface: box-sizing, resize.
  • Selectors: attribute selectors.
  • Formats: media queries, multiple column layout, speech.

New features

Using these new properties we’ll be able to achieve things such as:

  • Borders, background
    CSS 3 will allow images for borders, round corners and shadows. Objects can not only be positioned, but its direction can also be changed (horizontal or vertical).
  • Multi-column layout
    Designing pages with multiple columns now will be easier than ever. Until now we needed to enclose the content in two separate DIVs to simulate a two-column layout; now we’ll just use column-count: 2. Not all that hard, right?
  • Advanced Layout
    This new feature will allow objects to be distributed along the screen in a better an easier way, and combine them in different manners without additional tags. Besides, the page model will be included: this means that we will be able to indicate page footers, crossed references, and section headers.
  • Selectors
    There are new selectors to make it easier locating exactly the element you want:
    E:only-of-type: an element which is unique in its type.
    E:not(s): an element which doesn’t match simple selector.
    E ~ F: an element F with an element E right before.
    E:nth-child: the n-th child element of a parent node. With this selector we’ll be able to implement things such as zebra tables.
    E:nth-last-child: the last child element from a parent node.
    E:nth-of-type: the n-th element which is of a certain type.
    E:first-of-type: the first element which is of a certain type.
  • Resizing
    Up till now, if we wanted our elements to be resizable we needed to use Javascript to alter its attributes. With CSS 3 it will now be a task of the browser, just by using the resize property.
  • And many more things …

Some properties of CSS 3 are already being implemented in most major browsers. There’s not a 100% fully compliant web browser yet (specially because CSS 3 is not finished yet), but it won’t take much time to have one. This means that maybe we won’t be able to use all of these new features right now, but we can certainly start using some of them. So, what are you waiting for? The sooner the better!

Further reading

Related posts:

  1. HTML 5: dramatic improvements in the web language

]]> http://www.undisciplinedbytes.com/2009/12/css-3-one-more-step-in-the-evolution-of-the-web/feed/ 0 HTML 5: dramatic improvements in the web language http://www.undisciplinedbytes.com/2009/11/html-5-dramatic-improvements-in-the-web-language/ http://www.undisciplinedbytes.com/2009/11/html-5-dramatic-improvements-in-the-web-language/#comments Tue, 24 Nov 2009 15:00:23 +0000 Oliver Mezquita http://www.undisciplinedbytes.com/?p=200 HTML 5 is a new revision of the standard language that moves the web. The increase in needs has brought new uses in HTML and new tags to support them, paying special attention to the semantic web. There are quite a few elements added to the new HTML standard to encapsulate different types of information:

New tags

  • <article /> This new element defines a portion of the content as an article. Perfect for newspapers or blogs.
  • <aside /> Represents a fragment of information that slightly relates with the rest of the content.
  • <dialog /> Depicts conversations.
  • <figure /> Used to associate a caption with an embedded content, such as graphics or video.
  • <footer /> Page section to hold author information, copyright statement, etc…
  • <header /> Page section to hold some introductory information.
  • <nav /> Section oriented to navigation.
  • <section /> Element that defines a generic section.
  • <audio /> and <video /> Provides multimedia content.
  • <embed /> Supports plugin contents.
  • <m /> Marked text.
  • <meter /> Used to display measures.
  • <time /> Used to display dates and/or time.
  • <canvas /> Used to show real-time renderized graphics, such as games. For example, Sierra adventure games.
  • <command /> Related with commands a user can invoke.
  • <datagrid /> Shows additional information if it is requested by the user.
  • <datalist /> Used together with the new attribute for <input /> can be used to create comboboxes.
  • <output /> Denotes what kind of output the page produces.
  • <progress /> Represents a progress bar in a time consuming task, such as donwloading a file.

New local attributes

There’s a few new attributes for some of the elements that were already present in HTML4.

  • media: for greater consistency with the link element.
  • ping: whitespace-delimited URLs list to which a ping will be produced when the link is followed. For the elements <area /> and <a />.
  • target: for greater consistency the <a /> element.
  • autofocus: indicates that the <input />, <select />, <textarea /> or <button /> element should get the focus at page load.
  • form: attribute for <input />, <ouput />, <select /> <textarea />, <button /> and <fieldset /> which allows them to be associated to a form. This way, they can now be placed anywhere on a page, not as children of the form element.
  • replace: will affect the element once changes are performed to it. For elements <input />, <button /> and <form />.
  • data: specifies data for the elements <form />, <select /> and <datalist />.
  • required: denotes a required element, for <input /> and <textarea />.
  • disabled: for the <fieldset /> element.
  • autocomplete, min, max, pattern, step: these attributes delimitate the possibilities of the <input /> element.
  • list: for <datalist /> and <select /> elements.
  • template: for <input /> and <button /> elements, it will be used to repeat templates.
  • scoped: for the <style /> element, enables the use of scoped style sheets.
  • async: for the <script /> element. AJAX turned into an attribute.

New global attributes

Some attributes that apply to the whole web page document:

  • contenteditable: denotes an editable area.
  • contextmenu: contextual menu supplied by the user.
  • draggable: … needs explanation?
  • tabindex: a numeric value representing the order of elements we will tour around when pressing the TAB key.
  • irrelevant: … need I say more?
  • repeat, repeat-start, repeat-min, repeat-max: these attributes refer to iterations.

HTMLDocument extensions

There are some improvements, and some other elements that finally get standarized:

  • getElementsByClassName(): selects elements given a class. Time responses seem to be dramatically improved by using this function.
  • innerHTML: present in all ECMAScript implementations, it was not a standard till now.
  • activeElement, hasFocus(): will allow us to know which is element is active and which one has the focus.
  • getSelection(): returns an object with the current selection.
  • designMode, execCommand(): used to edit documents.

HTMLElement extensions:

The DOM element has also had some changes:

  • getElementsByClassName(): returns the children of an element that has a given class.
  • innerHTML: reads/changes the content of a node.
  • classList: a very interesting implementation that, along with className, lets us interact with element classes, providing methods such as has(), toggle(), add() and remove().
  • relList: works as classList on the rel attributes of the elements <a />, <area /> and <link />.

This is just a quick overview of the most important changes that HTML will bring. But there’s many more not mentioned here. For a complete reference guide, consult the W3C official draft.

HTML 5 is still a draft. Its definition is not finished yet. But all major browsers are already starting to implement some of its features. There’s still many years to wait for HTML 5 to be as widespread as HTML 4.01 is today, but the improvements this new version bring are so impressive that may affect its adoption speed. The originally proposed name for HTML 5 was Web Applications 1.0, which provides a very good idea about the goal of this new standard.

Further reading

Related posts:

  1. CSS 3: one more step in the evolution of the web

]]> http://www.undisciplinedbytes.com/2009/11/html-5-dramatic-improvements-in-the-web-language/feed/ 1