Date formats, culture and globalization

[JimLad]

Hi,

ASP.NET 3.5

We are creating a 3-tier ASP.NET Web Application that needs just to
understand dates as UK shortdate format (dd/MM/yyyy). It will only be
used in the UK on intranet. I often come across web server and client
machine that are incorrectly set up so I want to protect the app from
these incorrectly set up hosts.

I understand the safe date formats for passing through to the
database. SQLParameters pass through a non-ambiguous format and also
that 'yyyyMMdd' is also a safe format. So ignore the database side of
things - I get that.

At the moment all the bound controls are done as follows:
<%# Bind("spouse_date_of_birth","{0:dd/MM/yyyy}") %>

This nicely controls the inputs, but would it be better to put the
following line in web.config:
<globalization uiCulture="en" culture="en-GB" />
and then specify the short date format on the page:
<%# Bind("spouse_date_of_birth","{0:d}") %>

Also, if we fail to convert all strings in the UI layer and then
convert them in the BLL or DLL layer, what culture would those
assemblies/DLLs use in the date conversion? Do they use the values
specified in the web.config or do you specify them separately?

One thing I am sure about is that I want to isolate the ASP.NET app
from the culture settings on the web server and the client machine.

Cheers,

James

 

[Guest]

Hi,

ASP.NET 3.5

We are creating a 3-tier ASP.NET Web Application that needs just to
understand dates as UK shortdate format (dd/MM/yyyy). It will only be
used in the UK on intranet. I often come across web server and client
machine that are incorrectly set up so I want to protect the app from
these incorrectly set up hosts.

I understand the safe date formats for passing through to the
database. SQLParameters pass through a non-ambiguous format and also
that 'yyyyMMdd' is also a safe format. So ignore the database side of
things - I get that.

At the moment all the bound controls are done as follows:
<%# Bind("spouse_date_of_birth","{0:dd/MM/yyyy}") %>

This nicely controls the inputs, but would it be better to put the
following line in web.config:
<globalization uiCulture="en" culture="en-GB" />
and then specify the short date format on the page:
<%# Bind("spouse_date_of_birth","{0:d}") %>

Also, if we fail to convert all strings in the UI layer and then
convert them in the BLL or DLL layer, what culture would those
assemblies/DLLs use in the date conversion? Do they use the values
specified in the web.config or do you specify them separately?

One thing I am sure about is that I want to isolate the ASP.NET app
from the culture settings on the web server and the client machine.

Cheers,

James

Just use <globalization uiCulture="en-GB" culture="en-GB" /> and your
date will be automatically shown in UK format. You will not need to
bother about format in <%# Bind(...)%> statement. ASP.NET uses web
application settings from the web.config file. It doesn't rely on
client or server settings.

 

[JimLad]

Just use <globalization uiCulture="en-GB" culture="en-GB" /> and your
date will be automatically shown in UK format. You will not need to
bother about format in <%# Bind(...)%> statement. ASP.NET uses web
application settings from the web.config file. It doesn't rely on
client or server settings.- Hide quoted text -

- Show quoted text -

Thanks.

How would I set the Culture and UI Culture for the BLL and DAL layers
in separate VB.NET dlls?

James

 

[Patrice]

Hi,

You shouldn't. The idea is to convert to a text representation at the very
end and from a text representation as soon as possible (that is in the UI
layer). Your BLL and DAL should deal with dates, and shouldn't have anything
to convert. Have you run into an issue or is it a question you ask just in
case ?

--
Patrice


"JimLad" <[email protected]> a écrit dans le message de

Just use <globalization uiCulture="en-GB" culture="en-GB" /> and your
date will be automatically shown in UK format. You will not need to
bother about format in <%# Bind(...)%> statement. ASP.NET uses web
application settings from the web.config file. It doesn't rely on
client or server settings.- Hide quoted text -

- Show quoted text -

Thanks.

