Раскрывающийся многоуровневый список записей

Всем привет,

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

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

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

давайте начну от того, в каком виде мы может выводить списки:

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

(2) необычные способы визуализации списка: список в виде Событий на календарной сетке или анимированной галереи.

(3) и раскрывающийся многоуровневый список записей.

возьмем пример, есть записи Участники, у них есть такой атрибут как Город (а это ссылка на запись в объекте Города), а у города есть атрибут Район (а это ссылка на запись в объекте Районы), а у района есть атрибут Страна (а это ссылка на запись в объекте Страны).

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

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

Т.о. в таком четырех-уровневом списке мы фактически организуем вывод сразу четырех списков разных объектов (но не польных, а фильтрованных). Это интересно.

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

Den Brown

Всем привет,

в этой теме мне хотелось бы обсудить тему кастомного выведения списка записей.

как известно, на сайте у нас нет стандартных лейаутов, и все приходится пилить в ручную (что и есть один из наших програмистских хлебов).

сегодня столкнулся с примером раскрывающегося многоуровневого списка записей, и это заставило меня задуматься: а что есть такой список?

давайте начну от того, в каком виде мы может выводить списки:

(1) традиционный - это список записей, обязательно (или желательно) с пагинацией, часто с возможностью фильтрации выборки по атрибуту записи плюс иногда есть функционал по упорядовачиванию списка.

(2) необычные способы визуализации списка: список в виде Событий на календарной сетке или анимированной галереи.

(3) и раскрывающийся многоуровневый список записей.

возьмем пример, есть записи Участники, у них есть такой атрибут как Город (а это ссылка на запись в объекте Города), а у города есть атрибут Район (а это ссылка на запись в объекте Районы), а у района есть атрибут Страна (а это ссылка на запись в объекте Страны).

и на нашей странице мы сначала видим список стран, кликаем на одной из них (и страница перегружается или асинхронно), и открывается подсписок с районами, принадлежащим к этой стране, затем кликаем на районе и видим подспиок городов и затем доходим до участников, живущих в этом городе.

вначале я подумал, что такую страницу правильнее назвать Список атрубутов с соответвующими записями, но пока это писал, я понял, что это не просто атрубуты - это записи в др объектах. Таким образом такая страница - это цепочка списков записей из разных, связанных с собой объектов, так что открывающийся уровень показывает записи по связи от одного-ко многому (те новый уровень - это вроде как список связанных записей на дитейл лейуте).

Т.о. в таком четырех-уровневом списке мы фактически организуем вывод сразу четырех списков разных объектов (но не польных, а фильтрованных). Это интересно.

если у кого-то был опыт создания таких страниц и не сложно дать пример, то дайте, но конечно я позже еще погуглю тему сам

Для данной задачи использую обычный tree view + lazy loading на каждый уровень

Gres

Для данной задачи использую обычный tree view + lazy loading на каждый уровень

Gres

использую обычный tree view

Ты вот это имеешь в виду?
http://techsahre.blogspot.com/2011/03/simple-sf-tree-for-vf-page.html

Dmitry Shnyrev

[quote="Gres"]использую обычный tree view[/quote]
Ты вот это имеешь в виду?
http://techsahre.blogspot.com/2011/03/simple-sf-tree-for-vf-page.html

Den Brown

возьмем пример, есть записи Участники, у них есть такой атрибут как Город (а это ссылка на запись в объекте Города), а у города есть атрибут Район (а это ссылка на запись в объекте Районы), а у района есть атрибут Страна (а это ссылка на запись в объекте Страны).
и на нашей странице мы сначала видим список стран, кликаем на одной из них (и страница перегружается или асинхронно), и открывается подсписок с районами, принадлежащим к этой стране, затем кликаем на районе и видим подспиок городов и затем доходим до участников, живущих в этом городе.

По описанию очень похоже на связанные списки. Просто "многоуровневые списки" это больше про деревья, как написал Gres.
Я как-то писал связанные списки. В принципе ничего сложного - можно легко стандартными средствами Visualforce страницы сделать. Хотя способов реализации с помощью JS я думаю много.
Я делал просто 4 выпадающих списка, на которых висел обработчик onchange и renreder. При изменении любого из списков на сервер уходили состояния списков и дочерние списки пересчитывались в зависимости от значений парентов. Если данные статичные, то можно вообще сразу все данные на страницы выгрузить и работать уже чистым JS.

