Вот вам как это делает гугль: developers.google.com/webmasters/ajax-crawling/docs/getting-started
при желании можете поискать как это делают другие поисковики (но лично мне кажется, что примерно так же).
Что касается шаблонизатора — не имеет никакого значения какой он, поскольку HTML берётся с сервера уже готовый, в обход клиентской инфраструктуры.
Не вижу никаких проблем, гугль и другие поисковики уже умеют индексировать ajax-сайты, причём делают это достаточно хитро: по имеющейся «ajax-ссылке» (что-то вроде mysite.ru/#!/link/89) они формируют нормальную ссылку без хэша, по которой сервер отдаёт готовый HTML-слепок ajax-страницы.
Ваше заявление касается только случая, когда шаблоны обрабатываются в runtime, однако если шаблоны компилируемые (как в Smarty или как в Twig), то с большой вероятностью Вы не сможете вручную сделать исполняемый код быстрее, чем код скомпилированного шаблона. Я уже не говорю о кэшировании, которое в случае шаблонизатора добавляется буквально двумя строками кода и сводит на нет «преимущества» приведённого Вами лапшекода.
Понятно, что демонстрационный. Но разве не должен демонстрационный сайт показывать всю мощь фреймворка? Потому что имхо такой «демонстрационный сайт» можно написать без всякого фреймворка и даже оптимальнее…
Что-то новое всегда интересно, но вот наличие в классах страниц (VGS_GuestBook.java) низкоуровневых методов, считывающих побайтно какие-то файлы и раскладывающие их в переменные переносит меня мысленно во времена exe-файлов, работающих под CGI и написанных на Delphi.
Несмотря на то, что V8 скорее всего по-любому шустрее Zend, о быстродействии тут речи не идёт. Суть в концепции построения приложения. В конце концов, если быстродействие будет так важно, мы напишем всё на С++.
Лет 8 назад я писал однопоточный демон на PHP с помощью socket_select() (мне нужен был клиент для iChat с постоянным коннектом, реализующий несложную текстовую игру). Работало это достаточно шустро и надёжно, перегружал этого демона не чаще раза в неделю. Я и подумать не мог, что именно эта технология через несколько лет станет популярной и начнёт набирать обороты.
Кстати написать нечто подобное с нуля может любой средний программер на PHP, это может быть полезно, например, для того, чтобы «на берегу» разобрать все тонкости работы с таким демоном. Как Вы понимаете, в nodejs по сути реализовано то же самое, просто больше библиотек и пафоса.
Если кто-то пропустил, то можно прямо сейчас посмотреть асинхронный фреймворк на php, называющийся phpDaemon. Если запустить его в один воркер, то получится в точности однопоточный nodejs. Так что любители синтаксиса php могут опробовать асинхронность прямо сейчас, не переучиваясь на js.
Кстати говоря, phpDaemon также весьма шустр.
Кстати говоря (часть 2): асинхронный код на php очень сильно отличается от «обычного» php-кода. «Вроде функции те же, а чё написано не понятно».
Вот уже 5 лет я использую следующий простой принцип:
1. Тэг form ничего никуда отправляет, он служит скорее для группировки полей, но в принципе можно обойтись и без него. Очень часто я использую div — это не имеет большого значения.
2. По событию нажатия на submit (или какому-то другому — для сложных форм) js собирает данные из контролов и отправляет их на адрес обработчика с помощью ajax.
3. Обработчик на PHP (каждая форма считается объектом и у него есть просто метод onFormSubmit()) анализирует данные и через JSON возвращает последовательность простых команд по дальнейшей работе клиента. Это могут быть: подсветить поле(-я), вывести alert, сделать редирект, выполнить js-код или обновить кусок DOM. Редирект не делается только в том случае, если есть ошибки в форме и надо повторить отправку после их исправления.
Куда делать редирект — решает сам контроллер, и это, я считаю, правильно. Сам клиент ничего не валидирует и не принимает никаких решений (валидация на клиенте бессмысленна), а просто следует командам сервера.
В Вашей работе только одни плюсы, продолжайте работать «на дядю».
Единственный риск, который можно углядеть в Вашем ярком описании — это отсутствие гарантий, что завтра Вы всё так же будете работать на этой престижной работе. Я вовсе не хочу сглазить, просто это один из минусов работы «на дядю», который никак и ничем не скомпенсирован в вашем сообщении.
Плюс ко всему я полагаю, что Вы можете поехать только туда, куда Вас отправят, а вот самостоятельно поехать — вряд ли.
Как раз это и не проблема. Существует множество методик, чтобы определить. Самая простая: сесть, закрыв глаза и не двигаться, пока не найдётся мысль, которая сорвёт вас с места.
Можно, наконец, прочесть какую-нибудь специализированную книгу.
Да можно и проще определить: каким делом ты готов заниматься круглосуточно, не ради кого-то, а ради себя любимого? Это оно.
Уникальность контента доказывать не нужно — если он где-то ещё есть, значит он уже не уникальный. А у вас написано «если впоследствии окажется, что контент _не_уникальный_ и не авторский».
Сами понимаете, что впоследствии (обращаю Ваше внимание: время не ограничено), любой контент перестаёт быть уникальным, такова природа интернета.
Мне кажется, что в этой фразе просто должно быть уточнение «на момент передачи», без всяких неопределённых прилагательных. Т.е. тупо пробиваем по гуглю цитату — если нет повторов, то цитата принимается, деньги платятся и никаких возражений и споров по поводу уникальности быть впоследствии не должно. Ибо по приведённой Вами фразе из договора чисто формально через год сотрудничества у вас можно забрать все деньги, причём в двойном размере, т.к. через год все цитаты будут неуникальны.
при желании можете поискать как это делают другие поисковики (но лично мне кажется, что примерно так же).
Что касается шаблонизатора — не имеет никакого значения какой он, поскольку HTML берётся с сервера уже готовый, в обход клиентской инфраструктуры.
Кстати написать нечто подобное с нуля может любой средний программер на PHP, это может быть полезно, например, для того, чтобы «на берегу» разобрать все тонкости работы с таким демоном. Как Вы понимаете, в nodejs по сути реализовано то же самое, просто больше библиотек и пафоса.
Кстати говоря, phpDaemon также весьма шустр.
Кстати говоря (часть 2): асинхронный код на php очень сильно отличается от «обычного» php-кода. «Вроде функции те же, а чё написано не понятно».
1. Тэг form ничего никуда отправляет, он служит скорее для группировки полей, но в принципе можно обойтись и без него. Очень часто я использую div — это не имеет большого значения.
2. По событию нажатия на submit (или какому-то другому — для сложных форм) js собирает данные из контролов и отправляет их на адрес обработчика с помощью ajax.
3. Обработчик на PHP (каждая форма считается объектом и у него есть просто метод onFormSubmit()) анализирует данные и через JSON возвращает последовательность простых команд по дальнейшей работе клиента. Это могут быть: подсветить поле(-я), вывести alert, сделать редирект, выполнить js-код или обновить кусок DOM. Редирект не делается только в том случае, если есть ошибки в форме и надо повторить отправку после их исправления.
Куда делать редирект — решает сам контроллер, и это, я считаю, правильно. Сам клиент ничего не валидирует и не принимает никаких решений (валидация на клиенте бессмысленна), а просто следует командам сервера.
Единственный риск, который можно углядеть в Вашем ярком описании — это отсутствие гарантий, что завтра Вы всё так же будете работать на этой престижной работе. Я вовсе не хочу сглазить, просто это один из минусов работы «на дядю», который никак и ничем не скомпенсирован в вашем сообщении.
Плюс ко всему я полагаю, что Вы можете поехать только туда, куда Вас отправят, а вот самостоятельно поехать — вряд ли.
Можно, наконец, прочесть какую-нибудь специализированную книгу.
Да можно и проще определить: каким делом ты готов заниматься круглосуточно, не ради кого-то, а ради себя любимого? Это оно.
Сами понимаете, что впоследствии (обращаю Ваше внимание: время не ограничено), любой контент перестаёт быть уникальным, такова природа интернета.
Мне кажется, что в этой фразе просто должно быть уточнение «на момент передачи», без всяких неопределённых прилагательных. Т.е. тупо пробиваем по гуглю цитату — если нет повторов, то цитата принимается, деньги платятся и никаких возражений и споров по поводу уникальности быть впоследствии не должно. Ибо по приведённой Вами фразе из договора чисто формально через год сотрудничества у вас можно забрать все деньги, причём в двойном размере, т.к. через год все цитаты будут неуникальны.