Чем не устраивают существующие цмс? Лучше подумайте 10 раз, перед тем как делать новый велосипед. Я например для проектов использую HOSTCMS - могу сказать что для меня она лучшая по след. причинам: 1. Удобство работы с шаблонами - сколько нужная вложенность шаблонов + последний - XSL шаблон - для управления данными. 2. Простота настройки. 3. Простота натяжки верстки. 4. Простота использования для наполнения. 5. Отличные маны, как для пользователей цмс, так и для разработчиков. в итоге - ключевое для меня преимущество - быстрота разработки проекта. Добавлено спустя 1 минуту 55 секунд: А смарти это всего лишь шаблонизатор. И вам всё равно придется подгонять код под проект. + ко всему Смарти реально не удобен в том плане, что он непривычно "вписывается" в шаблоне.
Мне в шаблонизаторах нравятся две вещи: - более краткий синтаксис записи как управляющих конструкций, так и всяких вспомогательных. Не сильно, но есть. Особо когда нужно обработать блок внутри шаблона, или банальные вещи типа "последний элемент массива" и т.п. К этому можно приблизится путем создания кучи классов хелперов, ну т.е. создавая по сути свой шаблонизатор. - возможность некого дефолтного поведения вывода. Мне, например, очень нравится возможность вывод переменных по-умолчанию эскейпить, отменяя когда нужно. Ограниченность синтаксиса шаблонизатора, к слову, тоже имеет свой плюс - мешает "накодить быстренько логику прямо в шаблоне". В минусах - нужно изучать синтаксис. Производительность не сильно страдает, если шаблонизатор компилит шаблоны в нативные php шаблоны.
с этого места можно подробнее? я просто обхожусь без шаблонизаторов просто потому что считаю их избыточными и при этом не добавляющими никакого полезного функционала. Ну вобщем,я никакими хелперами не пользуюсь. Что за хелперы, как они выглядят, чем полезны?
мад скилз по какой-нибудь навороченной CMS, особенно коммерческой, действительно даёт профит в сайтостроении, но тогда ты развиваешься как веб-мастер, а не программист.
CMS из коробки - только конструктор, с ограниченным функционалом. Есть реальный заказчик, со своими реальными требованиями. Заколебся перекраивать готовое (существующее) в CMS из коробки, сама CMS из коробки накладывает массу ограничений, которые нужно обходить.
Узнать последний элемент или первый массива. Произвести какое-то действие над блоком текста в шаблоне (типограф какой-нить, например, писать всякие ob_start). Эскейпинг и работа со строками со всякими дефолтными параметрами типа кодировки. Наследование шаблонов, инклуд без всяких там километровых путей. В общем куча плюшек, решение которых напрямую на пхп в шаблоне делает его еще более плохо читаемым. Добавлено спустя 2 минуты 27 секунд: Хотя, имхо, идеальный шаблонизатор должен уметь работать с html по принципу jQuery, но на уровне PHP. Единственное что - нагрузки тут уже будут побольше - DOM в PHP строить.
Еще раз. Пожалуйста, пишите свою мысль развернуто. Узнавание первого и последнего члена массива делается силами похапе нативно и очень кратко несколькими способами в зависимости от задачи. ничо не понял прошу пример Наследование шаблонов это что? может быть, может быть. Видимо это такая тайна, что ее все очень упорно охраняют не сговариваясь.
Ты можешь иметь набор модификаций каких-то модулей CMS и вместо разработки по индивидуальным требованиям, делать встречное предложение, как реализовать те или иные функции. В основном заказчики просто хотят то, что видели на других сайтах и совсем не против изменить свои требования, если ты сможешь убедить их в преимуществе своего предложения. (с)Если бы программисты строили дома
Основное - не хочу быть зажатым готовыми решениями CMS. Не все там гладко(на готовеньком), частенько большие чудеса происходят, и в самый не подходящий момент
>Узнавание первого и последнего члена массива делается силами похапе нативно и очень кратко Приведи. Что-то по краткости равное if loop.last. Т.е. не делая каких-то предварительных count, $i++ и т.п. >ничо не понял Мои проблемы что ли? {% tipograf %} <p>sdfweorgweoiuhgewiuhgfre</p> {% endtipograf %} >прошу пример Какой пример? О том, что можно избежать написания htmlspecialchars везде, и самое главное - не забыть это случайно сделать? Или о том, что в htmlspecialchars куча параметров, которые могут потребоваться везде? > Наследование шаблонов это что? http://twig.sensiolabs.org/doc/templates.html#template-inheritance >Видимо это такая тайна, что ее все очень упорно охраняют не сговариваясь. Может просто никому не нужно тебя убеждать в чем-то? По-этому никто и не пытается вспомнить? Документация открыта - бери, смотри, прикидывай какие вещи удобно использовать и сколько придется написать на PHP для этого.
бро, ты ведь в курсе, что: 1) серверная сторона никак не влияет на клиентскую; 2) php - серверная сторона; 3) внезапно, DOM-а не существует вне браузера. Браузер получает текст с разметкой (хытымылы), парсит, делает из этого дела DOM. При этом мы можем просить браузер так или иначе оперировать с DOM посредством стандартизированного API в виде JS, обработчик которого является так же частью браузера.
ЛОЛ. Граббер в пример привел, и? Что оно сделает с уже готовой страницей, которую уже отдал сервер? Скачает ее и распарсит хорошенько?
О_о ложки нет? Научись не грубить. Это парсер html. Работает как аналогичный в браузере. Ну ок. На серверной стороне ты сгенерил, а потом распарсил зачем-то документ. Что дальше? Отдаешь его клиенту? Окай. Все, больше он тебе не принадлежит. Ты можешь только скромно верить, что твои JS-ки будут делать на стороне клиента то, что тебе надо, не более того. Гарантий нет никаких. Да, в php есть парсилка html, есть парсилка xml, это все здорово. Но на клиентскую часть ты никак не повлияешь ими. Это просто парсилки.
Просто скажи - что именно тут тебе не понятно? Буковки, слова... что именно? С чего ты вдруг про какой-то клиент заговорил.
Мне не понятно, зачем ты хамишь чуть что. Даже не знаю. Наверное потому что операции с DOM имеют смысл только на клиентской стороне, а на серверной нафиг не нужны(если конечно ты не ставишь целью спасрить и перепилить с чужого сайта страницу), потому что если клиенту надо отдавать чистый html, то и генерь его сразу там где надо и так как надо. А то это как украсть бочку спирта, продать, а деньги пропить
Так бы и спросил - нафига. Все очень просто - есть куча операций, которые проще потом сделать с html, чем плодить кучу IF. Проще и гораздо лучше читается. Например, повесить класс на последний элемент списка, скрыть какие-то элементы и т.п. Т.е. берем что-то вроде phpQuery, и приделываем его к шаблонизатору. Что бы можно было сказать pq(".table TD:last")->addClass("last"); Где-то уже после создания в цикле таблицы. Вместо попытки в этом цикле определить последний TD и приделать класс. Все это на PHP. И уже потом это отдается клиенту.
ды не суть, не о том речь Добавлено спустя 3 минуты 4 секунды: Псевдоклассы CSS не дял этого разве? Ну, в целом стало понятнее, что ты задумал. Но, ИМХО, это надо решать правильной структурой проекта, а не лопатить то, что нагенерилось. То есть организовывать сразу так, чтобы все корректно генерилось. У меня вон, проектик, работает без кучи IFов и ничо
Ну есть проектик вообще без одного IF-а и цикла... да в общем даже переменной нет ни одной. А популярный жуть. Hello world! назвается, может слышали.