How would I set the Culture and UI Culture for the BLL and DAL layers
in separate VB.NET dlls?

James

 

[Guest]

Thanks.

How would I set the Culture and UI Culture for the BLL and DAL layers
in separate VB.NET dlls?

James

CultureInfo.CurrentCulture

If you use dates you normally don't need it. If any string comparisons
must be done, either use current culture or a culture-invariant string
comparison.

CultureInfo.CurrentCulture
CultureInfo.InvariantCulture

More about CultureInfo
http://msdn.microsoft.com/en-us/library/system.globalization.cultureinfo.aspx

Hope this helps

 

[JimLad]

CultureInfo.CurrentCulture

If you use dates you normally don't need it. If any string comparisons
must be done, either use current culture or a culture-invariant string
comparison.

CultureInfo.CurrentCulture
CultureInfo.InvariantCulture

More about CultureInfohttp://msdn.microsoft.com/en-us/library/system.globalization.culturei...

Hope this helps- Hide quoted text -

- Show quoted text -

Thanks. That's what I thought. However I've recently been stuggling
with BLL Validation and when and where it should occur.

I have a Gridview using an ObjectDataSource. This is a standard thing
that I'll be doing on loads of pages and I will be creating a template
for this.

So obviously I can validate in the Gridview_Updating event. However,
nothing is typed at this point so I would have to type everything
manually. Things are typed in ObjectDataSource_Updating, but by then
I've lost the e.cancel function and would have to raise an exception
to cancel.
Returning to Gridview_Updating I can pass the typed values I need
individually or I can pass the IOrderDictionary of values, newvalues
or keys. However these are untyped and I would have to them type them
in the BLL layer so I've rejected this option.

Or I can Validate in the BLL layer in the Update function. I have a
Generic List of validation failures to return and I also want to keep
the entered values on the page, not refresh the page if there are
validation problems. The only way to prevent the page from refreshing
seems to be to return an exception to GridView_Updated. I could create
a new Exception which contains the Validation Error Generic List. But
I have always thought that Exceptions should not be raised for
standard functionality like this?

Basically I want to limit bespoke validation functionality to the BLL
layer and not have to do manual typing on the UI layer. But I can't
seem to find a way of doing that without raising exceptions.

Any advice would be very welcome. If these are the only 2 options,
which should I do? I realise it would take very little effort to type
values manually on the UI side for each page, but I always like to
standardise code where possible.

James

 

[JimLad]

Thanks. That's what I thought. However I've recently been stuggling
with BLL Validation and when and where it should occur.

I have a Gridview using an ObjectDataSource. This is a standard thing
that I'll be doing on loads of pages and I will be creating a template
for this.

So obviously I can validate in the Gridview_Updating event. However,
nothing is typed at this point so I would have to type everything
manually. Things are typed in ObjectDataSource_Updating, but by then
I've lost the e.cancel function and would have to raise an exception
to cancel.
Returning to Gridview_Updating I can pass the typed values I need
individually or I can pass the IOrderDictionary of values, newvalues
or keys. However these are untyped and I would have to them type them
in the BLL layer so I've rejected this option.

Or I can Validate in the BLL layer in the Update function. I have a
Generic List of validation failures to return and I also want to keep
the entered values on the page, not refresh the page if there are
validation problems. The only way to prevent the page from refreshing
seems to be to return an exception to GridView_Updated. I could create
a new Exception which contains the Validation Error Generic List. But
I have always thought that Exceptions should not be raised for
standard functionality like this?

Basically I want to limit bespoke validation functionality to the BLL
layer and not have to do manual typing on the UI layer. But I can't
seem to find a way of doing that without raising exceptions.

Any advice would be very welcome. If these are the only 2 options,
which should I do? I realise it would take very little effort to type
values manually on the UI side for each page, but I always like to
standardise code where possible.

James- Hide quoted text -

- Show quoted text -

I am reposting this as a new topic.
James