Dashboard > Spring.NET > ... > Spring.Web > Bidirectional data binding
  Spring.NET Log In View a printable version of the current page.  
  Bidirectional data binding
Added by Aleksandar Seovic, last edited by Mark Pollack on Nov 27, 2005  (view change)
Labels: 
(None)

Warning

This documentation has been moved to docbook format and now resides on the Spring.NET website. If you feel the need to edit this document please send and email to the Spring.NET developer list.

A problem with the existing data binding support in ASP.Net is that it is one way only. It allows you to bind controls to the data model and display information from it, but it doesn't allow you to extract values from the controls when the form is submited and to update data model automatically.

Spring.Web adds such bidirectional data binding to ASP.Net using custom attributes that you can use to describe bindings, and by providing data binding logic within a base Page class.

Spring data binding is very easy to use. All you need to do is expose your data model as properties of the page and add binding attributes to your control declarations:

public class UserRegistration : Spring.Web.UI.Page
    {
        #region Control declarations

        [Binding("Text", "UserInfo.Email")]
        protected TextBox email;

        [Binding("Text", "UserInfo.Password")]
        protected TextBox password;

        protected TextBox passwordConfirmation;

        [Binding("Text", "UserInfo.FullName")]
        protected TextBox name;

        [Binding("Text", "UserInfo.Address.Street1")]
        protected TextBox street1;

        [Binding("Text", "UserInfo.Address.Street2")]
        protected TextBox street2;

        [Binding("Text", "UserInfo.Address.City")]
        protected TextBox city;

        [Binding("Text", "UserInfo.Address.State")]
        protected TextBox state;

        [Binding("Text", "UserInfo.Address.PostalCode")]
        protected TextBox postalCode;

        [Binding("Text", "UserInfo.Address.Country")]
        protected TextBox country;

        #endregion

        #region Properties

        private User user;
        public User UserInfo
        {
            get { return user; }
            set { user = value; }
        }

        #endregion

        // the rest of the class omitted
    }

First parameter to Binding attribute is the name of the control property you are binding to. Second argument is an object navigation expression that will be used to get and to set value in the data model. For more information on object navigation expression syntax consult Spring reference documentation

Binding attribute also has a third, optional parameter, OneWay. If you set OneWay to true (it is false by default), Spring will not attempt to update data model with the value of the control's property. This is useful if you want to bind control to a calculated read-only property in a data model.

Another optional parameter is Format, which allows you to specify how the value should be formatted for display. This parameter is usually used in conjunction with OneWay attribute to provide custom formatting for date or numeric values. Any format expression supported by String.Format can be used.

Type Conversion

Spring data binder will attempt to convert types when copying values from controls to data model and vice versa. If format parameter is specified it will use it to convert data model value to string. Otherwise, it will rely on a standard .Net TypeConverter mechanism for conversion.

Data Binding Events

Spring's base Page class adds two events to standard .Net page lifecycle – DataBound and DataUnbound.

DataUnbound event is fired after the data model has been updated using values from the controls. It is fired right after the Load event and only on postbacks, because it doesn't make sense to update data model using controls' initial values.

DataBound is fired after controls have been updated using values from the data model. This happens right before the PreRender event.

The fact that data model is updated right after the Load event and that controls are updated right before PreRender means that your events handler will be able to work with correctly updated data model, as they execute after the Load event, and that any changes you make to data model within event handlers will be reflected in the controls afterwards, as they are updated before rendering.

Site running on a free Atlassian Confluence Open Source Project License granted to Spring Framework. Evaluate Confluence today.
Powered by Atlassian Confluence, the Enterprise Wiki. (Version: 2.5.5 Build:#811 Jul 25, 2007) - Bug/feature request - Contact Administrators