[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: PHP Шаблонизатор
undercloud
Всем доброго дня! Я тут создал новый шаблонизатор для PHP http://undercloud.github.io/ant/.
Возможно кому нибудь понравится, интересно Ваше мнение, предложения, баг репорты и т.д.
redreem
Цитата (undercloud @ 23.05.2016 - 15:52)
создал новый шаблонизатор для PHP


еще один? нафига создавать шаблонизаторы для шаблонизатора?
T1grOK
Не вижу смысла. Если мне понадобится псевдо язык программирования для шаблонов, то я возьму twig.
А вообще от html на стороне php стоит уже отходить. Пишем API, a фронтент во главе с JS выполняет к нему запросы и формирует на основе данных уже готовую страницу.
Соответственно backend работает максимально изолированно от frontend.

_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api
Invis1ble
Цитата (undercloud @ 23.05.2016 - 14:52)
Всем доброго дня! Я тут создал новый шаблонизатор для PHP http://undercloud.github.io/ant/.
Возможно кому нибудь понравится, интересно Ваше мнение, предложения, баг репорты и т.д.

Для начала стоило бы описать его отличия и преимущества/недостатки по сравнению с существующими решениями.
Лично я не буду тратить своё время на самостоятельную добычу этой информации.

_____________

Профессиональная разработка на заказ

Я на GitHub | второй профиль

sg.com
Цитата (Invis1ble @ 23.05.2016 - 20:01)
Для начала стоило бы описать его отличия и преимущества/недостатки по сравнению с существующими решениями.
Лично я не буду тратить своё время на самостоятельное изучение этой информации.

согласен, может он и лучше других, но на самостоятельное изучение время неохота тратить.
Ron
Цитата (T1grOK @ 23.05.2016 - 15:52)
Пишем API, a фронтент во главе с JS выполняет к нему запросы и формирует на основе данных уже готовую страницу.

Кстати, у меня вопрос: где в этом случае будет храниться шаблон? Подозреваю что на сервере. Зачем дергать JSON и HTML с сервера и собирать всё на клиенте? Для чего такая нелогичная жопа?

Изменять информацию на странице таким образом можно. Но генерить с нуля весьма сомнительная идея.

А что будут делать поисковики? До тех пор пока не научились в полном объеме обрабатывать JS, номрального разделения не видать. Но мне думается, что такая обработка хоть и возможна теоретически, но не реализуема на практике ввиду ограниченной мощности поисковых роботов. Это как использование ресурсов клиента через JS, только ровно наоборот. Централизация процессов и сосредоточение в датацентрах. Сравнивать общую мощность всех серверов в интернете и "жалкого" датацентра (даже гугла), все-равно что футбольный мяч с луной.

И это. Говорить что PHP - шаблонизатор по-моему неразумно. Да, язык встраеваемый. Но и ассемблер можно встроить в сишный код. Дальше что?

redreem
Цитата (Ron @ 24.05.2016 - 00:42)
И это. Говорить что PHP - шаблонизатор по-моему неразумно.


объясни, что есть по сути шаблонизаторы?
заменялы одних кусков кода другими.
приведи пример выгодного использования шаблонизатора в сравнении с нативным кодом.
про верстальщиков, не желающих учить пару-тройку языковых конструкций можешь не писать.
Zzepish
redreem
Тогда можно говорить, что все ЯП - шаблонизаторы
redreem
Цитата (Zzepish @ 24.05.2016 - 03:20)
Тогда можно говорить, что все ЯП - шаблонизаторы

подумай еще раз.
Ron
Цитата (redreem @ 24.05.2016 - 01:03)
приведи пример выгодного использования шаблонизатора в сравнении с нативным кодом.

redreem, это холиварный вопрос, о пользе применения шаблонизаторов. И не в нем суть. Я хочу сказать (и по возможности доказать), то что ЯП, в частности PHP, не относится к категории шаблонизаторов ни по каким из его свойств. Это существенно более низкий уровень.

Шаблонизатор - абстракция над ЯП для удобства решения конкретной задачи. Например, наследование шаблонов самый яркий импрувмент. Только не надо говорить что его можно реализовать в 3 строки. biggrin.gif

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

redreem
Ron
ну круто, чо.
Ron
Цитата (redreem @ 24.05.2016 - 05:00)
ну круто, чо.

Ну как бы да, только php != шаблонизатор. )
Цитата (redreem @ 23.05.2016 - 15:16)
нафига создавать шаблонизаторы для шаблонизатора?



T1grOK
Цитата (Ron @ 23.05.2016 - 19:42)
Кстати, у меня вопрос: где в этом случае будет храниться шаблон? Подозреваю что на сервере. Зачем дергать JSON и HTML с сервера и собирать всё на клиенте? Для чего такая нелогичная жопа?

Как раз здесь все логично, прозрачно, удобно и универсально.
Шаблоны это отдельный репозиторий с доступом исключительно для фронтенд разработчиков, для которых главное, чтоб знать куда обратиться за нужными данными. Остальное они сделают как душе угодно, с любыми свистоперделками, не зная при этом ни о PHP, ни о Python, вообще не зная, что там на backend-е.
На backend-e используется единое api, для браузерных версий ресурса, для мобильных Android, IOS, для предоставления возможностей работы с ресурсом со сторонних систем.
Не так давно перешли на такую схему разделения backend от frontend в компании и честно говоря это очень удобно. По сути, на текущий момент мы строим приложения в виде микросервисной архитектуры, где нет MVC, а только MC smile.gif, V как уже сказал, отдельно - в гордом одиночестве) следует идеологии web components.

_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api
chee
T1grOK, как ни странно V у вас все-таки есть, вы же данные в что-то сериализуете, а потом каким-то образом это отдаете на клиент. Какая разница (кроме расходов на саму сириализацию), сериализуешь ты данные в html, либо в json, это всё равно представление для внешнего клиента.

По шаблонизатору: вроде бы ок, но идеологической составляющей в нём нет, то есть он не лучше других, но при этом ни чем не отличается от них по своей идеологии.

_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации
Ron
T1grOK, для внутренних решений полностью поддерживаю идеологию API. Если сайт потом требуется продвигать, то данная архитектура совершенно не подходит. И боюсь что в этом отношении никогда не завоюет рынок.
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.