Сохранять позицию элемента после редактирования строки в списке ... я должен даже попробовать? - PullRequest
2 голосов
/ 27 октября 2011

Я вручную связываю ASP.NET ListView с массивом объектов, отсортированных в алфавитном порядке по имени.После редактирования элемента снова устанавливается DataSource и вызывается DataBind.Если имя изменилось, только что отредактированный элемент мог быть перемещен, возможно, даже на другую страницу.

Например;Вы только что переименовали Хот Дог в Колбасу, поэтому Колбаса переместилась после завершения ItemUpdating.

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

Такое поведение вы ожидаете от формы?Когда вы редактируете строку, следует ли ожидать ее после сохранения?Должно ли оно быть в той же позиции?Должен ли я отображать только запись, которую вы только что отредактировали после сохранения?

Что касается технической стороны поддержания предыдущего порядка после сохранения и, возможно, изменения порядок;

Я знаю , почему это происходит.Я ищу идеи, как избежать этого.

Я думаю о том, чтобы убрать как объединение элементов управления EditItemTemplate в ItemTemplate, так и настройку видимости для элементов управления только для чтения / редактирования на основе ListView EditIndex.

Это кажется возможным, но мне интересно, есть ли у вас, ребята, другие идеи.

Ответы [ 3 ]

2 голосов
/ 27 октября 2011

Поведение, которое вы видите здесь, является типичным желаемым выводом, так как после внесения изменений информация правильно сортируется. Если вам нужно сохранить старую структуру, вам, скорее всего, придется идти по пути, аналогичному тому, который вы упомянули в своем посте.

Тем не менее, я хотел бы подождать секунду и посмотреть, действительно ли это то, что хотят ваши пользователи, я мог бы увидеть, что это становится действительно запутанным после большого количества правок.

1 голос
/ 01 ноября 2011

Когда мои пользователи работают с наборами данных за GridView с, я всегда упорядочиваю свои данные по идентификатору базы данных, чтобы убедиться, что позиция каждого элемента данных остается неизменной.Не зная, как выглядит ваш источник данных, трудно сказать, сможете ли вы избежать или изменить повторную сортировку.

Однако, ( это чистое предположение, так как я не знаю, чтос данными, с которыми вы работаете ), если вы сохранили исходный источник данных в сеансе (я предполагаю, что вы возвращаетесь в базу данных и получаете данные после отправки), и он имееткакой-то упорядоченный идентификатор, тогда вы могли бы сделать что-то вроде:

void ItemUpdating(object sender, ListViewUpdateEventArgs e)
{
    List<MyClass> 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();
}

Это предполагает, что вы жестко закодировали свой ItemTemplate для включения конкретного WebControls / HtmlControls.Это неуклюжий, и этот код необходимо реорганизовать, чтобы изолировать неприятный код, такой как вызовы FindControl в отдельной функции, но это довольно близко к тому, что я делаю, когда мои пользователи обновляют данные в GridView и затем сохраняют свои измененияв базу данных.

В качестве альтернативы , вы можете оставить текущие методы сохранения такими же, и просто добавить что-то вроде:

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;
}

Я не уверен, если вашпользователи могли бы понять реплику пользовательского интерфейса или помочь ей, если она исчезнет (что, конечно, сделает вашу жизнь более сложной), но я думаю, что это менее неуклюже, чем в приведенном выше варианте, если вы сохраняетеизменения в базе данных после каждого редактирования.

0 голосов
/ 04 ноября 2011

В некоторых случаях я видел необходимость не прибегать к списку и не оставлять элемент там, где он находится.Хотя мы, программисты, понимаем, что произошло, рядовой пользователь может подумать, что его элемент был удален.

Я собрал пример веб-сайта, демонстрирующий такое поведение.Это на самом деле довольно просто сделать, и я уверен, что вы можете адаптировать мой метод для вашего проекта.

В скорлупе орехов каждый раз, когда сетка привязана, я упорядочиваю список данных по выбору пользователя (или сортировка по умолчанию), но перед тем, как связать его с сеткой, я проверяю, должен ли быть сохранен порядок, и в этом случае я извлекаю последний порядковый номер из DataKeyArray сетки и связываю эти порядковые номера с соответствующими элементами,В случае, когда они не хотели сохранять порядок, я просто связываю добавочный порядковый номер с каждым элементом в отсортированном списке.Тогда я просто сортирую по порядковому номеру.

Взгляните на проект , и я думаю, что это будет иметь больше смысла.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...