Я пользуюсь там eval, чтобы сгенерить функцию.
Как я уже говорил, штуки типа that[q]=function(a){...}(b) не пройдут, потому что в этой функции идёт работа с параметрами. Других выходов, как значение b (в примере method[index]) сделать там константным и разнообразным для различных q (в примере method[index]), я не представляю. Если у вас есть идеи - выслушаю.
Глобальная переменная? Вы возможно имеете ввиду global $UImethod?
Завтра с утра добавлю небольшой комментарий по этому поводу в текст, а пока, просто отвечу комментарием.
Функция __call в классе UserInterface из UI.php вызывает статические функции (подлинкованные с помощью add()). Да, красиво было-бы внутри их использовать не $UImethod, а $this - да и правильнее, но вот в PHP есть такая особенность функции call_user_func[_array], которая теряет $this даже при вызове статических методов из других объектов. Правильнее, если мы хотим, чтобы $this не потерялся, вызывать функцию eval("$class::$func(...)"); вместо call_user_func(array($class,$func)) но тут вам снова не понравится использования eval'a ;)
Так что приходится выбирать между eval и гибкостью. Для данного примера я выбрал call_user_func для большей ясности.
По поводу обработки JSON, сама матчасть говорит о том, чтобы использовать eval(req.responseText).
По поводу функции this.method[index]=eval('...') тут увы ничего не поделаешь. Так как принимаются параметры со стороны, то фокусы типа function(met){...}(method[index]) не пройдут.
А к чему вопрос. Вы беспокоитесь за безопастность вашего клиента? Боитесь, что не те данные с сервера прийдут? :)
Я сейчас дописываю заключительную статью. Там всё объясняю подробно. Плюс добавил небольшие изменения для JS.
Запрещенные методы класса в данном случае не играют роли- они могут быть вынесены в другие классы-интерфейсы не относящиеся совсем к UI. При этом, public интерфейс для JS ты создаёшь сам при помощи метода add.
Не согласен. В простых вещах (а они по этому и называются простыми), найти баги намного проще.
Целосность потеряна, я знаю. Но мне она, для моих задач и не нужна. У нас не штат программистов, которые пишут, не зная, что уже есть и что будет реализованно, чем можно воспользоваться в будующем.
Да и для этого есть системы типа UML ;). У меня подход немного другой.
Функции, которые можно вызывать разработчик задаёт сам с помощью $UImethod->add(...) в класс. Я достаточно подробно это описал. Вызов функций тоже возможен только через класс UserInterface.
Почему необходимо вызывать именно отдельные функции/методы скрипта?
Иначе теряется модульность. Возможно есть несколько модулей (например фото-галлерея, видео-галлерея), которые друг с другом не связанны и в любой момент их можно просто отсоеденить/присоеденить (удалив/добавив include).
Что вы имеете ввиду под "не все вызовы разрешены"?
Я расписал несколько примеров - там, помойму, нечего уже добавить. Всё просто и универсально.
Я пишу эти статьи не только для программистов "со стажем". Я уверен, что Хабр читают новички тоже, которым, возможно будет интересен этот подход или другие части кода. Я лично, в основном учился, разбирая примеры кода. :)
Плюсы - удобная разработка несколькими программистами одного кода.
Минус может быть лишь в том, что выполнение кода будет не оптимальным. Но это опять-же зависит от программиста - как он этим будет пользоваться и оптимизировать.
Как видишь, не смотря на это, очень многие не видят стёба. Возможно даже недочитывают.
А ещё смотрят на "друга" и решают мне понизить карму ;)
Удивительные хабралюди. Кстати комментарии тоже никто не читает.
Больше всего для меня остаётся под вопросом - какие причины в понижении кармы? Что их так разозлило? :)
Думаю, что совсем в минус не уйду.
Есть ещё интересные вещи в программировании, о которых скоро поведаю здесь. Так что я не переживаю совсем по этому поводу.
Удивительно, как рейтинг хабратопика от -2 до 2 скачет :)
Жду выхода на главную - там, думаю, будет ещё интереснее!
Как я уже говорил, штуки типа that[q]=function(a){...}(b) не пройдут, потому что в этой функции идёт работа с параметрами. Других выходов, как значение b (в примере method[index]) сделать там константным и разнообразным для различных q (в примере method[index]), я не представляю. Если у вас есть идеи - выслушаю.
eval стал теперь больше - зато теперь нормально работает.
Завтра с утра добавлю небольшой комментарий по этому поводу в текст, а пока, просто отвечу комментарием.
Функция __call в классе UserInterface из UI.php вызывает статические функции (подлинкованные с помощью add()). Да, красиво было-бы внутри их использовать не $UImethod, а $this - да и правильнее, но вот в PHP есть такая особенность функции call_user_func[_array], которая теряет $this даже при вызове статических методов из других объектов. Правильнее, если мы хотим, чтобы $this не потерялся, вызывать функцию eval("$class::$func(...)"); вместо call_user_func(array($class,$func)) но тут вам снова не понравится использования eval'a ;)
Так что приходится выбирать между eval и гибкостью. Для данного примера я выбрал call_user_func для большей ясности.
По поводу функции this.method[index]=eval('...') тут увы ничего не поделаешь. Так как принимаются параметры со стороны, то фокусы типа function(met){...}(method[index]) не пройдут.
А к чему вопрос. Вы беспокоитесь за безопастность вашего клиента? Боитесь, что не те данные с сервера прийдут? :)
Запрещенные методы класса в данном случае не играют роли- они могут быть вынесены в другие классы-интерфейсы не относящиеся совсем к UI. При этом, public интерфейс для JS ты создаёшь сам при помощи метода add.
Целосность потеряна, я знаю. Но мне она, для моих задач и не нужна. У нас не штат программистов, которые пишут, не зная, что уже есть и что будет реализованно, чем можно воспользоваться в будующем.
Да и для этого есть системы типа UML ;). У меня подход немного другой.
Мне кажется описанный мною метод - проще :)
Иначе теряется модульность. Возможно есть несколько модулей (например фото-галлерея, видео-галлерея), которые друг с другом не связанны и в любой момент их можно просто отсоеденить/присоеденить (удалив/добавив include).
Я расписал несколько примеров - там, помойму, нечего уже добавить. Всё просто и универсально.
Я пишу эти статьи не только для программистов "со стажем". Я уверен, что Хабр читают новички тоже, которым, возможно будет интересен этот подход или другие части кода. Я лично, в основном учился, разбирая примеры кода. :)
Минус может быть лишь в том, что выполнение кода будет не оптимальным. Но это опять-же зависит от программиста - как он этим будет пользоваться и оптимизировать.
Основное преимущество, что библиотеки могут не знать о присутствие других библиотек (если они им не нужны).
А ещё смотрят на "друга" и решают мне понизить карму ;)
Удивительные хабралюди. Кстати комментарии тоже никто не читает.
Больше всего для меня остаётся под вопросом - какие причины в понижении кармы? Что их так разозлило? :)
Есть ещё интересные вещи в программировании, о которых скоро поведаю здесь. Так что я не переживаю совсем по этому поводу.
Удивительно, как рейтинг хабратопика от -2 до 2 скачет :)
Жду выхода на главную - там, думаю, будет ещё интереснее!
Видимо второй вариант.....