Дело не в том, что Javascript хуже питона или руби. А в том, что в вышеперечисленных вами решениях надо писать код на Java, который потом уже транслируется в Javascript. То есть — если нет исходников на Java, то есть большие проблемы.
Насчет полусекунды — да, погорячился, но на статичных (то есть без JS в большом количестве) сайтах, коих большинство — инциализировать вообще нечего.
>Должен разочаровать, но крупные компании уделяют этому столько внимания, что тема неполной загрузки страницы весьма актуальна.
Я не разочаровываюсь… отнюдь. Я сам плотно занимаюсь данным вопросом, и то, что я к вам прицепился — означает лишь то, что мне эта тема небезралична, и посему от вашей серии статей ждал нечто большего :) Поэтому и пытаю в комментах, в надежде на уточнения и дополнения. ;)
>Договорились — в следующий раз обязательно проконсультируюсь у вас, как и про что мне писать! =))))
Согласен :)
CSS грузится один раз. А говорить о длительности инициализации JS-а (которого на сайте без AJAX-а может быть не так много), при том, что выставляется полусекундная задержка при каждом переходе со страницы на страницу — это как то странно.
По поводу универсальности: а универсального решения не надо. Потому как чем универсальнее решение, тем больше сил на его конфигурацию и настройку тратишь. Те же ThinWire, GWT и прочие с ними — это вообще нечто. Писать на Java Javascript — это только отличная возможность получить неподдерживаемый код, а не решение. А хотелось бы чего то достаточно простого и маленького, но в котором наиболее общие случаи работы со страницой шли бы из коробки, а экзотику надо было бы писать уже самостоятельно.
А у вас, к сожалению, вся изюминка обоих статей уложилась в использование анализа HTTP заголовков для определения, какой шаблон надо выдать. В итоге, если вы хотели донести эту идею до читателей, достаточно было бы просто взять и написать пример ее использования именно в Grails, JS часть попросту убрав в файлик и оставив в статье только ссылку на скачивание, либо вообще построив пример на какой нибудь уже известной библиотеке.
Вот как раз сохранять все события на странице то и нужно, хотя бы для того чтобы хистори и кнопка Back работала.
А если мыслить категориями одной страницы (одного блока) — то AJAX не нужен. CSS и JS отлично кешируется броузером, за-gzip-ленный контент на современных каналах прокачивается практически моментально. То есть все эти ухищрения с урлами, таймерами, аяксом и дополнительными обработчиками на стороне сервера только для WOW-эффекта не окупают себя никак. А если мы уходим от одноблочной структуры — то все, финиш, вся проработка сохранения статусов страницы опять ложится на плечи разработчика, и вместо разработки бизнес-логики он будет писать костыли для расширения вашего или другого такого же модуля.
То есть, такие модули должны работать как минимум с 2-мы блоками, чтобы их потом можно было по индукции расширять до любого n. В этом случае, да, профит будет очень высоким.
Что значит клики независимы? То есть если я кликнул в одном блоке — изменил его содержимое, кликнул в другом — тоже изменил, потом кинул ссылку другу, в надежде что он увидит первый блок в измененном состоянии — я обломаюсь? Или мне надо делать аналоги Jquery-евских addClass removeClass для hash-а, которые будут вставлять состояния всех блоков в URL?
Так это понятно, что блог «Groovy & Grails». Просто задача то решается на JS, Groovy в данном случае ничем не помогает. То есть если его заменить на PHP, Perl, Pyton etc, в вашем решении ничего не изменится. И что, теперь вашу статью можно с минимальными изменениями скопировать во все остальные блоги ?:)
События событиями… но речь немного не о том. У вас описан один блок на странице. Как будут сохраняться события и история переходов если блоков несколько?
Статья, если честно, ни о чем… ни одной животрепещущей проблемы в ней освещено не было. Только и того, что сервер приплетен сервер, непонятно зачем, с таким же успехом вместо него можно было использовать просто несколько HTML страничек, в содержательности статья не потеряла бы вообще ничего.
После строки: return document.location.toString().substr(0, document.location.toString().indexOf('#')) + anchor.substr(1); читать вообще расхотелось. Выше по тексту было 2 раза использовано свойство document.location.hash, но при этом был изобретен свой велосипед вместо остальных свойств.
Понятно, что человек осваивает JS+jQuery, но делать из этого цикл статей, вместо того, чтобы использовать уже существующие решения — это сурово. Лично я, рассчитывал увидеть более менее продакшен решение, потому как реально то насущность поставленных вопросов велика, и грамотную реализацию, учитывающую все нюансы — сложно.
Вот еще вопрос по статье: хорошо, а как я могу учесть изменение поведения остальных блоков на изменение одного? Изменение статуса ссылок — это хорошо, но если мне надо радикально поменять меню, в зависимости от того, какой блок был загружен? В блок писать простыни JS, которые бы модифицировали код остальной страницы?
Все равно, если честно, не понял :) Ведь если мы изначально в mark грузим список марок, но при этом не выбрана ни одна из них — то понятно, что во всех остальных селектах будет пусто. А если мы грузим какое то значение по умолчанию — то тут либо мы уже прямо на сервере в остальные селекты уже знаем что грузить и подставляем значения, либо чтобы все было проще — при загрузке формы выбираем значение по умолчанию JS-ом, тогда все остальные select-ы подгрузятся каскадно. Понятно, что в этом случае будут лишние AJAX запросы к серверу, но описание всего этого будет единообразно как для первого, так и для последующих показов формы.
А вообще, мне кажется, что надо решать задачу от сложного к простому, то есть взять и описать самый навороченный случай динамического взаимодействия полей формы от значений друг друга и попытаться максимально просто и удобно его описать. Лично я с трудом представляю, как можно описать задачу генерации формы, когда значения одного поля могут зависеть не от одного, а нескольких других полей, да еще и в обе стороны. К примеру, у нас есть форма выбора автомобиля и список салонов, в которых он есть в наличии. И при выборе Toyota Corolla 60 комплектации Green в списке должны остаться только те, в которых она есть. В этом случае список дилеров должен меняться и при выборе марки, и при выборе модели, и цвета и комплектации + список салонов в свою очередь связан со списком городов, и возможна обратная ситуация — выбирая город у нас должен меняться список салонов и в след за ним, список марок (при этом надо держать в голове, что если мы выбрали салон — то модели должны показываться только те, что есть в этом салоне, а не все).
Если вам удастся сделать такую вещь, и при этом не надо будет писать многокиллобайтной логики — то лично я с большим удовольствием бросил все свои велосипеды :)
Ну по сути, 99% полей должны иметь значение при первой загрузке типа «выберите [страну|район|город|и т.д.]». Потому как подставлять какие то значения по умолчанию нехорошо (если конечно, мы не определили город посетителя по IP и вероятность того, что ему придется в них что то перевыбирать — очень мала). А если мы о человеке ничего не знаем — то он должен выбрать сам. Иначе, если там что то уже будет выбрано — то мы не сможем отвалидировать, действительно ли человек что либо ввел, либо это наши умолчательные значения и регистрация в этом случае будет фейковой.
Так вроде ничего такого сложного нет. В принципе то, какие данные в какой селект подставлять определяет сам разработчик, поэтому вам для связи достаточно просто указать для связанных элементов шаблоны запросов к серверу. То есть, как я это вижу:
Допустим, есть родительский селект (parent) и подчиненный ему второй(child), и предположим, что данные для child-а сервер выдает по запросу www.site.com/get_child_values.php?parent_value=Toyota|VAZ|etc
Тогда связь можно описать в виде
{
'parent'=>'developer',
'child'=>'model',
'method'=>'ajax',
'url'=>' www.site.com/get_child_values.php?parent_value=#value#', // представляем URL в виде шаблона, где вместо #value# будет подставляться value parent-а
}
разобрать связь такого вида и описать в виде обработчиков на JS — плевое дело. Единственно, что при смене содержимого child-а надо на него генерировать событие onChange чтобы если на нем висят другие зависимые поля — они тоже вызвались, этакая каскадная загрузка зависимых данных получается.
Правда может быть вариант, когда зависимых полей большей одного, тогда по хорошему надо создавать массив связей.
В принципе, в каком то моем велосипедном генераторе форм это было сделано, но там генератор был скрещен с ORM-ом, поэтому избыточного кода с описанием было очень мало, роль связей играли FOREIGN KEY-s, а URL для получения данных был один, просто в паттерн URL-а подставлялись не только значение родителя, но и названия полей, и скрипт на сервере уже сам разбирался какие данные надо было выплюнуть.
Да, вещь неплохая. Но в данном случае мне доступна только клиентская валидация, серверную придется либо реализовывать самому, либо выпиливать напильником из того же jQuickForm. Интересней было бы все таки описывать правила валидации на сервере, чтобы если ушлый посетитель отключил JS, форма отвалидировалась и на сервере. Да и все эти зависимости переключения полей там же, чтобы потом JS либа просто прошлась по всем полям и навесила обработчики самостоятельно.
Это хорошо, когда разработчик и JS, и HTML, и PHP знает, а порой то пэхапе кодер норовит при виде HTML+JS в обморок упасть, то верстальщик и программист — 2 разных человека. То есть хочется: программер описал форму, дал верстальщику один файлик JS, который тот в прописал, и все. Верстальщик форму как хочет сам верстает, придерживаясь только выданных названий полей (ну или просит программера, тот вставляет один вызов генерации формы и та плюет готовый HTML).
Когда я вижу всякие такие чудесные генераторы форм, всегда интересует вопрос — а как они дружат с формами, когда выбор последующих данных зависит от выбора предыдущих? Тем более если они вовсю используют jQuery. У вас можно сделать, чтобы при выборе в select-e производителя автомобилей в следующий сразу же подгружались все марки этого производителя, а в — третий, допустим, все возможные цвета? И без уличной магии, желательно. И что мне делать, если есть уже сверстанная очень красивая и удобная форма в HTML, и мне надо просто прикрутить валидацию и фильтры?
Вы батенька, дурак… И это не лечится. Речь не о войне. А о патриотизме. А если у вас его нет — то и дети и внуки вам не положены. Ибо воспитаете их вы как и воспитали вас, в неуважении к своей истории.
Да причем здесь Тьюринг? Я на сто процентов уверен, что он отлично мог искать ответы на свои вопросы, не заваливая форумы вопросами, на которые были даны ответы не по одному разу. А вот с людьми, которые вместо того, чтобы забить вопрос в гугл, вбивают его в аську и отправляют его вам — лично мне приходится сталкиваться регулярно.
Не то слово… Их масса. Регулярно встречаюсь с молодежью, выращенной на переводах. И для них, то чего нет в рунете — нет вообще нигде. И на самом деле, в обычной повседневной работе это им никак не мешает. Потому что в основном на русском нет только достаточно инновационных вещей, а они в «клепании» сайтов практически не используются. Да о чем говорить, некоторые IT-шники, или точнее называющие себя такими, поисковыми системами то пользоваться не могут нормально. Это если говорить о:
>Уже все разжевано и пережевано в интернете 5 раз.
Так а кто вам мешает не подключать свой автомобиль к этой системе? Наверняка, получение ключа для идентификации вас к такому способу зарабатывания денег будет абсолютно добровольным и штатно в автомобиль его вам никто ставить не будет:
«В нем используются автомобили Toyota Scions, которые были переоборудованы в так называемые «eBoxes» с помощью соответствующего оборудования.»
То есть там надо доп. оборудование и некое количество рабочего времени. Так что не хотите — не получайте бабла, и радуйтесь мысли, что никто не знает, что ночью вы спите в своей кровати, а днем находитесь на своем рабочем месте.
А насчет чистой теории — все эти пропуска в бизнес-центры с rfid метками и проездные карты уже давно лишили вас какой либо приватности и свободы перемещений. Вопрос не в том, смогут ли узнать заинтересованные службы где вы находитесь — уже знают. Вопрос в том, хватит ли им ресурсов отследить все перемещения всех людей.
«что библиотечная наука лежит в основе всех наук, так же, как ключом ко всем наукам является математика, и что выживем мы или погибнем зависит от того, как хорошо справятся со своим делом библиотекари.» (с) Хайнлайн
Так что вопрос смогут ли спецслужбы обработать уже имеющуюся информацию, а не получить пару сотен террабайт новой.
Насчет полусекунды — да, погорячился, но на статичных (то есть без JS в большом количестве) сайтах, коих большинство — инциализировать вообще нечего.
>Должен разочаровать, но крупные компании уделяют этому столько внимания, что тема неполной загрузки страницы весьма актуальна.
Я не разочаровываюсь… отнюдь. Я сам плотно занимаюсь данным вопросом, и то, что я к вам прицепился — означает лишь то, что мне эта тема небезралична, и посему от вашей серии статей ждал нечто большего :) Поэтому и пытаю в комментах, в надежде на уточнения и дополнения. ;)
>Договорились — в следующий раз обязательно проконсультируюсь у вас, как и про что мне писать! =))))
Согласен :)
По поводу универсальности: а универсального решения не надо. Потому как чем универсальнее решение, тем больше сил на его конфигурацию и настройку тратишь. Те же ThinWire, GWT и прочие с ними — это вообще нечто. Писать на Java Javascript — это только отличная возможность получить неподдерживаемый код, а не решение. А хотелось бы чего то достаточно простого и маленького, но в котором наиболее общие случаи работы со страницой шли бы из коробки, а экзотику надо было бы писать уже самостоятельно.
А у вас, к сожалению, вся изюминка обоих статей уложилась в использование анализа HTTP заголовков для определения, какой шаблон надо выдать. В итоге, если вы хотели донести эту идею до читателей, достаточно было бы просто взять и написать пример ее использования именно в Grails, JS часть попросту убрав в файлик и оставив в статье только ссылку на скачивание, либо вообще построив пример на какой нибудь уже известной библиотеке.
А если мыслить категориями одной страницы (одного блока) — то AJAX не нужен. CSS и JS отлично кешируется броузером, за-gzip-ленный контент на современных каналах прокачивается практически моментально. То есть все эти ухищрения с урлами, таймерами, аяксом и дополнительными обработчиками на стороне сервера только для WOW-эффекта не окупают себя никак. А если мы уходим от одноблочной структуры — то все, финиш, вся проработка сохранения статусов страницы опять ложится на плечи разработчика, и вместо разработки бизнес-логики он будет писать костыли для расширения вашего или другого такого же модуля.
То есть, такие модули должны работать как минимум с 2-мы блоками, чтобы их потом можно было по индукции расширять до любого n. В этом случае, да, профит будет очень высоким.
События событиями… но речь немного не о том. У вас описан один блок на странице. Как будут сохраняться события и история переходов если блоков несколько?
После строки: return document.location.toString().substr(0, document.location.toString().indexOf('#')) + anchor.substr(1); читать вообще расхотелось. Выше по тексту было 2 раза использовано свойство document.location.hash, но при этом был изобретен свой велосипед вместо остальных свойств.
Понятно, что человек осваивает JS+jQuery, но делать из этого цикл статей, вместо того, чтобы использовать уже существующие решения — это сурово. Лично я, рассчитывал увидеть более менее продакшен решение, потому как реально то насущность поставленных вопросов велика, и грамотную реализацию, учитывающую все нюансы — сложно.
Вот еще вопрос по статье: хорошо, а как я могу учесть изменение поведения остальных блоков на изменение одного? Изменение статуса ссылок — это хорошо, но если мне надо радикально поменять меню, в зависимости от того, какой блок был загружен? В блок писать простыни JS, которые бы модифицировали код остальной страницы?
А вообще, мне кажется, что надо решать задачу от сложного к простому, то есть взять и описать самый навороченный случай динамического взаимодействия полей формы от значений друг друга и попытаться максимально просто и удобно его описать. Лично я с трудом представляю, как можно описать задачу генерации формы, когда значения одного поля могут зависеть не от одного, а нескольких других полей, да еще и в обе стороны. К примеру, у нас есть форма выбора автомобиля и список салонов, в которых он есть в наличии. И при выборе Toyota Corolla 60 комплектации Green в списке должны остаться только те, в которых она есть. В этом случае список дилеров должен меняться и при выборе марки, и при выборе модели, и цвета и комплектации + список салонов в свою очередь связан со списком городов, и возможна обратная ситуация — выбирая город у нас должен меняться список салонов и в след за ним, список марок (при этом надо держать в голове, что если мы выбрали салон — то модели должны показываться только те, что есть в этом салоне, а не все).
Если вам удастся сделать такую вещь, и при этом не надо будет писать многокиллобайтной логики — то лично я с большим удовольствием бросил все свои велосипеды :)
Допустим, есть родительский селект (parent) и подчиненный ему второй(child), и предположим, что данные для child-а сервер выдает по запросу www.site.com/get_child_values.php?parent_value=Toyota|VAZ|etc
Тогда связь можно описать в виде
{
'parent'=>'developer',
'child'=>'model',
'method'=>'ajax',
'url'=>' www.site.com/get_child_values.php?parent_value=#value#', // представляем URL в виде шаблона, где вместо #value# будет подставляться value parent-а
}
разобрать связь такого вида и описать в виде обработчиков на JS — плевое дело. Единственно, что при смене содержимого child-а надо на него генерировать событие onChange чтобы если на нем висят другие зависимые поля — они тоже вызвались, этакая каскадная загрузка зависимых данных получается.
Правда может быть вариант, когда зависимых полей большей одного, тогда по хорошему надо создавать массив связей.
В принципе, в каком то моем велосипедном генераторе форм это было сделано, но там генератор был скрещен с ORM-ом, поэтому избыточного кода с описанием было очень мало, роль связей играли FOREIGN KEY-s, а URL для получения данных был один, просто в паттерн URL-а подставлялись не только значение родителя, но и названия полей, и скрипт на сервере уже сам разбирался какие данные надо было выплюнуть.
Это хорошо, когда разработчик и JS, и HTML, и PHP знает, а порой то пэхапе кодер норовит при виде HTML+JS в обморок упасть, то верстальщик и программист — 2 разных человека. То есть хочется: программер описал форму, дал верстальщику один файлик JS, который тот в прописал, и все. Верстальщик форму как хочет сам верстает, придерживаясь только выданных названий полей (ну или просит программера, тот вставляет один вызов генерации формы и та плюет готовый HTML).
Это каких же? Вижу только 2 новых виджета + 3 корных фичи вынесли в плагины. То есть ощутим мы только автокомплит и кнопки.
>Уже все разжевано и пережевано в интернете 5 раз.
«В нем используются автомобили Toyota Scions, которые были переоборудованы в так называемые «eBoxes» с помощью соответствующего оборудования.»
То есть там надо доп. оборудование и некое количество рабочего времени. Так что не хотите — не получайте бабла, и радуйтесь мысли, что никто не знает, что ночью вы спите в своей кровати, а днем находитесь на своем рабочем месте.
А насчет чистой теории — все эти пропуска в бизнес-центры с rfid метками и проездные карты уже давно лишили вас какой либо приватности и свободы перемещений. Вопрос не в том, смогут ли узнать заинтересованные службы где вы находитесь — уже знают. Вопрос в том, хватит ли им ресурсов отследить все перемещения всех людей.
«что библиотечная наука лежит в основе всех наук, так же, как ключом ко всем наукам является математика, и что выживем мы или погибнем зависит от того, как хорошо справятся со своим делом библиотекари.» (с) Хайнлайн
Так что вопрос смогут ли спецслужбы обработать уже имеющуюся информацию, а не получить пару сотен террабайт новой.