Кастомная пагинация выводимого списка

Пагинация и одновременной редактирование это достаточно сложная задача в связи со всякими ограниченями Salesforce.

Я бы предложил лучше такое рашение (а ниже я прокомментирую твой мысли):

сделать страницу без пагинации, но с поиском и фильтрами. И выводить на странице только 100 записей, а если больше 100 записей выводить предупреждение для пользователя чтобы он уточнил критерии поиска. Я использую данный подходи во многих проектах. Работает на ура. Плюсов кучу, кода минимум. 
Немного подробнее: заходит пользователь на страницу - ему показываются первые 100 записей и выдается предупреждение, что записей больше и необходимо уточнить критерии поиска или включить фильтры (можно больше 100, но это самое оптимальное количество чтобы пользователь не устал скролировать). Пользователь уточняет критерии поиска и в итоге выходит на результат <100 записей, которые он спокойно может отредактировать в табличном виде и отправить в контроллер для update. Основная сложность данного способа - придумать фильтры и поиск чтобы использовать их в SOQL запросе. 

[i]Первая мысль[/i] - на VF странице можно использовать list c 1000 записями максимум не важно как ты потом его собираешься раскладывать на странице. Если будет побольше получишь exception.

[i]Вторая и третья мысль[/i] - пагинации в Standard Controller не будет работать, если ты изменишь хоть одно поле в записи из листа. Вернется ошибка что содержимое листа изменилось и на этом все закончится.

[i]Твой вариант[/i] - Можно использовать OFFSET в SQOL (вот здесь есть пример [url]http://www.redpointsolutions.com/add-pagination-to-your-visualforce-pages-using-the-soql-offset-clause[/url]). Проблема появится если у тебя будет более 2000 записей - смещение нельзя задать более 2000.

Так что подумай на счет моего варианта.

Полностью согласен с твоей идеей. Буду склонять кастомеров к этому.

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

Есть еще подвох в фильтрации: список может меняться. сегодня в всех вариантах отбора не более 100 записей - и мы в этом убедились. Завтра они добавят новые записи - и вот уже в выборке больше 100...

Моя задумка - попробовать взять под контроль ситуации с кастомной пагинацией [b]редактируемого [/b] списка, научится это делать, чтобы быть готовым к таким требованиям в будущем.

кстати: в идеале можно совмещать эти две вещи:
сначала работают селекторы
и если в списке более 100 - то включается пагинации и во время перехода по страницам передергивается только панель со списком. И все это можно было бы сделать с использованием возможностей станд контроллера, если бы не редактирование полей списка...

На выходных попробую, спасибо за подсказку с запросом.

На выходных еще раз прочитал приведенный выше вариант, посмотрел ему пример - все нравится, чуть позже буду пробовать.

И возникла более общая мысль - мысль о том, что если ты в VF странице выводишь список записей, первой твоей мыслью должна быть мысль: "А как я собираюсь ограничивать\регулировать кол-во передаваемый во вью записей? И не просто "ограничивать" (например, рубить выборку LIMITом, как это делается на начальных стадия разработки каст контроллера), а так чтобы это соответствовало логике приложения?"

Получается два варианта:
1) селекторы - выборка по определенному признаку, но тут нужно согласовать с заказчиком какие селекторы будут дефолтными, или не выводить никакого списка при начальной загрузке.

и\или

2) пагинация: средствами стан контроллера или кастомная.

Если ограничение не предусмотеть, то страница упадет при:
1) мере роста БД - довольно быстро.
2) сразу после импотра записей в объект.

Причем не все пользователи  столкнутся с проблемой сразу (у ролей будут  ограничения на видимые записи, так что не все пойдут в выборку). Получается, что первый у кого все упадет - это будет админ.

И теперь вещь, по поводу которой у меня нет полной ясности - и Дмитрий тут может хорошо подсказать:

[b]А какие лимиты будут выбиты[/b] (и теоретически) в какой последовательности в случае если не ограничивать выборку записи?

1) это [b]общее кол-во записей передаваемых из контроллера во вью [/b]- 1000шт? правильно?
а если у меня кастомная страница, типа Лист-Листа, т.е. ведущий лист и ведомый лист, то 1000 записей лимит будет работать в целом или на каждый объект?
2) если при этом записи сохраняются в переменную, то может выпасть [b]лимит по размеру стат-вью[/b]. Но сложно сказать сколько записей потребуется, чтобы выбить этот лимит, так это зависит от кол-во и содержания полученных полей.
3) Лимит по тн хип размеру, как я понял, это то сколько контроллер занимает оперативной памяти во время своей работы. 
4) еще я помню был какой-то лимит по кол-ву выбкверимыемый за раз записей в SELECT операции, но не понял, если он будет превышен в пределах одной операции - то код упадет или SELECT просто отсечет кол-во записей по лимиту.

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

