Все ясно 


Оффтоптик вполне могла бы поступить точно так же 


ИМХО, лишь покуда не наберется критической массы, после чего можно прикрыть лавочку и народу, вынужденному продолжать работу со знакомыми технологиями, придется раскошеливаться.


Есть, и множество. Я над этим думаю.


Да, это будет непросто. Однако ИМХО оно того стоит, "песочница" как способ защиты очень хороша.


Тогда эту тему можно смело закрывать, ибо она рассматривает все в комплексе.

Не глядел, поинтересуюсь, спасибо.

Необходимо отдать клиенту такую пачку: текст (будем считать его исключительно семантической величиной), скин (пачку ксс + картинки), логику (я о клиентских скриптах).
Я настаиваю, что эти три компонента невозможно заменить чем-то одним.
Можно сделать более логичным каждый из них, но троица контент-скин-логика - фундаментальная суть веба.
Потому что наряду с он-лайн векторными редакторами существуют банальные электронные книги в виде пачки связанных страниц да и просто тупо данные без скина и логики.
А значит, из "пачки" должна быть возможность исключить "скин" и "логику". Ну или если очень хочется, сделать их нулевой длины.
Ну а что на сервере - по традиции неважно. И это не проблема конкретно веба, а данность клиент-серверной архитектуры. Если очень хочется, то с серверной стороны можно на сервер-сайд ява-скрипте писать - вот и весь интернационализм.

См. далее.

Неа.
Здесь совсем другой конфликт.
Технология вошла в автоколебания.
Сначала был многоцелевой HTML, который про семантику не думал, просто позволял мал-мал совместить текст с картинками и ссылками. Дальше он усложнялся с целью расцветить страничку.
Потом стало понятно, что этого недостаточно. Добавляется скрипт.
Тут хтмл если не сбрасывает жирок, то удерживается от того, чтобы зарасти "динамическими тегами" навроде marquee.
Дальше стало заметно, что масса задач дублируются.
Тут HTML сбрасывает жирок, но рождается ксс. Яваскрипт хоть и не сбрасывает жирок, но строки омаусовер="имг.срц=картинка.он.гиф" превращаются в ксс.
Сайты становятся все изощреннее, и часть фунционала, которую нес скрипт, берет на себя ксс (я о псевдоклассах и динамическом контенте, который до сих пор толком не фурычит).
Дальше тенденция продолжается точно таким же образом:

часть задач, став "типовыми", оформляются в виде декларативов (будь то ксс или новые тэги в хтмл - не суть)
А скрипт продолжает оставаться неизменным "кукловодом", просто за счет более развитых средств и фреймворков (типа jquery) становится более понятным.

Я многословен, грешен, постараюсь вычленить суть:
с нарастанием сложности сайтов ряд задач начинают повторяться настолько широко, что вместо функционального программирования имеют тенденцию превращаться в декларативную разметку (хтмл-8, ксс-15 и т.п.)
Скрипт остается неизменным в том смысле, что он вечен   
А это уже - автоколебания.
Потому как не только в вебе, но и в самых что ни на есть настольных продуктах происходят подобные вещи. Начинается все прозаично, с ini-файла. Затем прирастает xml, вложенность которого стремительно растет. Затем продукт становится свободно конфигурируемым, появляется графический конфигуратор. Затем продукт благополучно дохнет от монструозности, порождая (или материально или идейно) более навороченные (с т.зр. базовых абстракций) но более узкие продукты. Затем цикл повторяется.

Особенность веба здесь в том, что кусок продукта (под продуктом будем понимать сайт) по ряду причин не изменен и не зависит от разработчика сайта. Я говорю о браузере.
В процессе автоколебаний всяко возникали интересные и эффективные идеи. Однако первичен здесь - браузер.
А потому свободноконфигурируемым предстоит стать именно ему   

