We interrupt this series of articles to bring you this important announcement !
- Have you ever stumbled on the problem of binding events to AJAX generated elements in your web application ?
- Looking for a neat way of updating a certain class of elements created and updated dynamically ?
- Want to attach events to existing and future elements in a simple and uniform way ?
Then look no further then the jQuery Event API… jQuery offers a wide variety of methods for handling the above issues. Read the rest of this entry »
After discussing creational patterns, which handle object creation throughout the application, it’s time to take a look at how objects are composed in order to create flexible larger structures. Structural patterns deal with the way objects connect with each other to form new objects, or modify object capabilities and they offer flexible solutions to common architectural issues when it comes to application design.
When it comes to creating new objects dynamically, an application needs to able to instantiate and remove objects at run-time. This becomes particularly difficult if the concrete classes describe similar objects that only vary in representation, because you could end up with a lot of subclasses for basically the same kind of product. Enter the Prototype pattern!
Now that we have looked at the Factory Method pattern, which delegates the responsibility, of deciding which objects to create, to its subclasses, we’ll be analyzing the Abstract Factory pattern, which is used for created multiple objects from the same family, by providing a common interface for creation. In the words of the Gang of Four (Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides), the pattern’s main intent is to “provide an interface for creating families of related or dependent objects without specifying their concrete classes.”
Like all other patterns (not just creational, but behavioural and structural as well), Abstract Factory is applied in a specific situation. Here are a few examples:
- a system should be independent of how its products are created, composed, and represented
- a system should be configured with one of multiple families of products
- a family of related product objects is designed to be used together, and you need to enforce this constraint
- you want to provide a class library of products, and you want to reveal just their interfaces, not their implementations
Many might argue that this should be the first topic when learning design patterns, and they could be right, but I’m documenting them in cronological learning order. So here we are today discussing the Factory Method pattern, a very simple and useful way of designing the part of an application responsible for creating new objects.
The definition in the Design Patterns book is: “Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses“. So, in other words, we create an interface for a class that creates elements, and then implement it to create elements in a particular way. Now, let’s take a closer look at the implications of this pattern and it usefulness. If you have ever been in the situation when you need to create different types of objects, but the means for creation alter the context of the application where the objects are created, then you will love this pattern. It unifies the way objects are created so you can add new types without having to alter the main code of the application where the objects are used. Talk about cool, this pattern is awesome! Read the rest of this entry »
Picking up on the last post, and following Alex’s advice, I have decided to rewrite the example for the Builder pattern. Read about the new and improved form Builder…
Following the previous post on the Singleton design pattern, this article will discuss some features of the Builder pattern.
First thing’s first. As a creational pattern, the Builder pattern deals with creation of new items throught the application, but unlike the Singleton, which has the main focus of creating a globally avaible instace of an object, the Builder focuses on creating an object by following various steps and then returning the final product in a neatly organized object. As The Great Book sais, the Builder’s main intent is to “separate the construction of a complex object from its representation so that the same construction process can create different representations”.
Most of us programmers, are very attached to our code, and find beauty not just in the end result (the working application), but also in the architecture and the actual code. As I am sure you’ve heared many times before, “Code is poetry”. And nowhere else is this concept more palpable then in Object-Oriented Programming.
The fact the Object-Oriented Programming is a major concept in programming today is unanimously accepted. From the basic OOP principles like Data abstraction, Inheritance etc., a programmer will end up learning and, most important, using what we call Design Patterns. Everyone heard about them, most us used them and the others learn them.
In practice, developers often encounter the situation when a page needs to display a set of items (products, users etc) on sepparate pages which can be accessed using the previous/next navigation links. All though it is not a difficult matter, if you’re implementing this in a page that uses smarty templates, it might seem more difficult to implement. This article discusses how you can display an array of items on pages, each page containing a set amount of items using Smarty for formatting the items, and later on jQuery for navigating between pages.
If you are here, I think you have allready tried to set the showCloseButton property to false and it doesn’t work. So how can you access that button ? Lets look at the example from below:
<?xml version=”1.0″ encoding=”utf-8″?>
<mx:Application xmlns:mx=”http://www.adobe.com/2006/mxml” layout=”absolute”>
<mx:TitleWindow id=”titleWindow” showCloseButton=”true”>
<mx:Button label=”Remove close button” click=”removeButton()” />
</mx:TitleWindow>
<mx:Script>
<![CDATA[
import mx.controls.Button;
import mx.core.mx_internal;
//don't forget to import mx_internal namespace
public function removeButton():void
{ //get the close button from mx_internal namespace
var closeBtn :Button = titleWindow.mx_internal::closeButton;
closeBtn.enabled = false;
}
]]>
</mx:Script>
</mx:Application>
Now, if you click the button from the TitleWindow, the close button will disapear 
.
Note: You can use the mx_internal namespace to change the behavior of a Flex component which is hidden behind a private method or variable so you can’t subclass it.