Comments 21
Вы забыли привести область применения. Имхо, при условии любой реализации паттерна MVC все вышеизложенное приобретает очертания двухколесного транспортного средства.
Не расписаны плюсы и минусы данного подхода.
Почему необходимо вызывать именно отдельные функции/методы скрипта, а не целиком скрипт, передавая параметры?
Почему необходимо вызывать именно отдельные функции/методы скрипта, а не целиком скрипт, передавая параметры?
Плюсы - удобная разработка несколькими программистами одного кода.
Минус может быть лишь в том, что выполнение кода будет не оптимальным. Но это опять-же зависит от программиста - как он этим будет пользоваться и оптимизировать.
Минус может быть лишь в том, что выполнение кода будет не оптимальным. Но это опять-же зависит от программиста - как он этим будет пользоваться и оптимизировать.
Почему необходимо вызывать именно отдельные функции/методы скрипта?
Иначе теряется модульность. Возможно есть несколько модулей (например фото-галлерея, видео-галлерея), которые друг с другом не связанны и в любой момент их можно просто отсоеденить/присоеденить (удалив/добавив include).
Иначе теряется модульность. Возможно есть несколько модулей (например фото-галлерея, видео-галлерея), которые друг с другом не связанны и в любой момент их можно просто отсоеденить/присоеденить (удалив/добавив include).
Потом придём к пониманию, что далеко не все вызовы разрешены и закончится процесс разработкой API. Не совсем в тему, но вспомнилась цитатка: "Все воруют. Просто ты честней других. Ты искренне сочиняешь чужое."
Что вы имеете ввиду под "не все вызовы разрешены"?
Я расписал несколько примеров - там, помойму, нечего уже добавить. Всё просто и универсально.
Я пишу эти статьи не только для программистов "со стажем". Я уверен, что Хабр читают новички тоже, которым, возможно будет интересен этот подход или другие части кода. Я лично, в основном учился, разбирая примеры кода. :)
Я расписал несколько примеров - там, помойму, нечего уже добавить. Всё просто и универсально.
Я пишу эти статьи не только для программистов "со стажем". Я уверен, что Хабр читают новички тоже, которым, возможно будет интересен этот подход или другие части кода. Я лично, в основном учился, разбирая примеры кода. :)
Я наверно являюсь новичком, но не совсем понятно - а зачем передавать в открытом виде функцию, которую необходимо вызвать? Соответственно надо добавлять тогда механизм, который будет решать - а разрешено ли вызвать данную функцию неизвестно кем (ведь при передачи запроса в Вашем варианте php не знает кто именно вызывает функцию). Насколько я понял именно это имелось в виду под "не все вызовы разрешены". Может лучше просто через JSON передать набор "стандартных" параметров - модуль, экшн, параметры? И пусть уже модуль сам разбирается, что ему с полученным добром делать.
Не учите плохому. Не всегда простота это хорошо.
Такой подход порождает баги.
> Возможно есть несколько модулей (например фото-галлерея, видео-галлерея), которые друг с другом не связанны и в любой момент их можно просто отсоеденить/присоеденить (удалив/добавив include).
Именно это неправильно. Целостность системы потеряна. Модули бегают по двору, как маленькие котята, а программер сидит и пишет "новый" метод, который другой программер уже описал раньше.
При использованиии подобной схемы общение в команде должно быть чуть-ли не телепатическим. Для решения подобных проблем придумали апи. alexxz написал совершенно верно. Да и Kupyc прав.
Такой подход порождает баги.
> Возможно есть несколько модулей (например фото-галлерея, видео-галлерея), которые друг с другом не связанны и в любой момент их можно просто отсоеденить/присоеденить (удалив/добавив include).
Именно это неправильно. Целостность системы потеряна. Модули бегают по двору, как маленькие котята, а программер сидит и пишет "новый" метод, который другой программер уже описал раньше.
При использованиии подобной схемы общение в команде должно быть чуть-ли не телепатическим. Для решения подобных проблем придумали апи. alexxz написал совершенно верно. Да и Kupyc прав.
Не согласен. В простых вещах (а они по этому и называются простыми), найти баги намного проще.
Целосность потеряна, я знаю. Но мне она, для моих задач и не нужна. У нас не штат программистов, которые пишут, не зная, что уже есть и что будет реализованно, чем можно воспользоваться в будующем.
Да и для этого есть системы типа UML ;). У меня подход немного другой.
Целосность потеряна, я знаю. Но мне она, для моих задач и не нужна. У нас не штат программистов, которые пишут, не зная, что уже есть и что будет реализованно, чем можно воспользоваться в будующем.
Да и для этого есть системы типа UML ;). У меня подход немного другой.
есть очень грамотно написанная библиотека xajax, ее главная задача - она запускает функцию php с передачей параметров из javascript. Пользуюсь ею постоянно
и из php может пускать js. Тоже часто пользуюсь его использую.
Да, вот это, вот это неплохой кодобред.
Имхо идея не плохая, даже хорошая, но есть трудности которые нужно решить чтоб этот подход позволил накапливать опыт в библиотеках:
1. сложность наследования сервисов таких, разделение прав и прочего. не представляю как осуществлять наследуемость в таких структурах
2. как было сказано выше прохая инкапсулируемость.
$functions=json_decode($_REQUEST['method'],TRUE);
$UImethod->run($functions);
echo json_encode($UImethod->result);
мне кажется в этих строках сложно сделать прозрачным ограничение на разрешенные и запрешенные методы класса..
а в целом для маленьких задачь с маленьким кол-вом функций очень даже удобно. коротко и вызовы прозрачные впринципе
Может стоит просто сделать нечно вроде
1. сложность наследования сервисов таких, разделение прав и прочего. не представляю как осуществлять наследуемость в таких структурах
2. как было сказано выше прохая инкапсулируемость.
$functions=json_decode($_REQUEST['method'],TRUE);
$UImethod->run($functions);
echo json_encode($UImethod->result);
мне кажется в этих строках сложно сделать прозрачным ограничение на разрешенные и запрешенные методы класса..
а в целом для маленьких задачь с маленьким кол-вом функций очень даже удобно. коротко и вызовы прозрачные впринципе
Может стоит просто сделать нечно вроде
Я сейчас дописываю заключительную статью. Там всё объясняю подробно. Плюс добавил небольшие изменения для JS.
Запрещенные методы класса в данном случае не играют роли- они могут быть вынесены в другие классы-интерфейсы не относящиеся совсем к UI. При этом, public интерфейс для JS ты создаёшь сам при помощи метода add.
Запрещенные методы класса в данном случае не играют роли- они могут быть вынесены в другие классы-интерфейсы не относящиеся совсем к UI. При этом, public интерфейс для JS ты создаёшь сам при помощи метода add.
Написано много интересного, а можно простой пример,
как сделать, например, загрузку Javascript из php,
например. на страницу PHP вставить счетчик Javascript,
это например, есть и более сложные задачки…
как сделать, например, загрузку Javascript из php,
например. на страницу PHP вставить счетчик Javascript,
это например, есть и более сложные задачки…
Sign up to leave a comment.
Интерфейс Javascript < == > PHP