Dmitry Shnyrev

[quote="Den Brown"]возьмем пример, есть записи Участники, у них есть такой атрибут как Город (а это ссылка на запись в объекте Города), а у города есть атрибут Район (а это ссылка на запись в объекте Районы), а у района есть атрибут Страна (а это ссылка на запись в объекте Страны).
и на нашей странице мы сначала видим список стран, кликаем на одной из них (и страница перегружается или асинхронно), и открывается подсписок с районами, принадлежащим к этой стране, затем кликаем на районе и видим подспиок городов и затем доходим до участников, живущих в этом городе.[/quote]
По описанию очень похоже на связанные списки. Просто "многоуровневые списки" это больше про деревья, как написал Gres.
Я как-то писал связанные списки. В принципе ничего сложного - можно легко стандартными средствами Visualforce страницы сделать. Хотя способов реализации с помощью JS я думаю много.
Я делал просто 4 выпадающих списка, на которых висел обработчик onchange и renreder. При изменении любого из списков на сервер уходили состояния списков и дочерние списки пересчитывались в зависимости от значений парентов. Если данные статичные, то можно вообще сразу все данные на страницы выгрузить и работать уже чистым JS.

Gres

Для данной задачи использую обычный tree view + lazy loading на каждый уровень

Обычно существует 2 варианта.

1. Загрузка всего дерева за 1 раз.
2. Так называемая загрузка по требованию.

В 1 обычно исползуется рекурсия и вывод уже готового HTML на странице. Так же в последнее время активно используется для этого JSON и AngularJs

2 описAл Gres

wilder

[quote="Gres"]Для данной задачи использую обычный tree view + lazy loading на каждый уровень[/quote]

Обычно существует 2 варианта.

1. Загрузка всего дерева за 1 раз. 
2. Так называемая загрузка по требованию.

В 1 обычно исползуется рекурсия и вывод уже готового HTML на странице. Так же в последнее время активно используется для этого JSON и AngularJs

2 описAл Gres

wilder

В 1 обычно исползуется рекурсия и вывод уже готового HTML на странице.

Кстати да. Помню один раз маялся с составлением дерева на стороне Visualforce страницы, а потом оказалось что собрать готовый html прямо в контролере (в рекурсивном методе) и просто вывести на страницы одим тегом вообще простая задача.

Dmitry Shnyrev

[quote="wilder"]В 1 обычно исползуется рекурсия и вывод уже готового HTML на странице.[/quote]
Кстати да. Помню один раз маялся с составлением дерева на стороне Visualforce страницы, а потом оказалось что собрать готовый html прямо в контролере (в рекурсивном методе) и просто вывести на страницы одим тегом вообще простая задача.

Dmitry Shnyrev

Ты вот это имеешь в виду?
http://techsahre.blogspot.com/2011/03/simple-sf-tree-for-vf-page.html

как вариант, использую плагин для jquery

Gres

[quote="Dmitry Shnyrev"]Ты вот это имеешь в виду?
http://techsahre.blogspot.com/2011/03/simple-sf-tree-for-vf-page.html[/quote]
как вариант, использую плагин для jquery

Dmitry Shnyrev

В принципе ничего сложного - можно легко стандартными средствами Visualforce страницы сделать.

Из начально как раз было 4 селекта с ренлерингом на серверной стороне, но как же это все долго работает.
Вообще, в последнее время стараюсь все писать на js + использую веб сервисы для работы с данными. На мой взгял это очень удобный подход.

Gres

[quote="Dmitry Shnyrev"]В принципе ничего сложного - можно легко стандартными средствами Visualforce страницы сделать.[/quote]
Из начально как раз было 4 селекта с ренлерингом на серверной стороне, но как же это все долго работает.
Вообще, в последнее время стараюсь все писать на js + использую веб сервисы для работы с данными. На мой взгял это очень удобный подход.