С т.зр. технологий в вебе, на мой взгляд, важно присобачить совсем другой механизм: сделать раздельную обработку шаблона и обработку контента. Причем шаблон должен становиться как бы "частью браузера".
Примерно как-то так:
браузер заходит на корневую папочку и понимает, что ему нужно загрузить шаблон (что-то вроде xml-stylesheet). Шаблон загружается, кэшируется. Причем это не только набор правил отображения (типа пачки картинок и стилей), но и набор правил обработки (да хоть к примеру что все страницы меняются через директ-икс фильтры). В т.ч., например, для ссылок в такую-то область необходимо включить такую-то анимацию и лишь затем загружать нужный контент.
Сама страничка, упоминавшая такой шаблон, содержит в основном контент.
Шаблон в паре с браузером разбирает этот контент и отображает его как ему нравится.
Очень похоже на клиент-сайд обработку xml, с возможностью подгрузки браузером внешнего xsl. Технология отличная и очень интересная. Недоработанная только тем, что какое-то время поддерживалась не всеми браузерами, а во-вторых, не очень продуманная с т.зр. мультимедийных ресурсов и "перманентных" скриптов.

Я пока все это писал, мне в голову пришла одна мысль...
Наверное, все дело совсем в другом.
В том, что в вебе первичен ДОКУМЕНТ (сиречь разметка) который собирает в кучу всю остальную мультимедию, а скрипт - разновидность мультимедии.
А на сегодня ситуация совсем иная - первичен КОНТЕЙНЕР контента - сайт. В некотором смысле самый простой сайт - это программа по предоставлению статических страниц и изображений. Более навороченный сайт - это более навороченное приложение по отображению динамичного текста и всякой мультимедии. САЙТ (как некий контейнер) объединяет все это разнообразие в законченное творение - САЙТ.
Иными словами, первично ПРИЛОЖЕНИЕ (сиречь скрипт). Можа, копать отсюда?!
Что-то вроде такого сценария:
1. Загружается индексный СКРИПТ (можно считать, что если такового на сайте нету, то подразумеваемый скрипт как будто бы есть, но выполняет единственную операцию - загрузку документа  с урлом "/index.content")
2. Индексный скрипт выполняет загрузку ресурсов (кэшируемых - к примеру, шаблон и не кэшируемых - у примеру, контент)
3. Модифицирует/организует/обрабатывает данные - и отображает их.
Будет считать, что отдельные ресурсы изначально являются "скриптовыми объектами" и способны на самостоятельные действия.

По-моему, большинство современных веб-страниц пытаются сделать именно это, но в силу ДОКУМЕНТО-центричности приходится подставлять костыли, от которых мы так жаждем избавиться.

А там всё хитро. Исходники дотнета доступны, но под не оупенсорсной лицензией. Использовать их в своих проектах нельзя.


Т. е. вместо современной клиент серверной (возможно даж сервис ориентированной) архитектуры ты предлагаешь откатиться лет на 15 назад?

Тогда, быть может, стоит пересмотреть Web как таковой? Взять, к примеру, идеи ОС Plan 9, где нет никакой разницы между удаленными и локальными ресурсами. Тогда и браузера никакого не надо, достаточно одного лишь поиска.


Все как обычно - открыть открыли, а толку никакого 


Я подразумевал, что нельзя рассматривать одну лишь сторону браузера, нужно представлять и что творится на сервере.

Может быть, не знаю.
Я говорил о другом.
Сейчас как: главный - документ. В нем туча всякой разметки для подгрузки ресурсов, для включения скриптов/ксс/картинок/объектов.
Причем "включение" происходит лишь иннициирующе, что-то на уровне body onload="init()", а затем уже скрипт разбирается, чего куда загружать, какие аякс-запросы делать и т.п.
Аналогично пытается делать и ксс с его встроенными возможностями подгружать внешние файлы ксс. И много раз прихходилось слышать, что ксс-у не хватает встроенных возможностей условной подгрузки.

А я предлагаю сделать так: главный - скрипт. Если скрипту потребуется - он загрузит ресурс "статичный/динамичный документ".
А если не потребуется - то никакого документа не будет загружено. К примеру, скрипт будет сам генерировать контент. Что весьма типично для современных веб-страниц.

