Есть ли в системе унифицированная парадигма обращения к обектам и их свойствам? У меня сложилось впечатление, что каждый шаблон представляет собой замкнутую систему со своим жестким набором переменных, и своей структуруой сетов для образования документа, а для каждого шаблона есть свой обработчик. Верно ли это?
Второй важный момент - это работа с объектами и их свойствами. Например, есть объект "единица товара" со своим определенным набором параметров и свойств. Имя, описание, картинка и т.д. Вот как обращаться к свойствам объектов? Пока что я вижу, что в шаблонах используются внутренние переменные ##var## для обозначения свойств. Причем эти переменные определены тайным образом где-то в обработчике шаблона. Между шаблонами эти переменные не работают, даже если в разных шаблонах идет работа с одним и тем же объектом. Подскажите, как мне обращаться к свойствам объектов, если в шаблоне эти свойства ни разу не использовались и я, соответственно, не могу знать как называется переменная для нужного мне свойтства. Можно ли прям вот как в любом объектно-ориентированном коде использовать структуры product.id, product.name, product.price и т.д. и где про это почитать?
Добавлено: Работа с объектами в системе22.02.11 14:15:48
Я сначала отвечу на вопросы, а потом прокомментирую, основываясь на своем долгом опыте работы с Амиро.
Oleg: Есть ли в системе унифицированная парадигма обращения к обектам и их свойствам? У меня сложилось впечатление, что каждый шаблон представляет собой замкнутую систему со своим жестким набором переменных, и своей структуруой сетов для образования документа, а для каждого шаблона есть свой обработчик. Верно ли это?
Начну с ответа на второй вопрос. Да, верно. Обработчики шаблонов находятся в коде, и формирование страницы идет с использованием сетов по правилам, заданным в коде. Каждому сету на вход подается определенное окружение переменных.
Публичного метода обращения к определенным свойствам объекта из произвольного сета нет.
Oleg: Подскажите, как мне обращаться к свойствам объектов, если в шаблоне эти свойства ни разу не использовались и я, соответственно, не могу знать как называется переменная для нужного мне свойтства. Можно ли прям вот как в любом объектно-ориентированном коде использовать структуры product.id, product.name, product.price и т.д. и где про это почитать?
Во-первых, можно посмотреть, какие передаются в сет переменные:
Во-вторых, в большинстве случаев если переменные отсутствуют в сете, они там не нужны. Да, бывают исключения, но их можно пересчитать по пальцам.
Теперь субъективное мнение.
Я видел изнутри много разных сайтов - и где код перемешан с отображением так, что смена дизайна крайне сложна; и где при малейших нагрузках, система переставала работать; и где система была настолько "правильно" спроектирована, что просто создавала избыточную нагрузку; и многое другое. В любой системе есть свои минусы и плюсы - идеала нет.
Безусловно, как программиста, меня возмущает, что такого стандартного механизма нет. Я тоже хочу все процессы же контролировать. Но, как руководителя веб-студии, я понимаю, что не имея такой возможности, я получаю другие:
1. человек, интегрирующий сайт, не замедлит его больше, чем может позволить система. Он не напишет лишних медленных запросов, не создаст лишние циклы, выполняющие ненужную работу и т.п.
2. человек никогда не удалит (или забудет добавить) из системы предусмотренные в ней механизмы расчетов (скидки, доставки, конвертации валют и т.п.). И если владелец сайта включит какую-то возможность, которую он не использовал раньше, все будет работать, как положено
3. для обучения работы с системой, не надо учить интегратора программированию - знания HTML вполне достаточно
Учитывая все плюсы и минусы, я считаю, что для реализации стандартного функционала магазина, шаблонов достаточно. Ну а для того, чтобы сделать то, чего нет в стандартном, следует смотреть . При помощи API Вы можете прочитать данные непосредственно из базы данных (по фильтру, в определенном порядке и т.п.), и использовать их.
НО! Не далее, чем на прошлой неделе, к нам попал в руки сайт, в котором было использование API. Но использование было настолько не оптимальным, что при анализе генерации страницы, нами было зафиксировано более 1000 (!) запросов к базе данных. Мы сделали оптимизации, и свели к обычному количеству запросов, и добились, чтобы все эффективно кешировалось. А требуемый заказчиком функционал мы свели к _стандартному_ функционалу Амиро (с полной поддержкой кеширования) без использования АПИ вообще. Причем, с точки зрения стоимости, наше решение близко к созданному ранее, но мы просто обладали чуть большим опытом, поэтому наше решение эффективнее.
Это вполне говорящий пример - как только есть возможность что-то сделать просто, человеческий мозг пытается сделать это. Но, к сожалению, прямое решение не всегда самое оптимальное. И при наличии опыта, можно использовать имеющиеся в Амиро механизмы, чтобы решать большинство задач. А АПИ, скорее, нужно уже для чего-то, что является не совсем стандартным.
Чтобы добавить сообщение, пожалуйста .
Всего тем: 6661
Всего сообщений: 27851
Всего зарегистрированных пользователей: 26750
Последний зарегистрированный пользователь: Антон Сагателян
Авторизация