Gres

js + использую веб сервисы для работы с данными

Именно веб-сервисы, не remote actions? Я использую последние! Очень удобно и плюс, нет лимитов по Api calls.

Dmitry Shnyrev

[quote="Gres"]js + использую веб сервисы для работы с данными[/quote]
Именно веб-сервисы, не remote actions? Я использую последние! Очень удобно и плюс, нет лимитов по Api calls.

Dmitry Shnyrev

Именно веб-сервисы, не remote actions? Я использую последние! Очень удобно и плюс, нет лимитов по Api calls.

Раньше использовал remote actions, сейчас перешел на webservice. Да проблемы с лимитами исчезают при использовании такой архитектуры.

Gres

[quote="Dmitry Shnyrev"]Именно веб-сервисы, не remote actions? Я использую последние! Очень удобно и плюс, нет лимитов по Api calls.[/quote]
Раньше использовал remote actions, сейчас перешел на webservice. Да проблемы с лимитами исчезают при использовании такой архитектуры.

Gres

Dmitry Shnyrev
Именно веб-сервисы, не remote actions? Я использую последние! Очень удобно и плюс, нет лимитов по Api calls.

Раньше использовал remote actions, сейчас перешел на webservice. Да проблемы с лимитами исчезают при использовании такой архитектуры.

А я вот наоборот планирую перейти с вебсервиса на Remote Action. Но это потребует какого-то времени.

wilder

[quote="Gres"][quote="Dmitry Shnyrev"]Именно веб-сервисы, не remote actions? Я использую последние! Очень удобно и плюс, нет лимитов по Api calls.[/quote]
Раньше использовал remote actions, сейчас перешел на webservice. Да проблемы с лимитами исчезают при использовании такой архитектуры.[/quote]

А я вот наоборот планирую перейти с вебсервиса на Remote Action. Но это потребует какого-то времени.

wilder

А я вот наоборот планирую перейти с вебсервиса на Remote Action. Но это потребует какого-то времени.

А в чем проблема?
Не нравится SOAP?

Gres

[quote="wilder"]А я вот наоборот планирую перейти с вебсервиса на Remote Action. Но это потребует какого-то времени.[/quote]
А в чем проблема?
Не нравится SOAP?

Кст, никто Rest сервисы не юзает?

Gres

Кст, никто Rest сервисы не юзает?

Gres

Кст, никто Rest сервисы не юзает?

Сколько не брался за их изучение, так и не нашел реального применения.

Dmitry Shnyrev

[quote="Gres"]Кст, никто Rest сервисы не юзает?[/quote]
Сколько не брался за их изучение, так и не нашел реального применения.

Dmitry Shnyrev

Сколько не брался за их изучение, так и не нашел реального применения.

Ну применение то в общем такое же.

Gres

[quote="Dmitry Shnyrev"]Сколько не брался за их изучение, так и не нашел реального применения.[/quote]
Ну применение то в общем такое же.

<blank>

Dmitry Shnyrev

[i]<blank>[/i]

Gres

wilder
А я вот наоборот планирую перейти с вебсервиса на Remote Action. Но это потребует какого-то времени.

А в чем проблема?
Не нравится SOAP?

Для моих нужд Remote action лучше чем СОАП.

wilder

[quote="Gres"][quote="wilder"]А я вот наоборот планирую перейти с вебсервиса на Remote Action. Но это потребует какого-то времени.[/quote]
А в чем проблема?
Не нравится SOAP?[/quote]

Для моих нужд Remote action лучше чем СОАП.

Gres

Кст, никто Rest сервисы не юзает?

Я иногда использую.

wilder

[quote="Gres"]Кст, никто Rest сервисы не юзает?[/quote]

Я иногда использую.

Gres

Кст, никто Rest сервисы не юзает?

Использовал на паре проектов, очень доволен. Сложностей никаих в общем-то нет, легче и быстрее SOAP.

Дмитрий Черник

[quote="Gres"]Кст, никто Rest сервисы не юзает?[/quote]

Использовал на паре проектов, очень доволен. Сложностей никаих в общем-то нет, легче и быстрее SOAP.