Jump to content


Photo
- - - - -

Как лучше сделать - один каталог или много каталогов?


  • This topic is locked This topic is locked
6 replies to this topic

#1 tri

tri
  • JBZoo User (rus)
  • User rate: 0
  • posts: 58
  • topics: 16

Posted 09 August 2013 - 07:48

С первого дня приобретения Jbzoo мучает вопрос правильной организации каталога недвижимости.

До сегодняшнего дня был создан каталог новостроек.

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

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

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

Со всеми типами кроме каталога новостроек смогут работать пользователи с фронта (добавлять, удалять с помощью submission).

Поначалу придерживался разделения, сейчас уже склоняюсь собрать все в одном. Получается будет много материалов в скором будущем.

Господа разработчики, перечислите главные плюсы и главные минусы этих 2 вариантов беспристрастно и скажите свое личное мнение.

Заранее благодарен...

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


  • 0

#2 joejoker

joejoker
  • JBZoo User (rus)
  • User rate: 6.8
  • posts: 305
  • topics: 5

Posted 09 August 2013 - 08:19

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


  • 1
В мире все совсем не сложно, если самому не усложнять.
Разработка индивидуальных решений для ZOO /JBZoo /Joomla

#3 3d

3d
  • JBZoo User (rus)
  • User rate: 0
  • posts: 96
  • topics: 33

Posted 15 August 2013 - 10:16

Возможность связать элементы из разных каталогов есть. Для этого использовал решение от ZOOLanders - Related items Pro. Он позволяет увязать элементы из разных каталогов. Но нужно очень внимательно читать для того, чтобы правильно все сделать и связать их. Точного рецепта не скажу пока- сам в процессе.


  • 0

#4 Станислав

Станислав
  • JBZoo User (rus)
  • User rate: 18
  • posts: 211
  • topics: 7

Posted 15 August 2013 - 13:24

Возможность связать элементы из разных каталогов есть. Для этого использовал решение от ZOOLanders - Related items Pro. Он позволяет увязать элементы из разных каталогов. Но нужно очень внимательно читать для того, чтобы правильно все сделать и связать их. Точного рецепта не скажу пока- сам в процессе.

 

Ну нормуль, чо... 39 евро за 1 элемент, который прилично увеличивает число запросов к MySQL, что в итоге для нормальной работы заставит вас покупать приличный ВДС или даже арендовать сервер для тех проектов, которые потянули бы на жирном, но shared хостинге. 

 

Могу сказать по опыту одно: если есть возможность, то нужно делать все в одном каталоге (экземпляре приложения).

 

В разные каталоги, с моей точки зрения, стоит разносить только при одном условии - если у вас количество категорий зашкаливает за 1-1,5 тысячи, иначе вы просто не сможете ими нормально управлять из-за неудобного интерфейса и громадного потребелния памяти браузера (проверено на всех основных браузерах - IE, Firefox, Opera, Google Chrome, Maxthon, Safari) джава-скриптом этого интерфейса. При количестве категорий примерно 4-5 тысяч управление категориями в админке еле-еле работает. Количество айтемов в этом случае даже не играет роли, только количество категорий.


  • 0

«Ну и зачем все это, лучше бы водки выпили». Из писем Белинского Гоголю.

 


#5 3d

3d
  • JBZoo User (rus)
  • User rate: 0
  • posts: 96
  • topics: 33

Posted 15 August 2013 - 13:32

Ну нормуль, чо... 39 евро за 1 элемент, который прилично увеличивает число запросов к MySQL, что в итоге для нормальной работы заставит вас покупать приличный ВДС или даже арендовать сервер для тех проектов, которые потянули бы на жирном, но shared хостинге. 

 

Могу сказать по опыту одно: если есть возможность, то нужно делать все в одном каталоге (экземпляре приложения).

 

В разные каталоги, с моей точки зрения, стоит разносить только при одном условии - если у вас количество категорий зашкаливает за 1-1,5 тысячи, иначе вы просто не сможете ими нормально управлять из-за неудобного интерфейса и громадного потребелния памяти браузера (проверено на всех основных браузерах - IE, Firefox, Opera, Google Chrome, Maxthon, Safari) джава-скриптом этого интерфейса. При количестве категорий примерно 4-5 тысяч управление категориями в админке еле-еле работает. Количество айтемов в этом случае даже не играет роли, только количество категорий.

Да я в принципе согласен с Вами....)))) 

