Server-side-centric asp.net ajax mode (Part 1

What is behavior?

What is behavior? What is the difference between behavior and control? This is the first question to answer.

In Windows development, the concept of behavior is non-existent, and some are just control. ASP development Even control is not, to the ASP.net only introduced the concept of control. Why should Ajax development introduce concepts such as behavior? Because behavior means that there is no need to change the original component logic, the logic of changing the original component is often not feasible at the client, at least it is difficult to achieve.

For the simplest example, a <input type= "text"/> is an object within a browser, you cannot extend the object's type or add new properties and methods to it, at least not all browsers allow you to do so in JavaScript. However, if you want to add auto-complete (or suggest) functionality, this can be done, and many people have done it, such as ASP.net AJAX Control Toolkit autocomplete, Or Script.aculo.us's autocompleter. These implementations are based on the same approach, trying to add new functionality outside it based on an existing interface to input, rather than trying to inherit input and add functionality within it.

Similar practices are common in AJAX development. For example, drag and drop bar, now away from the full popularity of HTML5 do not know how far, so we can only based on existing mouse events to develop drag-and-drop functions. or an input box with a validation function, whether it's input or select, whether it's client-side validation or server-end validation, is also based on an existing HTML element event. All this is behavior.

Under what circumstances is the use of behavior?

A simple summary, on two conditions:

Needs to be extended based on a specific build

The environment in which the build itself is lacking scalability

Look at the 1th condition alone, we have a rich choice. A lot of people's first reaction is to inherit from the component and extend the function into subclasses. If you are familiar with design patterns, you may also think of decorator pattern. However, in the context of the browser, it is not feasible to inherit or decorator pattern, which is restricted by the 2nd condition. That's when we need to use behavior.

To a certain extent, we can think of behavior as a eclectic decorator pattern. In decorator pattern, decorator also inherits from the component, so when a component uses decorator pattern, we place the decorator where the original component is located, The original component becomes a child node of the decorator (based on the tree's point of view). If you add another decorator, the original decorator will be encapsulated once more as a common component. In the case of multiple decorator, decorator is a concatenation relationship. Behavior itself is not a component within a browser, it cannot inherit from the base class of input, so behavior cannot be concatenated. Behavior itself will not replace input in the tree position, which allows behavior to be in parallel-one input can have multiple behavior, such as one is automatic completion, the other is input validation.

In short, if your original job is to interact with the UI and use decorator pattern skillfully, replace decorator pattern with behavior on AJAX development.

Summary

Looking back at the MessageBox (or confirm) problem at the beginning of the article, if this feature does not require feedback on the server side, you can use behavior implementations entirely. asp.net AJAX Control Toolkit There is a confirmbutton such a thing, in the client called behavior, in the server called Extender, in fact, Extender is behavior on the server to do a package. Of course, ConfirmButton does not fully implement the MessageBox feature, it can only cancel the entire commit operation when the user chooses "Cancel", but cannot execute another server-side code branch. This is a limitation of behavior that it can only add extra functionality to the client, but it does not affect the interaction with the server side. But very often, it is this limitation that ensures that the components we develop are decoupled from the server side.