I've been looking at the dayrender event and as far as i understand, it fires before rendering each day in a calendar.
In the helpdesk sample application this event has a code which connects to a database and determines whether the date should have a special formatting.
My question in this is, does this mean that for each day which is visible in the calendar, i.e. "the current month" a connection is opened making the application open a sql connection up to 31 times?
If so, is there any better way of doing this?
My own thoughts were that perhaps the data for the current month could be loaded beforehand and stored in a collection which I think must be stored in viewstate, and then in the dayrender event data is checked in the viewstate for formatting?
Recommendations?
In the helpdesk sample application this event has a code which connects to a database and determines whether the date should have a special formatting.
My question in this is, does this mean that for each day which is visible in the calendar, i.e. "the current month" a connection is opened making the application open a sql connection up to 31 times?
If so, is there any better way of doing this?
My own thoughts were that perhaps the data for the current month could be loaded beforehand and stored in a collection which I think must be stored in viewstate, and then in the dayrender event data is checked in the viewstate for formatting?
Recommendations?
1 Answer, 1 is accepted
0
plamen
Top achievements
Rank 1
Rank 1
answered on 15 Aug 2008, 11:04 AM
hi:)
Hope this helps...
<John:Peel />
There are certain cases where holding a state value in ViewState is not the best option. The most commonly used alternative is Session state, which is generally better suited for:
- Large amounts of data. Since ViewState increases the size of both the page sent to the browser (the HTML payload) and the size of form posted back, it's a poor choice for storing large amounts of data.
- Secure data that is not already displayed in the UI. While the ViewState data is encoded and may optionally be encrypted, your data is most secure if it is never sent to the client. So, Session state is a more secure option. (Storing the data in the database is even more secure due to the additional database credentials. You can add SSL for even better link security.) But if you've displayed the private data in the UI, presumably you're already comfortable with the security of the link itself. In this case, it is no less secure to put the same value into ViewState as well.
- Objects not readily serialized into ViewState, for example, DataSet. The ViewState serializer is optimized for a small set of common object types, listed below. Other types that are serializable may be persisted in ViewState, but are slower and generate a very large ViewState footprint.
Hope this helps...
<John:Peel />