Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 78
Вот! Достойноє применениє качеств таких PHP5, как chaining. Подобное я видел и очень даже пользовалса в библиотеке XAJAX, которой и буду продолжать пользоваться, поскольку проект очень-то связан из етим XAJAX... во всяком случае напишу когда-нибудь интерфеснийе блоки к jQuery...
вобщем, на такой скрипт думаю ждали многие.
+1000 разработчикам
вобщем, на такой скрипт думаю ждали многие.
+1000 разработчикам
А будет ли она востребована многими? Ведь приложения все чаще пишут с использованием шаблонизаторов, а не перемежающимся кодом с разметкой. И данная библиотека никак в подобных случаях не применима, что ограничивает круг ее использования(например, можно забыть про smarty && jquery-php).
ЗЫ: против библиотеки ничего не имею
ЗЫ: против библиотеки ничего не имею
По-моему, передавать через AJAX что-то кроме данных (XML, JSON, etc…) не есть кошерно. В то время как все борятся за разделение данных и логики их представления, эта библиотека призвана их смешивать.
Абсолютно согласен! Это все только усложняет и запутывает код и логику!
> В то время как все борятся за разделение данных и логики их представления ...
Не все :) Например вот люди борятся за Web Programming Without Tiers.
Не все :) Например вот люди борятся за Web Programming Without Tiers.
Вы конечно правы, но только отчасти, если взять тривиальную задачу - вывод сообщения с подсветкой (к примеру о отправке письма) - если не использовать данную библиотеку то Вам прийдется описать вызов функции $.ajax и описать функцию на событие success - и так для каждой подобной задачи, а если еще нужно добавить какую-нить логику - то у Вас будет дублирование этой самой логики и в PHP и в JS (по крайней мере Вам надо будет передавать в JS какие-либо параметры отталкиваясь от которых будете производить различные действия)...
Да еще данная бибилотека позволяет использовать всего пару универсальных методов для вызова AJAX.
Да еще данная бибилотека позволяет использовать всего пару универсальных методов для вызова AJAX.
Странно… до сих пор не было а с сегодняшнего дня будет?
Не совсем понял к чему относиться данный комментарий?
К тому, что у меня будет дублирование.
Ок, тогда попробую отстоять свою точку зрения на примерах:
Возьмем "регистрацию" - предположим у нас сушествует 3 реакции на отправку формы:
- регистрация прошла (система отображает сообщение, и скрывает форму)
- регистрация невозможна - внутренняя ошибка(система отображает сообщение о ошибке и скрывает форму)
- регистрация невозможна - т.к. не прошла валидация (отображаем сообщение и оставляем форму подсвечивая поля).
Для реализации данного функционала на javascript в функции обработки ответа Вам прийдется в зависимости от типа ответа (некой переменной) производить различные действия - т.е. описывать логику поведения...
Возьмем "регистрацию" - предположим у нас сушествует 3 реакции на отправку формы:
- регистрация прошла (система отображает сообщение, и скрывает форму)
- регистрация невозможна - внутренняя ошибка(система отображает сообщение о ошибке и скрывает форму)
- регистрация невозможна - т.к. не прошла валидация (отображаем сообщение и оставляем форму подсвечивая поля).
Для реализации данного функционала на javascript в функции обработки ответа Вам прийдется в зависимости от типа ответа (некой переменной) производить различные действия - т.е. описывать логику поведения...
Да, но без использования Вашей библиотеки я буду писать javascript на javascript’e, а не на пхп. А где здесь дублирование чего-то там?
PHP + JS:
Шаг 1. Вы описываете логику и присваиваете некой переменной X значение характерезующее поведение.
Шаг 2. Передаете переменную X и данные
Шаг 3. Обрабатываете X, и в зависимости от ее значения манипулируете данными.
jQuery-PHP + JS:
Шаг 1. Вы описываете логику и описываете поведение.
Шаг 2. Передаете данные (JSON)
Шаг 3. Библиотека выполняет предначертанное.
Шаг 1. Вы описываете логику и присваиваете некой переменной X значение характерезующее поведение.
Шаг 2. Передаете переменную X и данные
Шаг 3. Обрабатываете X, и в зависимости от ее значения манипулируете данными.
jQuery-PHP + JS:
Шаг 1. Вы описываете логику и описываете поведение.
Шаг 2. Передаете данные (JSON)
Шаг 3. Библиотека выполняет предначертанное.
Есть как минимум две разные логики: бизнес-логика (при каких исходных данных авторизация считается успешной, а при каких нет) и логика представления — что нарисовать в браузере для каждого из случаев.
Где что дублируется?
- На стороне сервера, в слое бизнес-логики, описываем правила авторизации.
- Приложение, получая данные из запроса, передает их в слой бизнес-логики и полученный результат передает в слой представления (посредством некоего транспортного слоя: html, json, и т.п.)
- Слой представления (в данном случае браузер) обрабратывает полученные данные и в соответствии с уже загруженными в него javascript и css (файктически, параметризующими слой представления), эти данные отображает — рисует алерты или что-то еще.
Где что дублируется?
С использованием jQuery-PHP в обработке данных в слое представления отпадает надобность, хотя конечно согласен - это не совсем хорошо с точки зрения разделения логики и представления...
Если хранить продукты на книжной полке, в холодильнике тоже необходимость отпадает :)
Да о какой обработке данных вы говорите?
типа о "если ответ 0, тогда... если ответ 1, тогда..."
из-за 2-3 ифов городить огород...
Вы больше потеряете в производительности от генерации кода на сервере,
чем выиграете на экономии if`ов на стороне клиента.
клиент или сервер, чувствуете разницу?
ко всему ещё и страдает разделение логики и представления.
и не тру и не производительно... и зачем тогда всё это?
типа о "если ответ 0, тогда... если ответ 1, тогда..."
из-за 2-3 ифов городить огород...
Вы больше потеряете в производительности от генерации кода на сервере,
чем выиграете на экономии if`ов на стороне клиента.
клиент или сервер, чувствуете разницу?
ко всему ещё и страдает разделение логики и представления.
и не тру и не производительно... и зачем тогда всё это?
"потеряете в производительности" - от появления 2-3 новых объектов я думаю приложение сильно не пострадает, хотя не гуд конечно.
А насчет if-ов - если их было бы 2-3 - то смысла конечно нет, но если у вас на сайте 50 и более различных AJAX обращений к серверу - то этих if-ов (switch-ей) будет не так уж и мало...
А насчет if-ов - если их было бы 2-3 - то смысла конечно нет, но если у вас на сайте 50 и более различных AJAX обращений к серверу - то этих if-ов (switch-ей) будет не так уж и мало...
люди годами шли к разделению приложения на слои. думаете от нечего делать?
тогда расскажите как приложение разработанное с помощью этой библиотеки переживет редизайн сайта. или о том как обстоят дела с повторным использованием кода (сама библиотека не в счет). про юнит тестирование даже и спрашивать не буду - боюсь представить себе эти тест кейсы.
тогда расскажите как приложение разработанное с помощью этой библиотеки переживет редизайн сайта. или о том как обстоят дела с повторным использованием кода (сама библиотека не в счет). про юнит тестирование даже и спрашивать не буду - боюсь представить себе эти тест кейсы.
редизайн сайта, как и вообще поддержка скинов в системе - это действительно будет проблемой если не используется какой-либо единный скелет при верстке дизайна...
насчет юнит-тестирования - тут оно ничем не будет отличаться от тестирования того же сайта с обычной реализацией AJAX-а
повторное использование кода - тут я так же не вижу разницы с обычной реализацией AJAX'a...
насчет юнит-тестирования - тут оно ничем не будет отличаться от тестирования того же сайта с обычной реализацией AJAX-а
повторное использование кода - тут я так же не вижу разницы с обычной реализацией AJAX'a...
при "обычной реализации ajax" серверная сторона вообще не зависит от дизайна (скелета верстки). она лишь обработывает запросы и возвращает результат (данные, а не набор команд)
насчет повторного использования тоже сомневаюсь. уж больно много приходится знать бизнес логике о представлении. ну к примеру - класс "current" и тег которому нужно его поставить. не факт что в следуюещем проекте верстальщик реализует аналогичную вещь тем же набором классов и тегов.
насчет повторного использования тоже сомневаюсь. уж больно много приходится знать бизнес логике о представлении. ну к примеру - класс "current" и тег которому нужно его поставить. не факт что в следуюещем проекте верстальщик реализует аналогичную вещь тем же набором классов и тегов.
Поддерживаю. Сам пользовался xajax'ом и в итоге всё стало только сложней. Где что обрабатывается - достаточно сложно. Разделение задач на контроллеры с данными, темплейты и js линейно я понятно.
фреймвОрк!
меня всегда смущали примеры, где задаются свойства объектам (цвет, фон и прочее). для большинства случаев достаточно установить нужный класс (например - current), а все стили уже задать в CSS. это важно для разделения логики и представления.
может конечно пример неудачный, но пока присоединяюсь к
DeadMoroz
может конечно пример неудачный, но пока присоединяюсь к
DeadMorozНу может не совсем удачный пример с изменением CSS - но точно так же можно использовать функции addClass, removeClass и toggleClass
а зачем мне в php скрипте авторизации к примеру думать о том что нужно какому-то тегу назначить класс current? можно лишь вернуть результат операции, а клиентская сторона пусть думает о том как отреагировать на это событие.
это было бы верно - но вот только клиентскую часть зачастую так же пишет PHP разработчик, так что думать о том, что какому-то элементу нужно назначить определенный класс все-равно прийдется...
да даже если этот же человек еще и верстает - все равно куда проще все разделить - логику авторизации, реакцию на работу с формой авторизации, и собственно ее внешний вид.
просто внешний вид будет меняться от проекта к проекту, реакция на заполнение формы - чуть реже, а вот логика самой авторизации почти всегда остается неизменной.
плюс еще есть такой немаловажный факт - отработка системы в случае если JS отключен. и тут хотелось бы чтобы логика авторизации была той же. если же ее склеить с реакцией на авторизацию - то она либо будет дулироваться - либо будет более сложной.
просто внешний вид будет меняться от проекта к проекту, реакция на заполнение формы - чуть реже, а вот логика самой авторизации почти всегда остается неизменной.
плюс еще есть такой немаловажный факт - отработка системы в случае если JS отключен. и тут хотелось бы чтобы логика авторизации была той же. если же ее склеить с реакцией на авторизацию - то она либо будет дулироваться - либо будет более сложной.
ИМХО авторизация через AJAX и без должна осуществлятся различными файлами (функциями), т.к. в одном случае у Вас должен быть ответ в формате XML или JSON, а в другом - должна полностью перегрузиться вся страница... сама же логика должна вообще быть спрятана, у меня это выглядет приблизительно так :
if ($User->auth($login,$pass)) {
// OK
} else {
$error = $User->getError();
// обработка кодов ошибок
}
if ($User->auth($login,$pass)) {
// OK
} else {
$error = $User->getError();
// обработка кодов ошибок
}
И до этого пользовался php, jQuery без всяких библиотек. От php требуется выплюнуть некий ответ после запроса jQuery, а jQuery обработать его и показать пользователю.
Зачем библиотека?
Зачем библиотека?
В данном случае она служит для передачи чистого html - чтоб как раз-таки на стороне клиента не пришлось ничего обрабатывать и динамически добавлять - банальный innerHTML в нужное место. Где-то это, конечно, и удобно, но чаще всего проще ответить xml'ем и обработать его в js-коде
Ну ведь можно передать чистый html средствами чистого php и чистой jQuery. Покажите мне полезность библиотеки.
Или это для тех, кому лень писать на javascript?
Или это для тех, кому лень писать на javascript?
А пробовали ли вы в Safari с innerHTML работать. При DOCTYPE XHTML 1.0 он игнорирует элементы. Так что спасает только банальный createElement/appendChild.
Так и не понял смысла. Помоему всё это проще без пхп делается :)
не вижу смысла в библиотеке. кусок js кода можно и обычным образом отослать клиенту. просто отправил строку и все.
имхо, не думаю что данная вещь будет удобной, с точки рения 2х моментов:
1. пхп скрипт должен сугубо возвращать response(json, xml, форматированый html etc) и ничего более (мысль можно развить детальнее, но это в общем)
2. если как-то и связывать jQuery с php, то только в качестве модуля к некому шаблонизатору (к тем же Smarty)
1. пхп скрипт должен сугубо возвращать response(json, xml, форматированый html etc) и ничего более (мысль можно развить детальнее, но это в общем)
2. если как-то и связывать jQuery с php, то только в качестве модуля к некому шаблонизатору (к тем же Smarty)
Все же зачем сие нужно? Не убедили, господа, ну не убедили ни разу.
Зачем я должен отказаться от использования
?
Зачем я должен отказаться от использования
if((isset($_SERVER['HTTP_X_REQUESTED_WITH'])) && $_SERVER['HTTP_X_REQUESTED_WITH'] == 'XMLHttpRequest')
{
# handling ajax requests here
}
?
Не совсем понял к чему тут данная конструкция? jQuery-PHP как раз и занимается формированием ответа на AJAX request...
это проверка, что запрос сделан через XMLHttpRequest и данные не передались через POST и GET. а внутри блока уже будет ответ на запрос
Назначение данной конструкция я понимаю, я не понимаю к чему она приведена в данном топике???
наверно это все что нужно от PHP, ответ на запрос. Я, если честно, тоже не понимаю чего вы добиваетесь своей библиотекой :)
Генерировать ответ который бы автоматически выполнялся без лишних телодвижений...
а почему нельзя сделать то же самое в jQuery на стороне клиента и там же где запрос выполнялся? я бы вот сделал такую штуку, чтобы можно было из jQuery вызывать функцию PHP и потом получать данные из неё.
типа
$.ajax({
host:"get.php",
func: "checkLogin",
params: ["login", "password"],
callback: function()
{
alert('Yeahhh!');
}
думаю скор займусь, пока руки не дошли =)
});
типа
$.ajax({
host:"get.php",
func: "checkLogin",
params: ["login", "password"],
callback: function()
{
alert('Yeahhh!');
}
думаю скор займусь, пока руки не дошли =)
});
т.е. суть библиотеки - это уменьшение JS кода на то количество строк IF(...){ , сколько вариантов ответа сервера может быть в данном скрипте...
если вариантов ответа сервера может быть три, то программисту придётся написать на 3 строки меньше.
Может быть вам просто не нравится синтаксис JS и вы заменяете его синтаксисом PHP?
если вариантов ответа сервера может быть три, то программисту придётся написать на 3 строки меньше.
Может быть вам просто не нравится синтаксис JS и вы заменяете его синтаксисом PHP?
Я использую jQuery, чтобы переложить часть нагрузки с сервера на клиента. Мне кажется, что для php-программиста эта функция JS важнее, чем украшательства с помощью JS. При формировании JS на сервере на это тратятся ресурсы, и как следствие распределение нагрузки смещается на сторону сервера. (это первый минус)
jQuery удобен тем, что позволяет быстро, легко и удобно использовать JS, а формирование jQuery на стороне сервера совсем не добавляет удобства, если не на оборот.
Т.е. приходится писать JS в формате jQuery, так ещё и в формате php, который сделает JS в формате jQuery, т.е. получается 2 формата записи одного и того же типа кода, что не совсем удобно. (это второй минус)
В результате минус в производительности и минус в удобстве. Вот такое моё мнение.
Пример AntonShevchuk`a с авторизацией не убедил, т.к. дублирования логики не происходит.
JS послал данные -> php принял решение о валидности авторизации и ответил "окей!" -> JS информирует пользователя о том, что он угадал логин/пароль.
Автор описал функционал своей библиотеки, но не на сайте, не в посте не написал ЗАЧЕМ? он её сделал, может быть в его понимании в её использовании есть смысл, который не сразу виден...
Хотелось бы услышать от AntonShevchuk`a суть/смысл/предназначение библиотеки, только не в примерах, а в теории.
jQuery удобен тем, что позволяет быстро, легко и удобно использовать JS, а формирование jQuery на стороне сервера совсем не добавляет удобства, если не на оборот.
Т.е. приходится писать JS в формате jQuery, так ещё и в формате php, который сделает JS в формате jQuery, т.е. получается 2 формата записи одного и того же типа кода, что не совсем удобно. (это второй минус)
В результате минус в производительности и минус в удобстве. Вот такое моё мнение.
Пример AntonShevchuk`a с авторизацией не убедил, т.к. дублирования логики не происходит.
JS послал данные -> php принял решение о валидности авторизации и ответил "окей!" -> JS информирует пользователя о том, что он угадал логин/пароль.
Автор описал функционал своей библиотеки, но не на сайте, не в посте не написал ЗАЧЕМ? он её сделал, может быть в его понимании в её использовании есть смысл, который не сразу виден...
Хотелось бы услышать от AntonShevchuk`a суть/смысл/предназначение библиотеки, только не в примерах, а в теории.
С первым минусом конечно нельзя не согласиться (хотя нагрузка мизерна), насчет второго я бы поспорил - мне как раз наооборот - удобно формировать ответ сервера так, как будто я пишу на javascript'е с использованием jQuery и при этом не задумываюсь о том, как же всё таки ловить и обрабатывать ответ сервера. Собственно это и было целью написания данной библиотеки...
xAjax наше все
Вот разработчикам jQuery как PHP так и Javascript - хочеться сделать donate!
php генерирует код jQuery, который генерит код JS, который генерит HTML, хм.. :))
Еще бы эту либу в смарти встроить, со всеми ее функциями.
Simplicity PHP Framework (основан на ExtJS)
http://www.antz29.com/
http://www.antz29.com/
все же, не понимаю я смысла этой библиотеки... хм...
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
PHP библиотека для jQuery