В статье "Using JavaScript in PHP with PECL and SpiderMonkey (http://devzone.zend.com/article/4704-Using-JavaScript-in-PHP...)" рассказано о возможности выполнения JavaScript кода внутри PHP скриптов на сервере, через подключение PHP расширения (http://pecl.php.net/spidermonkey) с реализацией JavaScript движка Mozilla SpiderMonkey. На Perl подобная функциональность достигается использованием модуля JavaScript::SpiderMonkey (http://search.cpan.org/~tbusch/JavaScript-SpiderMonkey-0.19/).URL: http://devzone.zend.com/article/4704-Using-JavaScript-in-PHP...
Новость: http://www.opennet.me/opennews/art.shtml?num=22101
какой в этом смысл?
>какой в этом смысл?унификация кода. допустим купили вы разработчика java script и благодаря этой возможности можете его использовать и для написания кода на сервере.
или например общая и для сервера и для клиента библиотека - меньше кода проще поддержка
>допустим купили вы разработчика java scriptвы сами понимаете, что это звучит как "директор по швабре"
>или например общая и для сервера и для клиента библиотека - меньше кода проще поддержка
меньше эффективность
> меньше эффективностьсмешно, мне как минимум не придётся платить каждый месяц зарплату лишнему ПХП кодеру :)
>смешно, мне как минимум не придётся платить каждый месяц зарплату лишнему ПХП
>кодеру :)Ага, вы б еще название конторы озвучили?Чтоб знать от кого стоит держаться подальше.
А то мало ли, вдруг вы там дворника ненароком купили и вам влом платить лишнему php-кодеру.
ЗЫ пример из области "и жнец и швец и на дуде игрец" :D
>смешно, мне как минимум не придётся платить каждый месяц зарплату лишнему ПХП
>кодеру :)Т.е. для вас это единственное мерило всего? Класс.
+1 к реквесту названия конторы.
а смысл по-моему очень простой
с появление JS разработчики разгрузили свои сервера за счёт клиентов
потом понаписали новых браузеров, разных JS библиотект и теперь у пехапешников возникла мысль, а почему разгрузить клиенские машины за счёт серверов
следующим маразматическим шагом будет вынесение серверов на сторону клиентов или перезд клиентов на сервера
>переезд клиентов на сервераЭто вряд ли
>вынесение серверов на сторону клиентовНу если нагрузка а локальный сервер будет небольшой, то почему бы и нет. Например, расширение google gears предоставляет возможность доступа к локальной БД SQLite - чем Вам не сервер БД?
Что же касается серверного javascipt, то можно использовать Jaxer:
http://www.aptana.com/jaxer
Насколько мне известно, там все пишется на javascipt, при этом разработчик может выбирать, где исполнять код - на сервере или клиенте.
>Что же касается серверного javascript, то можно использовать Jaxerно это полноценный standalone серверный жабоскрипт, а по сабжу встраивание одного интерпретатора в другой.
жабоскрипт же обычно используется в контексте клиентского документа. там он рулит деревом, парсит строки, верифицирует пользовательский ввод, добавляет декорации, эмулирует кросбраузерность. на сервере что делать?
>верифицирует пользовательский вводПроверять ввод пользователя можно на сервере, а не на клиенте.
>Проверять ввод пользователя можно на сервере, а не на клиенте.траффик, латентность, нагрузка
и вообще глупо
Вот приблизительно так и получаются различные виды sql-injection
>Вот приблизительно так и получаются различные виды sql-injectionерунда. клиентская верификация означает проверить синтаксическую валидность мыла, подсветить незаполненные поля, подсказать возможный логин. глупо и неэффективно такую ерунду гонять по сети. серверные проверки никто не отменял
>SQLite - чем Вам не сервер БД?Если sqlite - сервер БД, тогда glibc - стопудово "сервер приложений", как минимум 8[ ]
> следующим маразматическим шагом будет вынесение серверов на сторону клиентов или перезд клиентов на сервераТочно :) Чем бы дитё не тешилось...
>следующим маразматическим шагом будет вынесение серверов на сторону клиентов
>или перезд клиентов на сервера...но именно так и появились распределенные P2P сети без серверов.Где есть только клиенты.И ничего кроме клиентов.
Что только не сделают, лишь бы не изучать более глубоко тот же PHP?
О С/С++ я вообще молчу)Ещё можно поддержку VisualBasic и ActiveX сделать.
А чо, есть же такие скрипты у клиента в браузере)А вообще есть такая штука, как серверная Java.
Есть давно.
Очень любима в корпоративном секторе.
Может вместо JavaScript начать изучать её?
>Ещё можно поддержку VisualBasic и ActiveX сделать.Лучше брейнфак сразу, все-равно к чему-то этакому стремление у всех програмеров есть :)
Всё смешали в одну кучу.На C/C++ едва ли в настоящее время кто-то разрабатывает сайты. Кроме разве что спецзадач.
VisualBasic - это проприетарная МС технология, которая нигде кроме продуктов МС не используется.
АктивХ - это не язык программирования, а ЯП-независимый АПИ доступа к неким ресурсам МС.
"Серверная" Ява - это не альтернатива Яваскрипту, а опять же технология, призванная решать вполне конкретный, довольно узкий круг задач. Никто в здравом уме не будет писать например сайт-визитку на J2EE/EJB.
И к тому же, яваскрипт - это скриптовый ЯП, используемый в основном в разработке веб-сайтов и работающий во всех основных браузерах. всё остальное, включая пхп - таковым не является.
ПХП как ЯП - убог и отвратен. Да, полезные фишки типа расширений, которые правда далеко не на всех хостингах установлены, снискали ему популярность. Но его идиотская система разработки (АПИ в каждой версии отличается от предыдущей), отсутствие стандарта, отсутствие поддержки юникода, бредовые концепции глобальных переменных, издыхающие зачатки ООП, дебильный механизм warnings и notices вместо нормальной системы обработки ошибок, и прочие следствия того, что это "Personal Home Pages" - всё это убивает все плюсы напрочь.
Яваскрипт - это чётко стандартизированный ЯП, со вменяемым АПИ, с удачной (для скриптового языка) структурой типов и объектов, широко используемый. И я лично всеми руками за то, чтобы сделать его универсальным языком для Веб. А пхп пусть канет в лету, куда ему дорога.
>На C/C++ едва ли в настоящее время кто-то разрабатывает сайты.в то же время
>ПХП как ЯП - убог и отвратен.
>его идиотская система разработки (АПИ в каждой версии отличается от предыдущей)какое нафиг отличающееся апи? никому не важны проблемы с бинарными интерфейсами, это задача хостера обеспечит работоспособность.
>отсутствие стандарта, отсутствие поддержки юникода, бредовые концепции глобальных переменных
>прочие следствия того, что это "Personal Home Pages"дяденька наверное последний раз видел php лет пять назад. дальнейшее обсуждение не имеет смысла
>На C/C++ едва ли в настоящее время кто-то разрабатывает сайты. Кроме разве
>что спецзадач.Различные сервисы и службы на крупных порталов - сплош и рядом.
>Но его идиотская система разработки (АПИ в каждой версии отличается от
>предыдущей),Поясните мысль. Вы про Zend Engine API? И когда он последний раз менялся?
>отсутствие стандарта,
Это про что?
>отсутствие поддержки юникода,Ой http://ru.php.net/manual/en/ref.unicode.php
>бредовые концепции глобальных переменных,
Ой http://ru.php.net/manual/en/security.globals.php
>издыхающие
>зачатки ООП,http://ru.php.net/manual/en/language.oop5.php
Опять в лужу, да что за нафиг!>дебильный механизм warnings и notices
Механизм предупреждений и механизм обработки ошибок вещи разные и существуют для разных целей. Кстати
>вместо нормальной системы обработки
>ошибок,
>Яваскрипт - это чётко стандартизированный ЯП, со вменяемым АПИ, с удачной (для
>скриптового языка) структурой типов и объектов, широко используемый. И я лично
>всеми руками за то, чтобы сделать его универсальным языком для Веб.О да, стандартизированный. Там в самом стандарте в каждой строчке исключения, а если учитывать еще и микрософтовскую реализацию...
Да и сам язык убог до невозможности - после определения `слабо типизированный' его можно сразу похоронить. Вспомните правила преобразования типов, неявное объявление переменных, объекты обертки. Это нельзя языком назвать, тут даже PHP на порядки лучше. Хотя я за то, чтобы их скрестить и похоронить вместе, да.
>>Яваскрипт - это чётко стандартизированный ЯП, со вменяемым АПИ, с удачной (для
>>скриптового языка) структурой типов и объектов, широко используемый. И я лично
>>всеми руками за то, чтобы сделать его универсальным языком для Веб.
> О да, стандартизированный. Там в самом стандарте в каждой строчке исключения, а
> если учитывать еще и микрософтовскую реализацию...
> Да и сам язык убог до невозможности - после определения `слабо типизированный'
> его можно сразу похоронить. Вспомните правила преобразования типов, неявное объявление
> переменных, объекты обертки. Это нельзя языком назвать, тут даже PHP на
> порядки лучше. Хотя я за то, чтобы их скрестить и похоронить
> вместе, да.Ну если вы утверждаете что javascript реализовал микрософт то разговор сразу же можно прекращать. javascript разработан компанией netscape и Sun Microsystems. И только потом микрософт выпустил свой аналог jscript который поддерживается наверное только в ie
Если лично вам не нравится php, то это дело личное.
Но и тут сообществу есть, что вам предложить.
Perl/Python/Ruby и т.д. выбирайте тот язык, который вам нравится.>И к тому же, яваскрипт - это скриптовый ЯП, используемый в основном
>в разработке веб-сайтов и работающий во всех основных браузерах. всё остальное,
>включая пхп - таковым не является.Это не верно.
Все-таки стоит разделить то, что выполняется на сервере и то, что выполняется в браузере.
JavaScript не используется в разработке сайта.
Он используется для увеличения интерактивности уже сгенерированной и отданной юзеру странички.
И то - выполняясь на его стороне.
Если я открою сайт в lynx/links/telnet, JavaScript не запустится, ни на сервере, ни у меня.Ну а то, что в браузерах сейчас JavaScript - единственное, что есть у всех - это да.
Но он немного тормозноватый.
Если JavaScript тормозит на современной машине, это странно.
Google отчасти потому и выпустила Chrome - озаботилась скоростью JavaScript.
И сделала движения в ту сторону, чтобы народ продолжал пользоваться JavaScript и поменьше хотел изобретать велосипеды.Поэтому не вижу причин внедрять JavaScript на сервере, когда можно использовать Java.
Но если вы мне расскажите, буду рад.
По поводу применения:
Первое, что приходит на ум: возможность создания упрощённого скриптового языка внутри сложного пхп-фреймфорка - например для того, чтобы юзер мог какую-то бизнес-логику сам задавать. Ну или для того чтобы к системе контроллерров был доступ извне - из скрипта шелловского какого-нибудь и т.д.И главное отличие от пхп здесь в возможности создания изолированного окружения пользовательского кода - у яваскрипта не будут доступны потенциально опасные пхпшные функции, не будет доступа к глобальным переменным и т.д.
>пхп-фреймфорка - например для того, чтобы юзер мог какую-то бизнес-логику сам
>задавать.Да, точно, сделайте по такому принципу платежную систему :).Я чесслово логику задам.В свою пользу правда, но это уже детали :)
>По поводу применения:
>Первое, что приходит на ум: возможность создания упрощённого скриптового языка внутри сложного
>пхп-фреймфорка - например для того, чтобы юзер мог какую-то бизнес-логику сам
>задавать. Ну или для того чтобы к системе контроллерров был доступ
>извне - из скрипта шелловского какого-нибудь и т.д.
>
>И главное отличие от пхп здесь в возможности создания изолированного окружения пользовательского
>кода - у яваскрипта не будут доступны потенциально опасные пхпшные функции,
>не будет доступа к глобальным переменным и т.д.Ну так, в Java тоже можно сделать изолированное окружение.
И возможностей у него больше.
И программистов под него больше.
И его реалзации уже есть везде, где только можно.
Любопытно, никто не подумал про самое очевидное применение: исполнять внешний javascript код. Зачастую разбор внешнего js кода и написание его аналога на внутреннем языке слишком трудоемкая задача. Другое дело, что грабберы(а именно в им такое нужно) все-таки лучше писать на perl, а не на пыхе, но если так рассуждать, то пых вообще окажется ненужным :)
>Любопытно, никто не подумал про самое очевидное применение: исполнять внешний javascript код.подумали. но не написали, потому что подумали и про другое: почти всегда js жестко привязан к конкретному документу, разбор и исполнение вне контекста не имеет смысла. вот если бы рулить всем движком, а не только огрызком...
>Любопытно, никто не подумал про самое очевидное применение: исполнять внешний javascript код.
>Зачастую разбор внешнего js кода и написание его аналога на внутреннем
>языке слишком трудоемкая задача. Другое дело, что грабберы(а именно в им
>такое нужно) все-таки лучше писать на perl, а не на пыхе,
>но если так рассуждать, то пых вообще окажется ненужным :)Так может тогда выполнять Java код?
Они распространеннее, и может выполняться в своей виртуальной машине.
С каких пор на сайтах java более распространена чем js? Если вдруг не поняли про что я, то поясню. Скрипт на php/perl/python/итд должен получить некие данные с вебсайта, который не контролируем. Если это на прямую доступная простая страничка на html, пусть даже сгенерированная динамически жабой/пыхом/итд, то это все в легкую решается регексами. Однако если сайт имеет сложную структуру и активно юзает js, то может уйти много дней, чтобы найти способ добраться до нужной странички и вытащить инфу. Возможность исполнения js убирает значительную часть времени, затрачиваемого на его разборку. Иногда это может экономить больше 90% тотального времени на задачу.
> Скрипт на php/perl/python/итд должен
>получить некие данные с вебсайта, который не контролируем.На вас в суд еще никто не подавал за нарушение авторских прав?
Что-то мне подсказывает, что в первую очередь это расширение предназначено для выполнения сторонних ЖС и скрытого использования их функционала.
Так же подобная вещь может пригодиться для автоматизированного профилирования множества разрозненных клиентских скриптов.