По поводу лимитов:

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

2. лимит по размеру стат-вью очень вероятная штука!!! эту ошибку необходимо больше всего ожидать, когда работает с большими листами, особенно в вложенными!!! Мне приходилось часто бороться с этой проблемой. Проверить свою страницу на предмет view state очень просто - надо включить development mode (и что-то там про view state) в настройках user, открыть страницу, внизу появится дополнительный бар. В нем можно посмотреть view state и увидеть размер всего листа и отдельной его записи. Потом просто посчитать сколько примерно записей можно передать в листе чтобы влезть в 145кб.

3. memory heap size превысить достаточно сложно. Пока у меня единственный пример - когда я выбирал из базы записи с заполенными под завязку Long Text Area полями (32,768 символов). В остальных же случаях, когда объекты с "нормальными" данными, то опасаться нечего.

4. все просто - из базы можно достать максимум 50 000 записей :) Если не ограничивать выборку можно легко влитеть в этот лимит.

[quote="Den Brown"]
И возникла более общая мысль - мысль о том, что если ты в VF странице выводишь список записей, первой твоей мыслью должна быть мысль: "А как я собираюсь ограничивать\регулировать кол-во передаваемый во вью записей? И не просто "ограничивать" (например, рубить выборку LIMITом, как это делается на начальных стадия разработки каст контроллера), а так чтобы это соответствовало логике приложения?" [/quote]
Ограничивать надо ВСЕГДА. Я написал про это в первом ответе.
"[i]сделать страницу без пагинации, но с поиском и фильтрами. И выводить на странице только 100 записей, а если больше 100 записей выводить предупреждение для пользователя чтобы он уточнил критерии поиска.[/i]" Тут весь смысл в [b]max 100[/b] записях на странице в любой момент, независимо от того какой способ ограницения используешь!!! Больший объем пользователю не к чему, кроме как погонять туда сюда скролбар :)

Так что если все запросы к базе всегда заканчиваем конструкцией LIMIT. Иначе это верный путь к ошибке по лимитам.

[quote="Dmitry Shnyrev"]
Так что если все запросы к базе всегда заканчиваем конструкцией LIMIT. Иначе это верный путь к ошибке по лимитам.[/quote]

Да-да, именно так - LIMIT должен быть по-любому. Если применяется пагинация - то это кол-во запрошенных в одну страницу записей -  limit :list_size - в примере выше.

если пагинации нет, а есть только фильтры и поиск - то мы сами задаем лимит - и делаем предупреждение для пользователя если лимит сработал и требуется применять фильтры, иначе некоторые записи пользователь может просто не увидеть.

подниму старую тему про пагинацию списка на ВФ страницы.

собственно пагинации (точнее сказать - разделение на порции) списка для ВФ страницы - это очень важный для понимания вопрос. 

причем "разделение" на порции должно происходить именно в контролере, а не на фронте с помощью JS - так как это вопрос лимитов и просто здравого смысла.

я столкнулся с ситуацией, когда на ВФ странице контроллер (при некоторых сценариях) подает "нелимитированный" список целиком на фронт, где он радостно и беззаботно пагинируется в удобный интерфейс с помощью хитрого JS.

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

Но в целом, решить пагинацию в контроллере можно с помощью использования возможностей стандартного контроллера, это описано здесь:
https://salesforce-developer.ru/paginatsiya-na-visualforce-stranitse-pagination-using-standardsetcontroller

или более кастомно с помощью OFFSET стейтмента в SOQL (где-то я это видел).

т.е. в обоих случаях дробление списка производится с помощью порционного выквериваниея с объета, что очень правильно.

но в случае с той страинцей все немного сложней.
там идет сбор записей из многих объектов, идет упаковка инфы из этих записей в виде Листа экземляров спец класса.

То есть создается один Лист на все записи. И его нужно как-то нужно "пагинировать": так, чтобы он подавал на фронт записи порционно, и так чтобы этот список не сохранялся в виде контроллерного поля (или сделать это поле transient), чтоб список не ушел целиком в СтэйтВью...

есть над чем подумать, пока еще не искал как это решить.

[quote="Den Brown"]я столкнулся с ситуацией, когда на ВФ странице контроллер (при некоторых сценариях) подает "нелимитированный" список целиком на фронт, где он радостно и беззаботно пагинируется в удобный интерфейс с помощью хитрого JS.[/quote]
Это отличный пример как НЕЛЬЗЯ делать.

