UMIhelp
Управление сайтом на UMI.CMS => Наполнение сайтов => Тема начата: 31rus от 16 Марта 2012, 00:05:49
-
Здравствуйте. Прошу помоши у всех кто может дать дельный совет. Требуется создать портал типа желтых страниц, множество объектов каталогах разделенных по районам и городам. На этапе проектирования структуры столкнулся с проблемой. Суть следующая:
На базе каталога в umi будут заносится карточки предприятий. В области 4 районых центра в каждом N количество городов. В каталоге 5 корневых разделов в каждом из которых по N количеству подразделов с несколькими уровнями вложенности. 2 домена или языковых версий.
Все бы ничего если бы одно предприятие могло быть только в одном городе или районе, но может быть и такое что филиалы могут находится в разных местах (городах, районах), а также предприятия без адреса или чей адрес не важен, например радиостанция, она должна всегда показываться вне зависимости от какой район или город.
На ум приходит несколько решений:
1. В качестве корневых разделов использовать районы, а дальше фильтровать по полю город. Те объекты которые имеются в смежных районах, делать виртуальную копию.
2 Создавать разделы и объекты каталога как есть, создавать поля регионов и городов в необходимом количестве, пользователю все вываливать одним списком в конкретном разделе а фильтрацию возложить на jquery тем самым снизить нагрузку на сервер.
3 Создать аналог второго, но все отбирать через selector, беря за основу сортировки выбранный регион и город пользователем или выводить все если ничего не выбрано.
И в довесок как лучше на ваш взгляд организовать информацию на разных языках?
-
я бы сделал предприятие отдельной сущностью, а его местоположение уже задавалось выпадающим списком или т.п. чтобы потом по ним фильтровать, фильтровать через jquery (не думаю что самая удачная идея, так как насколько я понимаю для этого придется выгрузить все объекты, а потом уже работать с ними через jquery), лучше через usel или кастомные варианты
Особое внимание уделяй оптимизации всего что делаешь, чтобы не делал старайся использовать как можно меньше ресурсов, так как нагрузка большая будет.
Насчет языков, попробуй в начале перенести какой-нибудь интернет магазин на другую яз. версию, много интересного встретишь. На таком большом проекте будет сложновато обкатывать полноценный языковой перенос, а вот второй домен реально использовать
-
Да однозначно все через usel.
я пообщался с Владимиром из umi-cms.spb вото что он написал:
Вы все правильно видите, у вас получается, что каталог с данными должен быть отдельно, а каталог для посетителей - совершенно никак с ним не связан. А это убивает все преимущество ЮМИ - наглядность дерева страниц. К тому же, работать с многотысячными каталогами в ЮМИ тоже не сахар.
Если только ЮМИ, я бы создавал каталог карточек в скрытой от посетителей директории, группировал бы их как удобнее для редактора сайта. А для посетителей выборки на кастомных макросах или UMI.Framework. И чтобы он никогда не попадал на страницу с предприятием, т.к. тогда начнется путаница с активными пунктами меню и навибаром; пусть попадает на некую фиктивную страницу, которая уже программно читает данные предприятися и выводит в нужной форме.
А мне приходит в голову такая мысль:
1 Каждый район это поддомен, во всех поддоменах виртуальные копии каталога
Под каждый район свой шаблон с макросом или в общем шаблоне указывать что при обращении с данного домена выводить так то по такому макросу с выборкой.
Тогда у нас нет путаниц с адресами и меню, все ведет так как надо и куда надо относительно данного домена
2 Каждая языковая версия это район, во всех версиях виртуальные копии каталога
Под каждый район свой шаблон с макросом или в общем шаблоне указывать что при обращении с данного языка выводить так то.
Тогда у нас нет путаниц с адресами и меню, все ведет так как надо и куда надо относительно данной языковой версии (района), оперируем pre_lang для параметров макросов. (не знаю, можно ли создавать виртуальные копии в разные языковые версии)
Как на твой взгляд такое решение?
-
много всяких мелочей, которые надо подробнее рассматривать. Но я бы попробовал следущий вариант.
Создаем все организации в одной папке. У каждой организации есть поля для фильтра (Районный центр, Город и т.д.).
Создаем структуру разделов используя страницы типа "Раздел каталога", только мы этот раздел каталога немного модифицируем и добавляем в его тип данных такие же поля фильтра в итоге у нас получается примерно такая структура в админке
-главная
-...
-Районный центр1
--Город1
---раздел организаций1(напр. Спорт)
---...
--Город2
--Город3
--...
-Районный центр2
-...
-Скрытый раздел с организациями
--организация1
--организация2
--... и т.д.
на каждой странице раздела ге должны выводиться список организаций, указываем в полях фильтра (в разделе каталога) что именно там должно выводиться (например
организации со значением районный центр, равным "Районный центр1" и городом, равным "Город1" и так далее. То есть выбираем значения фильтра которые определят какие организации будут выводиться в данном разделе.
А потом пишем шаблон для разделов каталога, которые будут выводить результаты usel запроса согласно значениям полей фильтра в данном разделе каталога применяя их на организации.
Опять же остается вопрос с индексацией, есть вопрос, с навибаром при переходе на просмотр конкретной организации, есть вопрос с работой с таким кол-вом организаций (удобно было бы чтобы все организации были типом данным "объект каталога", тогда в модуле "Каталог" можно было бы выводить каждое поле и делать выборки в админке для удобства работы менеджера с контентом).
Но все эти вопросы уже надо решать исходя из задачи.
Но по хорошему, этот вопрос надо прорабатывать комплексно и делать новый тип данных, который будет работать по принципу объектов и рубрик, к которым могут быть привязаны организации. С соответствующей правкой админ интерфейса, htaccess (или чего то еще чтобы путь к странице в адресной строке менялся динамически в зависимости от того в каком разделе мы смотрим данную организацию) и т.п.