Positie van het artikel behouden na het bewerken van een rij in een lijst ... zou ik het zelfs moeten proberen?

Ik bind handmatig een ASP.NET ListView aan een array van objecten alfabetisch gesorteerd op naam. Na het bewerken van een item wordt de DataSource opnieuw ingesteld en DataBind wordt gebeld. Als de naam is gewijzigd, is het item dat u zojuist hebt bewerkt mogelijk verplaatst, mogelijk zelfs naar een andere pagina.

Bijvoorbeeld; je hebt zojuist de naam Hot Dog to Sausage gegeven, dus Sausage is verhuisd nadat ItemUpdating is voltooid.

--- OLD LIST ---   --- NEW LIST ---
    Hamburger          Hamburger
    Hot Dog______      Pizza
    Pizza        |_____Sausage

Is dit gedrag dat u van een formulier zou verwachten? Wanneer u een rij bewerkt, moet u die rij dan verwachten nadat u deze hebt opgeslagen? Moet het in exact dezelfde positie zijn? Moet ik alleen de record weergeven die u zojuist hebt bewerkt na het opslaan?

Wat betreft de technische kant van het handhaven van de vorige bestelling na het opslaan en mogelijk wijzigen van de bestelling;

Ik weet waarom dit gebeurt. Ik ben op zoek naar ideeën om het te vermijden.

Ik denk erover om zowel de besturingselementen van EditItemTemplate te combineren in ItemTemplate en de zichtbaarheid in te stellen op alleen-lezen/bewerkbare besturingselementen op basis van de ListView EditIndex.

Dit lijkt haalbaar, maar ik vraag me af of je fijne mensen andere ideeën hebt.

 2
toegevoegd bewerkt
Bekeken: 3
de bron

3 antwoord

Het gedrag dat u hier ziet, is de typische gewenste uitvoer, aangezien wanneer u de wijziging aanbrengt, de informatie correct is gesorteerd. Als je de oude structuur wilt behouden, moet je waarschijnlijk een route volgen die lijkt op wat je in je post hebt vermeld.

Ik zou echter een seconde nemen om te kijken of dit echt is wat uw gebruikers willen hebben. Ik zou dit na een groot aantal bewerkingen echt verwarrend kunnen zien worden.

2
toegevoegd
de bron
Ja, ik heb verschillende webgebaseerde managementtools gebruikt die zich allemaal op deze manier gedragen. De lijst wordt na elke bewerking opnieuw gesorteerd. De enige variatie lijkt te zijn of je blijft waar je was in de lijst, of het record naar de nieuwe locatie volgt. Dit is met name van belang wanneer paging in het spel komt ... en DAT is afhankelijk van de vereisten van uw gebruikers.
toegevoegd de auteur Tevo D, de bron
Hier is een perfect voorbeeld - mijn geplande betalingen via internetbankieren zijn gesorteerd op te betalen datum. Ik kan de datum op het eerste item wijzigen naar een latere datum en deze kan van de lijst verdwijnen. Dit is het verwachte gedrag omdat het een weergave is van wat er gedurende een bepaalde periode zal worden uitbetaald.
toegevoegd de auteur Tevo D, de bron
Is het herschikken na het bewerken van typisch gedrag voor lijsten met gegevens? Ik probeer webapps te herinneren die ik zelfs nodig had om een ​​rij te bewerken die zou worden verwijderd van de oorspronkelijke locatie, maar ik slaag er op dit moment niet in.
toegevoegd de auteur Orange Kid, de bron

Wanneer ik mijn gebruikers werk met datasets in GridView s, bestel ik altijd mijn gegevens op basis van de database-ID om ervoor te zorgen dat de positie van elk gegevensitem hetzelfde blijft. Zonder te weten hoe uw gegevensbron eruitziet, is het moeilijk te zeggen of u het opnieuw sorteren kunt voorkomen of wijzigen.

Echter, ( dit is pure speculatie omdat ik niet weet met wat voor soort gegevens je werkt ) als je je originele gegevensbron in de sessie hebt opgeslagen (I ' m ervan uitgaande dat je teruggaat naar de database en de gegevens na het verzenden pakt) en het heeft een soort van geordende ID, dan zou je iets kunnen doen als:

void ItemUpdating(object sender, ListViewUpdateEventArgs e)
{
    List foodDataSource = Session["dataSource"];
    ListItem editedFoodItem = foodListView.Items[e.ItemIndex];

    MyFood newFood = new MyFood(
        ((HiddenField)editedFoodItem.FindControl("foodId")).Value,
        ((Label)editedFoodItem.FindControl("foodName")).Text
    );

    foodDataSource.Where(k => k.foodId == newFood.foodId).foodName = newFood.foodName;

   //I'm guessing that you'll save somewhere in here,
   //rather than do an update-once-style commit to the database when the user clicks a save button.

    foodListView.DataSource = foodDataSource;
    foodListView.DataBind();
}

Dit veronderstelt dat je je ItemTemplate hebt gecodeerd met specifieke WebControls / HtmlControls . Het is onhandig, en deze code moet opnieuw worden geformuleerd om vervelende code zoals de FindControl -oproepen in een aparte functie in quarantaine te plaatsen, maar dit komt aardig in de buurt van wat ik doe wanneer mijn gebruikers gegevens bijwerken in een GridView en sla hun wijzigingen vervolgens op in de database.

Alternatively, you could keep your current save methods the same, and just add something like:

void ItemUpdating(object sender, ListViewUpdateEventArgs e)
{
    ListItem editedFoodItem = foodListView.Items[e.ItemIndex];
    Label foodNameLabel = ((Label)editedFoodItem.FindControl("foodName"));

    foodNameLabel.BackColor = System.Drawing.Color.LightGreen;

   //Saving in here, somewhere.

   //I'm not totally positive that DisplayIndex is the correct property here.
    foodListView.Items.Where(k => k.DisplayIndex != e.ItemIndex).BackColor = System.Drawing.Color.White;
}

Ik weet niet zeker of uw gebruikers de gebruikersinterface zouden begrijpen, of dat het hen zou helpen als het zou vervagen (wat uw leven natuurlijk gecompliceerder zou maken), maar ik denk dat dit minder onhandig is dan de bovenstaande optie als zolang u de wijzigingen in de database na elke bewerking opslaat.

1
toegevoegd
de bron

In sommige gevallen zag ik een behoefte om de lijst niet te gebruiken en het item te laten staan ​​waar het zich bevindt. Hoewel ons programmeurs begrijpen wat er is gebeurd, kan een gemiddelde gebruiker denken dat zijn item is verwijderd.

Ik heb een voorbeeldwebsite samengesteld waarin dit gedrag wordt gedemonstreerd. Het is eigenlijk vrij eenvoudig om te bereiken, en ik weet zeker dat je mijn methode voor je project kunt aanpassen.

In een notendop, elke keer dat het raster gebonden is, bestel ik de lijst met gegevens naar keuze van de gebruiker (of de standaardsortering), maar vlak voordat het aan het raster wordt gekoppeld, controleer ik of de volgorde moet worden bewaard, in welk geval , Ik extraheer het laatste volgnummer uit de DataKeyArray van het raster en koppel die volgnummers aan hun respectieve items. In het geval dat ze de volgorde niet wilden behouden, associeerde ik eenvoudig een oplopend volgnummer met elk item in de gesorteerde lijst. Dan sorteer ik eenvoudig op volgnummer.

Bekijk het project en ik denk dat het zal logischer zijn.

0
toegevoegd
de bron