[quote="Den Brown"]или более кастомно с помощью OFFSET стейтмента в SOQL (где-то я это видел).[/quote]
Нельзя - OFFSET позволяет сдвинуться максимум на 2000 записей.

[quote="Den Brown"]там идет сбор записей из многих объектов, идет упаковка инфы из этих записей в виде Листа экземляров спец класса.[/quote]
Это очень очень очень плохо!
В таком случае нужно создать новый промежуточный объект, записи в котором создавать по заданным условиям, используя ваш хитрый метод объединения. Собирать таким способом записи "на лету" нельзя.

[quote="Den Brown"]есть над чем подумать, пока еще не искал как это решить.[/quote]
Если не предполагается вставка записей НЕ ПО ОЧЕРЕДИ, то лучший способ здесь я вижу - создать промежуточный объект, записывать туда результаты вычислений. В этот объект добавить Счетчик 1,2,3 и так далее (по типу как в обычных базах данных принято создавать Id поле autoincrement) и пагинировать просто как 2 пальца об асфальт - 0..10, 10..20, 20..30 - будет работать как часы.
А так же советую почитать про пагинацию например в Postgresql - очень полезную информацию можно почерпнуть.

А что еще нужно от паджинации? Сортировка, фильтры?
Кастомный доменный объект ведь тоже на чем-то основан, в чем проблема применить паджинацию к основному объекту для нового доменного, а потом строить сам доменный объект?

Позвольте вставить 5 копеек по лимитам.
1000 записей в листе, насколько помню ограничению Visualforce - не SOQL.
Т.е. лист в контроллере может быть больше, но только если он не используется для вывода на страницу.

[quote="ogoblin"]1000 записей в листе, насколько помню ограничению Visualforce - не SOQL. 
Т.е. лист в контроллере может быть больше, но только если он не используется для вывода на страницу.[/quote]

это все верно.
и даже ВФ лимит на 1000 записей в листе можно увеличить переключив атрибут ReadOnly на ВФ странице в тру.

Я уже поднимал эту тему - зачем вам в листе на странице 1000 записей? В большинстве случаев если случается такая проблема - надо смотреть архитектуру. Мне, например, как пользователю было бы не очень приятно листать 1000 записей, а то и больше, как вы хотите сделать.

УПС!

вот схватил следующий лимит у Списочной страницы (использует тот стандартный контроллерный функционал, что описан в блоге https://salesforce-developer.ru/paginatsiya-na-visualforce-stranitse-pagination-using-standardsetcontroller  ):

Maximum view state size limit (135KB) exceeded.

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

    public  List<Object__c> Records { get{
        return (List<Object__c>)setCon.getRecords();
    } set; }

ничего не понимаю

надо смотреть что во view state

похоже, что вот эта штука содержит все выкверренные записи в стейт вью:

public ApexPages.StandardSetController setCon

что делать?

А нет, я модифицировал тот  setCon фрагмент, что в блоге.

а зря... сейчас буду все возвращать как было

PS: все вернул как описано в обновленном (втором) варианте в Блоге - все та же ошибка

[quote="Dmitry Shnyrev"]Я уже поднимал эту тему - зачем вам в листе на странице 1000 записей? В большинстве случаев если случается такая проблема - надо смотреть архитектуру. Мне, например, как пользователю было бы не очень приятно листать 1000 записей, а то и больше, как вы хотите сделать.[/quote]
В данном случае была речь о лимитах как понятии, а не показе пользователю.
Я делал пагинатор максимально на Apex/VF с регулируемым количеством записей. Фильтры также были, но уже позже. Он прекрасно себя чувствовал на 50к записей (не одновременном показе конечно :) ).

Ну так согласен, на apex/vf до 50k с standardSetController это говно вопрос :) 
Может и ламерски, но я когда-то давно про это писал - https://salesforce-developer.ru/paginatsiya-na-visualforce-stranitse-pagination-using-standardsetcontroller
Танцы с бубном начинаются когда у нас больше 50000 записей :)

А про 1000 на VF это я вообще считаю страшным числом. Не важно надо это пользователю показывать или нет. Зачем столько на странице? Если только не стоить какие-нибудь страшные научные графики. Да и то это все можно заранее просчитать и строить графики по агрегированным данным.

Я за то чтобы на странице было максимум то, что нужно в данные момент пользователю. Если надо больше - достаем с сервера.

[quote="Dmitry Shnyrev"]
Я за то чтобы на странице было максимум то, что нужно в данные момент пользователю. Если надо больше - достаем с сервера.[/quote]
+++