In this post, you will learn step-by-step to build your own custom, reusable, testable jQuery Plugin.
There are times where you will want to reuse code that performs a series of operations on a selection.
For example, you may want to embed information a span element and then have that information displayed in a references section near the end of the document. In this case, the jQuery plugin is stateless.
In the next post, Building Stateful jQuery UI Plugin Using Widget Factory, you will see how to create a stateful jQuery plugin using jQuery Widget. And you will see how the widget is a better solution for plugins that require user interaction, because the Widget factory helps you maintain state.
John Munsch explains it like this:
When you go and get things out of the refrigerator for yourself, you can cause problems. You might leave the door open, you might get something Mommy or Daddy doesn’t want you to have. You might even be looking for something we don’t even have or which has expired.
What you should be doing is stating a need, “I need something to drink with lunch,” and then we will make sure you have something when you sit down to eat.
In designing an object-oriented application, a major tenet of design is “loose coupling”. Objects should only have as many dependencies as is needed to do their job – and the dependencies should be few.
There are three primary approaches to implementing DI:
- Constructor injection
- Setter injection (also called Property injection)
- Method injection
Constructor injection uses parameters to inject dependencies. In setter injection, you use setter methods to inject the object’s dependencies. Finally, in interface-based injection, you design an interface to inject dependencies.
In his talk on Some REST Design Patterns (and Anti-Patterns), Cesare Pautasso explains, “REST architectural style is simple to define, but understanding how to apply it to design concrete REST services in support of SOA can be more complex.”
Several SOA Design Patterns:
- Uniform Contract
- Endpoint Redirection
- Content Negotiation
- Idempotent Capability
In this post, you will learn the design methodology, walk through a step by step scenario where the client and server trade information to perform a set of actions, and you will learn more about the SOA design patterns.
Everything is a resource in REST. As you learned in Choosing Between RESTful Web Service, SOAP, Representational State Transfer (REST) is an architecture style or design pattern for creating web services which allow anything connected to a network to something else on the network using Hypertext Transfer Protocol (HTTP).
In this post, you will learn the how to define your resource identifier. In the following post, you will learn how to use the HTTP verbs and response codes. And along the way you will learn many of the principles of a good RESTful API.
Let me second what As Thomas Hunter II writes:
The easier your API is to consume, the more people that will consume it.
Representational State Transfer (REST) is an architecture style or design pattern for creating web services which allow anything connected to a network to something else on the network using Hypertext Transfer Protocol (HTTP).
Typically we think of a RESTful Web Service as one that will get and set data. It works a lot the same way as a web page, but your user doesn’t see the data until it’s time to be displayed.
REST principles are based on the same underlying principles that govern the Web. Those principles are:
- User agents interact with resources, and resources are anything that can be named and represented. Each resource can be addressed via a unique Uniform Resource Identifier (URI).
- Interaction with resources (located through their unique URIs) is accomplished using a uniform interface of the HTTP standard verbs (GET, POST, PUT, and DELETE). Also important in the interaction is the declaration of the resource’s media type, which is designated using the HTTP Content-Type header. (XHTML, XML, JPG, PNG, and JSON are some well-known media types.)
- Resources are self-descriptive. All the information necessary to process a request on a resource is contained inside the request itself (which allows services to be stateless).
- Resources contain links to other resources (hyper-media).
Or your application may want to be “cloud ready” from the beginning. The vision may begin with a set of servers, each doing a specific task, each that can be scalable to meet demand, provide reliability. As soon as you take that second step, it’s time to look to well known practices.
Microsoft’s Patterns and Practices team has put together architectural guidance to help you design your cloud applications, Cloud Design Patterns: Prescriptive Architecture Guidance for Cloud Applications. Each pattern is provided in a common format that describes the context and problem, the solution, issues and considerations for applying the pattern, and an example based on Azure.
It also discusses the benefits and considerations for each pattern. Most of the patterns have code samples or snippets that show how to implement the patterns using the features of Microsoft Azure.
Although the guidance helps you adopt Azure, the patterns are relevant to all kinds of distributed systems, whether or not they are hosted on Azure or on other cloud platforms.