Data binding and non-string type formatting

[Alistair]

Hi

We're using Spring data binding but I'm having problems fully understanding the formatting mechanism. I can't seem to figure out exactly what the Format parameter of the Binding attribute should be set to.

The "standard" .Net formatting strings don't seem to work, or at least don't work consistently. Additionally, it seems that formatted non-string types can't be unbound because the formatting is only applied in one direction.

Do you guys have an opinion on the best approach to managing formatting of dates, decimals (currency + percentages), and integers that avoids or minimises the amount of additional code required for fields that need to be unbound during postback?

Thanks
Alistair

[Aleks Seovic]

Hi Alistair,

Data binder uses String.Format to format value, so any standard formatting string should work fine.

You are correct regarding the fact that formatting is only in one direction. In fact, if you look closer at the BindingAttribute code, you will see that direction is set to BindingDirection.DataModelToControl automatically when formatting string is specified.

The main reason for Format property existance is to bind values to *non-editable* elements of the page and format them in the process. Typical example would be a label that displays current date.

If you need formatting with editable values, preferred approach is to do it on the client side using JavaScript and to post back only "clean" data, without any formatting applied. For dates you might want to use an open sourc calendar DHTML control that we've integrated into SpringAir and built server-side control for that greatly simplifies its use. It is really a great pop-up calendar and we also added the ability to make its textbox part editable so users can enter date directly, or to force users to choose date from the calendar.

As for the other controls (masked inputs for currency and decimal values, for example) my advice is to find a set of commercial (or open source, but commercial is probably your best bet in this case) controls that provide this support and to use them instead of plain ASP.NET controls.

Regards,

Aleks

[Alistair]

Aleks

Thanks for the information - I'll look into a set of third party controls that will do this for us.

Regards
Alistair

[Aleks Seovic]

Great. If you find something you really like let me know -- I have the need for the good set of input controls, but unfortunately not enough time to evaluate the ones that are out there properly.

Later,

Aleks

[Alistair]

Aleks,

Just to let you know - we did some investigation in this area and decided to produce our own derivative of the TextBox control that provided client side formatting and strongly typed value properties (for binding with Spring so that the "Text" property isn't needed in binding, instead we bind directly to "IntegerValue" or "DateTimeValue" etc).

This control isn't as flexible as could be - arbitrary format masks can't be provided - you choose from a list then set precision etc, but we'd be happy to provide the code if you were interested in it.

Regards
Alistair

[Aleks Seovic]

Take a look at my last post in the Validation topic... I might be able to add a few things to a data binding framework that will make this unnecessary and save you some trouble.

Let me know what you think,

Aleks

[Alistair]

Your suggested approach to unbinding may make some of this unnecessary, but going back to our original discussion I think client side formatting should be the preferred approach - you convinced me of this!

What this means is that from a developer's perspective the data that gets sent to the browser is unformatted (Javascript formats it when the page is loaded and updates the formatting as fields are changed) and the TextBox control is responsible for stripping the formatting from or unformatting the display value on post back - i.e. removing currency symbols, commas etc.

Adding two way formatting / unformatting into the Spring databinding code would probably be the best approach overall because we won't have to write any of that code ourselves, but it often isn't straight forward. DateTime values are a good example because even though we specify an initial format of "dd/mm/yyyy" we will actually accept data back in a variety of formats (e.g. "dd-mmm-yy", or "yyyy-mm-dd") and so Javascript formatting is potentially more flexible than relying on a single format mask.

From a design perspective, do you think that the databinding component or the GUI control should be responsible for managing the formatting / unformatting of data? We've gone with the latter, but really are just looking for the solution that makes our lives easier :)

Alistair

[Aleks Seovic]

Yeah, I know, I convinced myself earlier that client side formatting is the way to go, but the more I think about it the more I realize that the approach is flawed...

One big issue with it is related to localization: how do you let client side script know which locale to use? It's possible, don't get me wrong, and we are doing it for the Calendar control for example, but it's far from trivial and much easier to handle on the server.

That's why I revised my opinion and believe that adding bidirectional formatting and parsing capability would make life much easier for the users such as yourself, especially because it's already present in the core .NET framework and we just need to expose it.

As for date parsing, I find date parser to be very forgiving and it will accept a date in a number of formats if you don't explicitly tell it which one to use. I would just need to change the binding code to actually use DateTime.Parse for the conversion.

- Aleks

[Alistair]

Aleks

I agree - localisation is difficult on the client and we have, because our web pages are currently only nationally focused and at business users, ignored the issue.

If Spring could provide what we need on the server side, that would be great. I am becoming quite fond of our TextBox control formatting currency, date, and decimal numbers as you leave the field though. It provides a slightly more polished user experience.

Alistair

[Aleks Seovic]

I hear ya, and there is absolutely nothing wrong with you using that control to improve user experience, all I'm saying is that it shoudn't be required.

I'm open to include your control in Spring.Web, which is what you offered if I understood correctly, and I do think that web applications should take the advantage of the client-side scripting to improve user experience, but our (Spring.NET team's) general stand is that we should provide the features, but not force the users to do things any specific way.

That said, I'd love to offer your control as an available feature to the users.

Regards,

Aleks