Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 30
Думается мне, что развитие проекта не просто так остановилось. Все-таки генерить JavaScript с помощью PHP идея не самая здравая.
Если вам хочется все целиком разрабатывать в одиночку и не радует зоопарк технологий — посмотрите в сторону sencha, или даже nodeJs+sencha, например.
Для интранет-приложений, имхо, это будет самое то.
Если вам хочется все целиком разрабатывать в одиночку и не радует зоопарк технологий — посмотрите в сторону sencha, или даже nodeJs+sencha, например.
Для интранет-приложений, имхо, это будет самое то.
Посмотрю, спасибо.
Собственно, генерации JS как таковой там нет — есть общий обработчик, который занимается связью с сервером и является прослойкой между PHP и объектами DOM.
Собственно, генерации JS как таковой там нет — есть общий обработчик, который занимается связью с сервером и является прослойкой между PHP и объектами DOM.
Дело даже не в самой генерации как таковой, просто при подобном подходе не могут не появиться всякие искуственные ограничения, из-за которых придется делать хаки и т.д. В результате в сложном проекте минусов от такого подхода будет намного больше, чем плюсов.
Что-то у меня мозг ломается. Не могли бы вы описать подробнее как это происходит?
Ну если на примерах с сайта:
Иными словами, есть класс, соответствующий странице.
При помощи методов этого класса можно работать с DOM-объектами на этой странице — читать из форм, менять содержимое, удалять-добавлять классы — фактически, всё, что умеет jquery.
На элементы страницы можно навесить обработчики — либо в HTML-коде тегом «xt-bind» как в примере — «при событии click вызвать метод echoMessage», либо то же самое со стороны PHP.
Функционал обработки этих событий берёт на себя фреймворк.
<input type="text" name="text1" id="text1" size="50" value="" />
<input type="submit" name="submit1" id="submit1" value="Submit" xt-bind="click,echoMessage" />
<div id="echoText" xt-autoupdate="true"></div>
protected function echoMessage($e) {
$message = $this->post->textVal('text1'); // sanitize input text
$message = 'You have entered <span>"'.$message.'"</span>';
$this->echoText->html($message); // echo message to page
}
Иными словами, есть класс, соответствующий странице.
При помощи методов этого класса можно работать с DOM-объектами на этой странице — читать из форм, менять содержимое, удалять-добавлять классы — фактически, всё, что умеет jquery.
На элементы страницы можно навесить обработчики — либо в HTML-коде тегом «xt-bind» как в примере — «при событии click вызвать метод echoMessage», либо то же самое со стороны PHP.
Функционал обработки этих событий берёт на себя фреймворк.
Немного напоминает ASP.NET WebForms, если я правильно понимаю.
Покапался чуток в Raxan'е, ничего необычного не заметил. По первому взгляду, он показался мне просто JS фреймворком + библиотечка на PHP, которая согласованно работает с JS фреймворком.
Много ИМХО:
Вполне хороший способ универсализации/упрощения, но не более. Но как это обычно бывает, ещё одна абстракция верхнего уровня уменьшает производительность ПО в общем.
Посмотрел что ходит между клиентом и сервером, и заметил очень много мусора (избыточных данных, которые по сути не нужны) и формат не особо понравился. Я не говорю, что это никуда не годится. Хочу лишь сказать, что он больше подходит для маленьких проектов «для себя» или прототипов, которые нужно быстро собрать. Сомневаюсь, что кто-то рискнёт использовать Raxan в продакшене на каком-нибудь хайлоад проекте, где каджый байт (а то и бит) трафика, каждая миллисекунда ожидания очень дорога, где необходимо делать узконаправленную оптимизацию. Вот для этого не годится, а в общем, вполне занятная штука ;)
Много ИМХО:
Вполне хороший способ универсализации/упрощения, но не более. Но как это обычно бывает, ещё одна абстракция верхнего уровня уменьшает производительность ПО в общем.
Посмотрел что ходит между клиентом и сервером, и заметил очень много мусора (избыточных данных, которые по сути не нужны) и формат не особо понравился. Я не говорю, что это никуда не годится. Хочу лишь сказать, что он больше подходит для маленьких проектов «для себя» или прототипов, которые нужно быстро собрать. Сомневаюсь, что кто-то рискнёт использовать Raxan в продакшене на каком-нибудь хайлоад проекте, где каджый байт (а то и бит) трафика, каждая миллисекунда ожидания очень дорога, где необходимо делать узконаправленную оптимизацию. Вот для этого не годится, а в общем, вполне занятная штука ;)
> Все-таки генерить JavaScript с помощью PHP идея не самая здравая.
Почему нет? Я у себя во фреймворке практикую подобное и достаточно успешно. Правда, до описанного в топике подхода не доходил, но затея интересная. Тоже сейчас всё чаще приходится к AJAX обращаться. Пока это касается в первую очередь админки, а там всё автоматизировано на уровне описания модели, но во фронтенде давно пора переходить на автоматизацию.
На тестовом уровне я использовал модульный подход — в шаблоне указываю «использовать AJAX-модуль, класс такой-то», класс имеет два варианта выдачи контента, статический, при создании страницы (в т.ч. с возмжностью статического кеширования в файловой системе) и динамический, который будет вставлен через AJAX после загрузки статической страницы пользователем. Вся работа с JS от меня, как целевого программиста, скрыта оказывается. Но это простой случай. Вариант, когда логику работы JS-клиента можно описать на сервере (не обязательно PHP, можно и в шаблоне) мне кажется интересным. Надо будет реализовать…
Что я упускаю, полагая, что генерит JS из PHP — вполне здравая идея?
Почему нет? Я у себя во фреймворке практикую подобное и достаточно успешно. Правда, до описанного в топике подхода не доходил, но затея интересная. Тоже сейчас всё чаще приходится к AJAX обращаться. Пока это касается в первую очередь админки, а там всё автоматизировано на уровне описания модели, но во фронтенде давно пора переходить на автоматизацию.
На тестовом уровне я использовал модульный подход — в шаблоне указываю «использовать AJAX-модуль, класс такой-то», класс имеет два варианта выдачи контента, статический, при создании страницы (в т.ч. с возмжностью статического кеширования в файловой системе) и динамический, который будет вставлен через AJAX после загрузки статической страницы пользователем. Вся работа с JS от меня, как целевого программиста, скрыта оказывается. Но это простой случай. Вариант, когда логику работы JS-клиента можно описать на сервере (не обязательно PHP, можно и в шаблоне) мне кажется интересным. Надо будет реализовать…
Что я упускаю, полагая, что генерит JS из PHP — вполне здравая идея?
Идея действительно интересная, но в MVC вписывается плохо.
Результат немного предсказуем.
Результат немного предсказуем.
Я могу ошибаться, но не аналогичный ли принцип используется при разработке под Windows, например? Есть элементы интерфейса, на них навешиваются обработчики событий, по срабатыванию события контроллер что-то делает. Вполне себе MVC.
Как мне кажется — наоборот, это упрощает код, потому что вся логика собирается в одно место.
Как мне кажется — наоборот, это упрощает код, потому что вся логика собирается в одно место.
Почему плохо вписывается? Это уж смотря как использовать. Да и, в принципе, на MVC свет клином не сошелся.
Вписывается плохо, потому что приводит к смешиванию контроллера и представления, как результат — сильное связывание.
конечно, на MVC свет клином не сошелся, но на данный момент это доминантный архитектурный паттерн, на котором основано большинство популярных фреймворков.
конечно, на MVC свет клином не сошелся, но на данный момент это доминантный архитектурный паттерн, на котором основано большинство популярных фреймворков.
View это все-таки не просто html, это также логика отображения.
Тут точно также можно запихнуть эту логику во View, просто выглядеть будет немного странненько.
Как раз и приходим к тому, что на самом деле проще было бы во VIew писать на JavaScript.
Тут точно также можно запихнуть эту логику во View, просто выглядеть будет немного странненько.
Как раз и приходим к тому, что на самом деле проще было бы во VIew писать на JavaScript.
Имел ввиду писать на JavaScipt писать именно ту часть, которая описана в подходе фреймворка.
При этом так написанный JS будет работать быстрей, и не будет проблем с конфликтующими событиями и т.д.
Я согласен, что всё, специально написанное, лучше.
Может быть, есть какие-то специализированные механизмы для упрощения этих задач, на JS?
Ну классический пример — проверка существования юзера при регистрации. Форма ввода username теряет фокус — срабатывает JS-обработчик-1, отправляется ajax-запрос на сервер, на сервере его принимает PHP-Обработчик, проверяет существование такого имени и возвращает ответ. На клиенте, соответственно, срабатывает JS-Обработчик-2 и рисует красный крестик или зелёную галочку.
На RAXAN это всё решается пятью строчками PHP. В классическом подходе — запутанным обменом между клиентом и сервером.
Чем и как это можно решить ещё?
Может быть, есть какие-то специализированные механизмы для упрощения этих задач, на JS?
Ну классический пример — проверка существования юзера при регистрации. Форма ввода username теряет фокус — срабатывает JS-обработчик-1, отправляется ajax-запрос на сервер, на сервере его принимает PHP-Обработчик, проверяет существование такого имени и возвращает ответ. На клиенте, соответственно, срабатывает JS-Обработчик-2 и рисует красный крестик или зелёную галочку.
На RAXAN это всё решается пятью строчками PHP. В классическом подходе — запутанным обменом между клиентом и сервером.
Чем и как это можно решить ещё?
Во-первых не стоит гнаться за количеством строчек.
5, 10 или 15 не важно — главное чтобы они внятные были, на остальное есть IDE
Для задач, когда форм много, можно и универсальное что-то сделать, но на самом JavaScript, так чтобы и получалось 5 строчек в сумме.
Но для этого фреймворк не нужен, и возможно от проекта к проекту универсальность будет разная.
Смысл в том, что не надо отказываться от Javascript стараясь все писать на PHP, это к добру не приведет.
Я много и с радостью пишу на PHP, но я бы вам в вашем случае, тогда советовал бы отказаться от PHP и писать все на JavaScript вместе с серверной частью — это просто логичнее и многих вопросов просто не будет.
5, 10 или 15 не важно — главное чтобы они внятные были, на остальное есть IDE
Для задач, когда форм много, можно и универсальное что-то сделать, но на самом JavaScript, так чтобы и получалось 5 строчек в сумме.
Но для этого фреймворк не нужен, и возможно от проекта к проекту универсальность будет разная.
Смысл в том, что не надо отказываться от Javascript стараясь все писать на PHP, это к добру не приведет.
Я много и с радостью пишу на PHP, но я бы вам в вашем случае, тогда советовал бы отказаться от PHP и писать все на JavaScript вместе с серверной частью — это просто логичнее и многих вопросов просто не будет.
В MVC хорошо вписываются только совсем простые статические решения. Если что-то более сложное, начинаются всякие MVP/MVVC/MVVM. Вот в них вполне себе вписывается. Если представление чуть сложнее статики, то от контроллера представления никуда не деться. Вот и задачи обработки JS-активности вполне, ИМХО, гармонично вешаются на контроллер представления.
> В MVC хорошо вписываются только совсем простые статические решения.
категорически не согласен. Если четко разделять зоны ответственности слоев, модели получаются довольно универсальными, а контроллеры тонкими, предоставляя вьюшке простор для маневров.
Что касается MVP и MVVM — это производные от MVC, использование которых во-первых довольно нишевое, а во вторых часто приводит к излишней сложности архитектуры.
категорически не согласен. Если четко разделять зоны ответственности слоев, модели получаются довольно универсальными, а контроллеры тонкими, предоставляя вьюшке простор для маневров.
Что касается MVP и MVVM — это производные от MVC, использование которых во-первых довольно нишевое, а во вторых часто приводит к излишней сложности архитектуры.
посмотрите Yii www.eha.ee/labs/yiiplay/index.php/en/person/admin
На хабре была статейка про Wt, который теоретически позволяет вообще абстрагироваться от HTML, CSS и JavaScript. Правда сам он на C++.
На Хабре уже упоминался этот фреймворк — ExtJS и его подсистема Ext.Direct.
Краткое и толковое введение в Ext.Direct
Хочу сказать, что знание Ext.JS это очень полезное знание. Не побоюсь сказать, что на сегодняшний день это самый развитый и богатый функционалом JS фреймворк. Он не очень прост в изучении, но время потраченное на его освоение того стоит.
Краткое и толковое введение в Ext.Direct
Хочу сказать, что знание Ext.JS это очень полезное знание. Не побоюсь сказать, что на сегодняшний день это самый развитый и богатый функционалом JS фреймворк. Он не очень прост в изучении, но время потраченное на его освоение того стоит.
Мне больше по душе писать все самому с нуля в итоге имею полностью подконтрольный мне проэкт, который я знаю как своих 5 пальцев, знаю где исправить и что можно оптимизировать, а что переделать. На прожорливые фреймворки смотрю с ухмылкой…
В целом желание писать всё на одном языке понятно.
Но мне кажется что если уж если пытаться так делать, то лучше взять язык который создавался преследуя как раз такие цели.
Один из таких языков это Dart. Возможно вам имеет смысл посмотреть в его сторону.
Но мне кажется что если уж если пытаться так делать, то лучше взять язык который создавался преследуя как раз такие цели.
Один из таких языков это Dart. Возможно вам имеет смысл посмотреть в его сторону.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Raxan, или веб-программирование в одиночку