Dans un contrôle de répéteur, il existe une façon de désactiver certains éléments avant que la page soit rendue?
Nous avons actuellement une collection d'articles liés à un répéteur et si l'article ne fait pas partie de la langue actuelle, nous masquons l'article.
Je veux pouvoir faire un compte sur le répéteur et obtenir un numéro valide. Un compte qui n'inclut pas également les articles cachés.
est-il possible de désactiver des éléments spécifiques peut-être dans l'événement itemDatabound
Pour chaque élément de la collection, nous lassons, nous vérifions la base de données lors de l'élément pour plus d'informations sur l'élément, telle que la langue, etc. Il s'agit actuellement de filtrage des données liées. avant de le lier.
4 Réponses :
Une solution plus appropriée pourrait être de filtrer la collecte liée s'il n'y a pas de besoin spécifique dans ces éléments cachés. Quelque chose comme mise à jour: comme pour moi, j'utiliserais cette approche: donc tout filtrant est appliqué à l'avance Cela réduira également le nombre de voyages ronds dans la base de données, ce qui joue pour de meilleures performances
Je vais mettre à jour mon OQ mais essentiellement, nous ne savons pas quels éléments à définir comme visible, etc. jusqu'à l'événement ItemDatabound. Chaque élément a une carte d'identité et nous allons à la DB pour plus de détails à ce moment-là.
Que se passe-t-il sur l'élémentDatabound qui rend le filtrage possible? Votre langue actuelle n'est-elle disponible que à ce moment-là?
Ouais. Fondamentalement, nous avons quelque chose appelé une collection d'identifiants "page" et, chaque élément étant lié, nous allons dans la base de données, découvrons si cela fait partie de la langue actuelle et, sinon, masque l'élément.
Est-il possible d'obtenir des identifiants d'articles avant de se lier et d'interroger la base de données que de ces identifiants conviennent cette fois?
Ce n'est pas non plus bon pour les raisons de performance d'interroger la base de données à chaque fois qu'un article est PataNTound
Pourquoi ne pas filtrer la DataSource avant la liaison. Ainsi, en supposant que vous utilisez des objets personnalisés: Si vous n'en avez pas besoin, ne les liez pas en premier lieu. update Si c'est possible, vous devriez probablement tirer cette information de la DB Upfront. Ces listes sont-elles grandes? Si c'est le cas, frappez la DB une fois pour chaque élément de la liste apparaîtra en tant que problème de performance.
Je suis d'accord avec les autres réponses - la meilleure solution (pour la clarté de performance et de code) est de redéfinir la page afin que vous puissiez filtrer les entrées non valides avant em> la base de données. La plupart des sources de données Ne nous permettez pas de supprimer leurs articles pendant que ASP.NET les est itération. Par exemple, si vous vous liez à une simple liste générique Si filtrant les éléments à l'avance n'est vraiment pas une option, votre solution actuelle va bien: Cachez simplement les articles! Si vous avez besoin d'obtenir le comptage correct en plus de cela, suivez le nombre d'éléments non valides dans votre articleDatabound Handler et l'exposer en tant que propriété au niveau de la page: P> InvalidOperationException code>. P> Dans d'autres cas, ASP.NET iTère effectivement une copie AA de la source de données. Si vous liez à un dataTable code>, ASP.NET utilise une copie du contenu (le DataView par défaut) plutôt que d'itération des rangées source elles-mêmes - Vous pouvez supprimer des éléments de la source de données sous-jacentes tout en itération, mais elle N'affecte pas l'opération de base de données. P> if (IsInvalid(args.Item.DataItem)) {
this.invalidItemCount++;
// code to hide the current item
}
J'adorerais redéfinir la façon dont les pages fonctionnent, mais nous utilisons Episerver comme CMS et aussi loin que j'ai trouvé, la voie actuelle est la meilleure que j'ai pu trouver. Je suis actuellement à la suite de votre dernier suget pour exposer une propriété Compter et incruster pour les articles valides. Pourrait avoir à coller avec ça. Merci pour la réponse :)
La réponse est très facile Vous vient de définir la propriété visible code> sur false code> sur l'élément et il ne sera pas rendu. Dans cet exemple, je retire les éléments d'une liste de produits uniquement disponible pour les nouveaux clients si l'utilisateur actuel a une historique d'achat: void rpt_ItemDataBound(object sender, RepeaterItemEventArgs e)
{
if (!userHasPurchaseHistory) { return; }
// filter out products only allowed for new members
if (e.Item.ItemType == ListItemType.Item || e.Item.ItemType == ListItemType.AlternatingItem)
{
System.Data.Common.DbDataRecord rec = (System.Data.Common.DbDataRecord)e.Item.DataItem;
if (rec != null)
{
bool newMemberOnly = Convert.ToBoolean(rec["NewMemberOnly"]);
if (newMemberOnly) { e.Item.Visible = false; }
}
}
}