Просто в данном случае Эти примочки позволяют связать различные каталоги с разными типами материалов. Да и вообще...

Например ГугельКартаПро позволяет не просто вводить адрес или координаты, а просто Тыцнуть где нужно.

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

Если вводить в каталог 1000 категорий, то мне кажется есть смысл использовать что-то отличное от Джумлы)))

 

П,С. - А насчет 39 евро....))) Вы можете купить, да.. Но .. Гугль в помощь. Я нашел...


  • 0

#6 Станислав

Станислав
  • JBZoo User (rus)
  • User rate: 18
  • posts: 211
  • topics: 7

Posted 15 August 2013 - 14:21

Да я в принципе согласен с Вами....)))) 

Просто в данном случае Эти примочки позволяют связать различные каталоги с разными типами материалов. Да и вообще...

Например ГугельКартаПро позволяет не просто вводить адрес или координаты, а просто Тыцнуть где нужно.

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

Если вводить в каталог 1000 категорий, то мне кажется есть смысл использовать что-то отличное от Джумлы)))

 

П,С. - А насчет 39 евро....))) Вы можете купить, да.. Но .. Гугль в помощь. Я нашел...

 

По поводу Related Items Pro. Когда-то потратив вечером 2-3 часа на протяжении 1 недели на доскональное изучение элементов Zoo, я просто-напросто начал встраивать собственные элементы в некоторые коммерческие решения, чтобы избежать хаков, но получить требуемое.

 

Идея простая. Чаще всего релейтеды между приложениями решают задачу связи один-ко-многим между сущностями: Производитель - Товары производителя, Продавец - Товары продавца, Покупатель - Заказы покупателя и т.п., то есть по выбранному типу в одном приложении выводится список айтемов нужного типа из другого приложения.

 

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

 

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

 

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

 

Мало того, используя такое решение, я могу выводить даже такие сложные структуры как Продавец - Товары продавца - Покупатели конкретного товара продавца (на SQL это вложенные JOIN'ы), что Related Items Pro вроде бы не делает.

 

Остальные 2 примера - это, мягко говоря, журнал мурзилка :) Вечер работы на допил элемента :)

 

По поводу использовать нечто отличное от Джумлы: не всегда выбор движка - прерогатива исполнителя :) Встречались товарищи, которые на магазин из 200 товаров использовали Мадженто  >:(  

 

 

P.S. Насчет поиска в Гугле... Ай-ай-ай  B)  ::)


Edited by Станислав, 15 August 2013 - 14:27.

  • 1

«Ну и зачем все это, лучше бы водки выпили». Из писем Белинского Гоголю.

 


#7 3d

3d
  • JBZoo User (rus)
  • User rate: 0
  • posts: 96
  • topics: 33

Posted 15 August 2013 - 14:32

По поводу Related Items Pro. Когда-то потратив вечером 2-3 часа на протяжении 1 недели на доскональное изучение элементов Zoo, я просто-напросто начал встраивать собственные элементы в некоторые коммерческие решения, чтобы избежать хаков, но получить требуемое.

 

Идея простая. Чаще всего релейтеды между приложениями решают задачу связи один-ко-многим между сущностями: Производитель - Товары производителя, Продавец - Товары продавца, Покупатель - Заказы покупателя и т.п., то есть по выбранному типу в одном приложении выводится список айтемов нужного типа из другого приложения.

 

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

 

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

 

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

 

Мало того, используя такое решение, я могу выводить даже такие сложные структуры как Продавец - Товары продавца - Покупатели конкретного товара продавца (на SQL это вложенные JOIN'ы), что Related Items Pro вроде бы не делает.

 

Остальные 2 примера - это, мягко говоря, журнал мурзилка :) Вечер работы на допил элемента :)

 

По поводу использовать нечто отличное от Джумлы: не всегда выбор движка - прерогатива исполнителя :) Встречались товарищи, которые на магазин из 200 товаров использовали Мадженто  >:(  

 

 

P.S. Насчет поиска в Гугле... Ай-ай-ай  B)  ::)

Согласен на 100%, но!

Клиенты бывают разные - как Вы сами заметили. А по сему - и бюджеты бывают разные.))) и, следовательно, и объем работ соответствующий... 
Я бы рад платить, но адекватно нашим условиям, бюджетам и клиентам.
Не хочу техническую беседу переводить в иную плоскость, а потому предлагаю на сим остановиться - сколько людей, столько и мнений!)))


  • 0




Click to return to top of page in style!