Единственное что, для удобства можно предусмотреть привычное поведение ресурсов и добавить несколько встроенных функций в сам движок скрипта. Чтобы несложно было ваять статичные, простые сайты.
К примеру, "браузер" (пусть будет "Бр", чтобы не путать с традиционным браузером) заходит на урл хттп://хост/
Сервер отдает пустой 200 ОК.
Бр понимает, что индексного скрипта на сервере нет. И загружает индексный скрипт, комплектный к дистрибутиву Бр (о, кстати, какой волшебный механизм для расширения браузеров! Не то что нынешняя каша в xpi...).
Индексный скрипт по умолчанию делает только одно - загружает контентный файл (ресурс), к примеру, хттп://хост/index.content (тоже всего лишь ресурс) и умолчальный скин, к примеру хттп://хост/index.mega-css
Ессно, что если на сервере отсутствует скин, то подставится дистрибутивно-комплектный.
Итого для минимальной странички по-прежнему нужно написать только один файл index.content (пусть будет в каком-нибудь виде xml, пускай, например, из подмножества xhtml). "Минимальный", "чистый" веб практически не изменится

Но все меняется, если мы добавляем индексные скрипты:

Сервер глядит в урл хттп://хост/ и находит там индексный скрипт.
Загружает его, подгружает необходимые внешние скрипты (да-да, предлагаю возможность включения (вроде include) сделать базовой способностью Бр.
И потом запускает этот скрипт на выполнение.
Теперь потоком загрузки, выполнения и отображения ведает индексный скрипт.
К примеру, прежде чем отображать контент, скрипт пытается загрузить ресурс "скин". Или, к примеру, сначала предлагает выбрать, какой скин, а затем загружает.
Затем загружает контентный файл и "вручную" или каким-нибудь заранее заданным способом (типа xbi в XUL) привязывает контент к скину.

Можно пофантазировать дальше, на тему, что любой ресурс может грузиться по подобной схеме (скрипто-центричной) и т.д.
Зачем это и что это дает?
1. ХТМЛ перестанет быть фаршем из скриптов, ксс, разметки и т.п. Его по-настоящему можно будет делать чисто семантическим. Потому что "скин" - это не просто ксс, который с огромным трудом манипулирует потоком документа, а развитый скрипт
2. Многие возможности становятся умолчальными
3. Самое главное - не приходится городить огороды для самых типичных в современном вебе задач. Ведь давайте на чистоту, нам очень трудно представить СОВРЕМЕННУЮ страницу обычного сайта (не говоря о современном веб-приложении) БЕЗ СКРИПТОВ. Ведь всеми правдами и неправдами все крутится вокруг скриптов. ХТМЛ при этом пытается носить характер, с одной стороны, контейнера ресурсов, а с другой стороны - семнтического наполнения. И именно благодаря такой двойственности происходит то, что происходит - получается целый фарш технологий.

в этом смысле полезно вспомнить, что ксс какое-то время имел синтаксис ява-скрипта. Еще припомним, что с развитием веба появился формат JSON. Ну так и давайте узаконим их, наконец. Сразу несколько левых синтаксисов исчезнет.
Кроме того, можно немного подработать встроенный функционал и синтаксис ява-скрипта, чтобы типичные операции синтаксически выглядели ДЕКЛАРАТИВНО.

Как вам? Или я не смог донести?

Иллюстрация однако.

Зачем? Разделение ролей же! Если ты вызываешь АПИ сторонней библиотеки/сервиса - тебе обязательно знать, что оно делает внутри и ты когда пишешь свой код завязываешься на это?!


Клик очевидно на клиенте происходит. И этот код (клиентский) устанавливает соединение с БД и пр.?

rsm

Чей - то я дурак, чей - то я не понимаю, вот это из выше приведенного, именно так у меня на сайте и работает, пользователь вводит данные, отправляет их на сервер, проверка данных происходит через вызов хранимой процедуры из БД, одновременно проходит там же на сервере проверка на валидность, если все совпало возвращаеться положительный результат, если нет, то ошибка. Это приведен частный случай для примера. Вот и вопрос, а что новое тут?

Концепция определенно годная! Однако никуда не пропадают два вопроса: индексация (как поисковые роботы будут обрабатывать контент) и адресация (как создавать закладки).


Малость не допер - сайт как сайт, в чем фишка? 


Обязательно - иначе как оценивать скорость, эффективность, узкие места и пр.?


Да, именно так. Выполняется внутри браузера и работает сам по себе.


То, что не нужно перезагружать страницу и что соединение устанавливается только с БД, без участия сервера.

Ок. Тогда ещё раз мои прошлые вопросы:

• Безопасность. Как с точки зрения разделения ролей, так и с точки зрения тяжёлых запросов. Если у меня есть дотсуп к базе (раз у браузера есть, то и у меня есть), то я могу работать с ней напрямую.
• Трафик. Гоняем весь трафик от базы к клиенту через инет (о, ужас).

Ну и раз официально подтверждено, что клиент (браузер) работает с базой напрямую - да, мы откатываемся на 15 лет назад и используем технологию толстых клиентов.


Ээ.. Модульность же! Серверные проблемы - это проблемы сервера. А если это не так - то это проблемы неудачной архитектуры системы.

Работать с базой можно только через интерфейс, предоставленный сервером. Со стороны клиента это будет выглядеть примерно так:



Трафик можно нативно сжимать. Да и вообще, его сейчас никто не считает 


История всегда возвращается на круги своя с каждым последующим витком эволюции. Например, могу напомнить, что ставшие нынче такими понтовыми "облака" восходят к древним мэйнфреймам с терминалами.


Задача как раз в синтезе системы в целом (клиент <=> сервер), а не одной ее части (клиент).

Ага.. Т. е. это таки не базный сервер, а аппилкейшен сервер  И здесь мы уже работаем "через интерфейс" и нам пофиг, что реально (мб) сервер лезет в "обычную" базу и т. д.? Забавно.

Да, чисто для полноты картины замечу, что во всяких CouchDB можно интегрировать базный и аппликейшен сервер. Нужно ли это? Ну это уже другой вопрос.

Это сообщение отредактировал(а) Любитель - 23.1.2011, 15:25

У меня да, страницу приходиться перезагружать, для отправки всех данных на сервер. А чем не устраевает Аякс контрол? Можно привязать к каждому элементу на странице.

Это сообщение отредактировал(а) Freyzer - 24.1.2011, 12:42

Хороший вопрос. Мне такой в голову не приходил.
Навскидку ответы такие: или по умолчальным файлам контента, или по sitemap.xml (в развитом веб-приложении почему бы его не иметь-то?)
Ну и если будет подрихтован синтаксис js с целью декларативно подгружать контент - почему бы поисковику бы и не парсить эту радость? В целом - проблемы негров шерифа не волнуют. В конце концов все лежит открытым текстом.
Насчет закладок - вот тут хз. Надо подумать. Но навскидку ничего трудного не вижу. В конце концов сейчас можно делать закладки на аякс-страницы с использованием hash-части урла, почему бы и не делать так же в новом вебе?



В сайте нет ничего сверхестественного.
Просто там предлагается либа, которая позволяет ДЕКЛАРАТИВНО оформлять фишки ява-скрипта. То, о чем я говорю: чем больше развивается веб, тем более сложные (функционально) действия обретают декларативный синтаксис. Игнорировать эту тенденцию нельзя.
Сначала было достаточно псевдоклассов HOVER, сейчас вон че предлагают...
Иллюстрацией я назвал лишь потому, что тенденции, которые я описал, имеют вполне реальное подтверждение.
Все больше веб становится не документо-центричным, а скрипто-центричным.
А то, что раньше реализовывалось пачкой ухищрений, ныне стремится стать просто декларативным объявлением, а реальную работу выполняет либо сам браузер либо фреймворк. Не?

Я имел в виду, что это затратно с точки зрения аппаратных ресурсов. ИМХО технологии типа: Java/Flash/Silverlight имеют большие преимущества перед нативным кодом. Не надо отдельно собирать приложение под каждую поддерживаемую платформу (а если приложение подписано, то и подписывать надо отдельно). Приложение изначально пишется с расчетом на "песочницу" предоставляемую фреймворком.