Задать вопрос
SerafimArts
@SerafimArts
Senior Notepad Reader

Двухсторонний шаблонизатор?

Господа хорошие, задам довольно необычный вопрос. Подскажете ли вы, есть ли на свете белом шаблонизатор, который умеет исполняться и на стороне сервера (PHP или Ruby, хотя если что-то подобное есть в других вариациях — тоже будет замечательно) и на стороне клиента? В идеале — с возможностью восстановления исходного варианта после «компиляции» (но это мечты)



Если не понятно зачем, объясняю. Есть у нас шаблон на сервере (все мы знаем — смарти, xsl, blade, haml, slim, jade и прочее), обрабатываем его и отправляем клиенту результат. Клиент получает html код и радуется. А теперь добавим немного аякса. В идеале — мы отловили тег «a» и ссылку «href», сделали запрос на сервер — получили новый шаблон и json данные для его заполнения. Вставили куда надо данные, показали пользователю и подменили url через history api.



Если совместить эти два варианта — можно получить следующую картину: Открываем страницу — получили статику, переходим по страницам — грузим их динамически, добавив сюда кеширование шаблонов (ну например в localStorage\IndexedDb\WebSQl и проч.) — получаем идеальную ситуацию, когда имеем полностью асинхронный ресурс и при этом ни шаблоны, ни контроллеры (сервера) совершенно никак не надо под это дело подстраивать. Вот как-то так, надеюсь доступно объяснил.



По поводу «восстановления после сборки» — небольшой каприз — делать так, что бы уже первая загрузка статичного варианта позволяла JS коду понять шаблон и его закешировать, и при взаимодействии с ним (новый комментарий добавляем, плюсуем рейтинг, переходим по страницам — не важно что) — можем сразу же работать с уже существующими данными.
  • Вопрос задан
  • 5969 просмотров
Подписаться 9 Оценить Комментировать
Решения вопроса 1
Fesor
@Fesor
Full-stack developer (Symfony, Angular)
Пригласить эксперта
Ответы на вопрос 8
AMar4enko
@AMar4enko
Дело в том, что вы старательно пытаетесь игнорировать тот факт, что в требованиях пришли к single page application на JS. И пробуете найти какой-то подход, который оставит вас в рамках текущей парадигмы разработки.
А решения уже придуманы давно и их очень много, можно выбирать на любой вкус. И все он заключаются в том, что на сервере шаблонизации нет вообще - там только данные.
Все взаимодействие с фронтом через REST API.

Единственное, что может вызвать проблему в этом случае - индексация такого приложения браузером. Но и тут есть решение, требующее минимального вмешательства в код сервера - вы просто делаете снэпшоты страницы, требующих индексации, например с помощью PhantomJS, после чего отдаете их как статику с сервера при запросе от бота.
Ответ написан
Anonym
@Anonym
Программирую немного )
XSLT можно рендерить и на сервере и на клиенте.
Но в вашем случае проще всё отображать на клиенте, а с сервера присылать только layout страницы и данные в json.
Ответ написан
k12th
@k12th
console.log(`You're pulling my leg, right?`);
mustache имеет реализации на нескольких языках.
Ответ написан
Комментировать
@egorinsk
Шаблоны перенести недостаточно, вам еще придется переносить модели и частично бизнес-логику на клиент (если только у вас не примитивный сайтик на 3 странички). На мой взгляд, избежать двойной работы можно лишь используя технологии вроде node.js: в этом случае можно часть кода с логикой сделать разделяемой для клиента и сервера.

Ну или еще есть вариант, как-то настроить кодогенерацию и генерировать JS-модельки на основе серверного кода.
Ответ написан
SerafimArts
@SerafimArts Автор вопроса
Senior Notepad Reader
<deleted> (промахнулся веткой)
Ответ написан
Комментировать
Mendel
@Mendel
PHP-developer
Сейчас плотно курим такой подход:
Вьювы с помощью простых классов генерируют простой хтмл через ДОМ.
Этот код не содержит оформления, а только контент, более менее семантично оформленный.
Для оформления используется CSS и JS
Я знаю что все так делают, но я имею ввиду ВСЁ оформление выносить туда.
Примерно вот так:
jsfiddle.net/x8mmC/

На выходе имеем стройный хтмл, который является очень даже семантичным, достаточно красиво выглядит и без оформления, понимается поисковиками, и заметно меньше по размеру.
Со стороны вьюва мы имеем обычный ооп код, который можно так или иначе наследовать, расширять, инкапсулировать и т.п.
Если интерфейс достаточно продуман, то верстальщику вполне достаточно будет не трогать хтмл а обходиться жс. (см пример).

Всё вышеописаное в принципе у нас работает, хоть и не до конца отлажено.
Но вот что еще хочется сделать — по аяксу отдавать не новую страницу, а ее разницу в сравнении с текущей.
т.е. некий DOMdiff или в виде jquery (как стиль в примере) или в более сжатом виде — не важно.
НО пока до этого не доходят руки. Надо для начала формализовать первую часть, переписать все классы на чистовик и т.п.
Ответ написан
sHinE
@sHinE
веб-разработчик, php/js/mysql и сопутствующее
Лично не пробовал, но недавно видел ссылку на статью, где, судя по описанию, решают вашу проблему:
www.phpied.com/server-side-react-with-php/
www.phpied.com/server-side-react-with-php-part-2/
Правда, насколько я понял, там идет обертка в php для JS-движка.
Ответ написан
Slavenin999
@Slavenin999
программист php/erlang/elixir/js
у себя пользую smarty + jsrender.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы