Ik wil gebruik maken van een Repeater control om bepaalde data weer te geven. Daarbij moet ook gebruik worden gemaakt van paging.
De data zelf zit in dit geval in business objecten en worden via een collection als datasource aan het Repeater control gehangen.
Dus, ongeveer zoiets:
En de codebehind:
Stel dat ik die code uit wil breiden om paging mogelijk te maken, dan wordt het dus zoiets:
Wat me niet lekker zit is dat ik nu noodgedwongen de GetContactpersonen bij iedere page load uit moet voeren. Daar stappen bijna alle PagedDataSource how-to website's zonder moeite overheen. In het ene voorbeeld is een nog een IsPostback check... het volgende voorbeeld issie ineens weg
De vraag is nu wel.. waar laat ik het resultaat van GetContactpersonen bij een postback?
De methodes die ik tot nu toe bedacht had waren ViewState, de Session of de application Cache. Eigenlijk heb ik bezwaar tegen alle 3 de methodes.
- ViewState... not done.. je kunt geen halve datasets in je viewstate gaan proppen en heen en weer blijven posten.
- Session... te losjes, het leeft niet in de scope van de pagina en moet achteraf weer opgeruimd worden om niet tot het einde van de sessie in het geheugen te blijven staan.
- Cache, eigenlijk zelfde bezwaren als in Session
Dus... wat is hier nu best practice om de resultaten van bijv. een query als datasource aan een control te hangen.. EN deze daarbij te bewaren voor acties na een postback ?
De data zelf zit in dit geval in business objecten en worden via een collection als datasource aan het Repeater control gehangen.
Dus, ongeveer zoiets:
HTML:
1
2
3
4
5
6
| <asp:Repeater runat="server" ID="MyRepeater"> <ItemTemplate> <%# Eval("Voornaam") %> <%# Eval("Achernaam") %><br /> <%# Eval("Telefoonnummer") %> </ItemTemplate> </asp:Repeater> |
En de codebehind:
C#:
1
2
3
4
5
6
7
| protected void Page_Load(object sender, EventArgs e) { if (!Page.IsPostback) { MyRepeater.DataSource = GetContactpersonen; MyRepeater.DataBind(); } } |
Stel dat ik die code uit wil breiden om paging mogelijk te maken, dan wordt het dus zoiets:
C#:
1
2
3
4
5
6
7
8
9
10
11
| protected void Page_Load(object sender, EventArgs e) { PagedDataSource pageddata = new PagedDataSource(); pageddata.DataSource = GetContactpersonen; pageddata.AllowPaging = true; pageddata.PageSize = 7; pageddata.CurrentPageIndex = 0; MyRepeater.DataSource = pageddata; MyRepeater.DataBind(); } |
Wat me niet lekker zit is dat ik nu noodgedwongen de GetContactpersonen bij iedere page load uit moet voeren. Daar stappen bijna alle PagedDataSource how-to website's zonder moeite overheen. In het ene voorbeeld is een nog een IsPostback check... het volgende voorbeeld issie ineens weg
De vraag is nu wel.. waar laat ik het resultaat van GetContactpersonen bij een postback?
De methodes die ik tot nu toe bedacht had waren ViewState, de Session of de application Cache. Eigenlijk heb ik bezwaar tegen alle 3 de methodes.
- ViewState... not done.. je kunt geen halve datasets in je viewstate gaan proppen en heen en weer blijven posten.
- Session... te losjes, het leeft niet in de scope van de pagina en moet achteraf weer opgeruimd worden om niet tot het einde van de sessie in het geheugen te blijven staan.
- Cache, eigenlijk zelfde bezwaren als in Session
Dus... wat is hier nu best practice om de resultaten van bijv. een query als datasource aan een control te hangen.. EN deze daarbij te bewaren voor acties na een postback ?
:strip_exif()/u/13818/episodebutler_60x60.gif?f=community)
./u/56680/gurgi.png?f=community)
:strip_icc():strip_exif()/u/6143/rincewind.jpg?f=community)
:strip_icc():strip_exif()/u/1857/crop5a4d06ced6afe_cropped.jpeg?f=community)
) de page te passen en het daar op te lossen.
dit was slechts voorbeeld code om even aan te geven waar de schoen knelt 
tnx voor de input !
/u/39688/AnnoAvatarSmall.png?f=community){kind=avatar}