Спустя это время я больше не работаю с Битрикс, обхожу его стороной. Что использую не скажу, так-как здесь за это по головке не погладят. Проекты на Битрикс для меня как территория отчуждения, типа Чернобыля, движок в саркофаге, но фонит.
02.12.2014 12:07:05
|
|||
|
24.07.2014 13:28:47
|
|||
|
24.07.2014 12:44:12
|
|||
|
24.07.2014 11:32:03
|
|||
|
24.07.2014 03:48:05
|
|||
|
11.12.2012 19:38:08
В документации Битрикс
Там так: "Алгоритм работы паттерна MVC примерно таков: на основании действий пользователя Controller (контроллер) определяет, какое View (представление) должно быть показано пользователю, и отдает управление этому View (представлению); View (представление) запрашивает необходимые ему данные у Model (модели), получает эти данные и выводит их соответствующим образом пользователю; пользователь с помощью каких-либо элементов управления, которые ему предоставил View (представление), посылает новый запрос в Controller (контроллер)." Должно быть так: Контроллер получает данные от пользователя и передаёт их Модели. Модель запрашивает необходимые данные, обрабатывает данные и возвращает Контроллеру ответ. Контроллер на основании ответа определяет какой View должен быть показан пользователю (чаще это определяет Модель, а Контроллер просто выполняет непосредственное подключение нужного View) и отдаёт управление этому View. View выводит данные на страницу пользователю. Пользователь с помощью каких-либо элементов управления, которые ему предоставил View и Контроллер, посылает новый запрос в Контроллер. Где больше логики? |
|
|
01.06.2012 13:37:00
Оказывается структура инфоблоков компонента Статьи находится в xml файле в дирректории модуля Инфоблоки. То есть Компонент Статьи входит в состав Модуля Инфоблоки, а его структура включена в поставку Модуля. Я планирую свои компоненты поставлять так, чтобы можно было вручную инициализировать множество экземпляров инфоблоков для этих компоентов, чтобы например иметь на сайте несколько разделов статей не связанных между собой ничем. А для уже имеющихся компонентов из поставки Битрикс я сделаю экспорт инфоблоков в xml стандартным средством, тогда можно будет создать сколько угодно экземпляров инфоблоков этих компонентов.
|
|
|
07.05.2012 19:23:43
Конструктивизм мной приветствуется. Итак, по пунктам:
1. "На практике выборка из таблицы элементов с индексом по IBLOCK_ID очень эффективна. Тесты не показывают хоть какой-то существенной разницы от выборки из отдельных таблиц. Здесь на форуме это уже неоднократное обсуждалось, с цифрами результатов теста." Это я понял, что идея сделать всё в одной таблице - дань производительности в ущерб традициям релиционных баз данных созданными многими поколениями профессоров американских университетов и защитивших дессертации на эту тему. 2. "Зато в таком способе хранения элементов есть важное преимущество: сквозная выборка из нескольких инфоблоков." Это приемущество только в том, что за счёт такой архитектуры - сквозная выборка может быть реализована "ленивым кодом". На самом деле нет ни одной задачи, которую нельзя было бы реализовать программно, при любой архитектуре данных, Вы это и сами прекрасно понимаете. Лучше бы вы написали программный код посложнее, нежели нарушили кононы информационной инженерии. 3. "Что касается переноса инфоблоков, то я вас квалифицированно заверяю, что рано или поздно ID элементов хоть в одной таблице, хоть в разных таблицах все равно со временем рассинхронизируются." Вы имеете ввиду в Битрикс? Да, в Битриксе они рано или поздно - рассинхронизируются, но в классической БД - всё будет неизменным в веках. 4. "Связи между элементами необходимо делать по символьным или внешним кодам, о чем выше уже говорилось." Это справедливо только для статей, но для форумов нет. Где вы видели, чтобы каждой теме форума давался символьный код? Не бывает такого. Вообще симпольные коды для другого придуманы - чтобы была человекочитаемая ссылка, а не цифровой номер страницы. Вы ещё предлагаете делать внешние коды - а чем тогда эти коды будут отличаться от внутренних ID таблиц? Не легче ли Битрикс вернуться к стандартам баз данных и автоматом создавать всем таблицам свои внутренние ID таблиц? Конечно же легче. Но поезд ушёл, Битрикс уже не может себе позволить признать такой серьёзный недостаток, иначе маркетинговый отдел будет в шоке. 5. "Довод про поисковую оптимизацию несостоятелен, т.к. в рамках одного проекта ID уже не изменяется." У меня были планы держать инфоблоки одного сайта в разных базах данных, ещё я планировал переносить сайты из одной многосайтовой системы в другую, теперь этому всему не суждено сбыться. Я наверное уйду из Битрикс. 6. "Кроме того, вы можете URL страницы формировать по символьному коду, а не ID." Повторение мать учения: если всем объектам задавать символьный код, то легче тогда следовать правилу - каждому инфоблоку по внутреннему ID. Дело в том, что у меня сайты, в которых очень много объектов, которые создают рядовые пользователи. Заставить их писать каждому создаваемому ими объекту символьный код - наивно. Писать модуль, который бы автоматически создавал внутреннюю индексацию - унизительно, когда это по традиции есть во всех бесплатных CMS, а я плачу деньги и не имею этого. |
|
|