Да мне всё хватает. Просто изначально это пошло из XHTML. Что забыли - да, не нравится :)
Не нашли применение.

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

1. Тут мы вклиниваемся в мир CSS. Наглядно использование атрибута не по назначению. Меня блевать тянет от такой разметки и кода. В итоге это приводит только к постоянным багам/фиксам лучи поноса в сторону jQuery

2. Нестандартный атрибут. Ну это вообще каша получается. Зачем тогда в стили выносить остальное? Вчера я правил один интересный баг. Скрипт писался давно. Его код устанавливал свойство hidden для DOM-узла ссылки. Это задумывалось просто как флаг. В итоге, в html5 вводят тег hidden и ссылки исчезают. Мораль - не засирай чужое пространство, когда есть свое.

3. Реализация на классах вообще не катит. Нет уже такой гибкости. Ведь в значение атрибута занести кучу всякой инфы.
Ещё это не катит, потому что нельзя будет использовать всю мощь XML-схем.

4. В догонку:
http://www.w3.org/TR/2004/WD-xhtml-m...dule_namespace

Может потом ещё что вспомню.

т.е. раз мы протестировали модуль и валидатор проверил разметку, это значит что больше тестировать нету смысла? По-моему спорное утверждение. В идеале, возможно. Просто готовые компоненты часто подгоняют под свои требования и в результате вылазят всякие проблемы. Но идею я понял

хм, странно, читая вот это:
видно, что тебе это не нравится, и закрадывается подозрение, что все-таки призываешь

ok, поспешил, попытка номер два

<div ns-parent="name">
  <p>Paragraph</p>
  <ns-item class="item-1">text</ns-item>
  <ns-item class="item-2">text</ns-item>
  <div class="nbsp">&nbsp;</div>
</div>

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

т.е. в общем-то все это можно легко сделать без пространств имен (их можно сэмулировать), за исключением валидации

Этот случай я учел. Я сам допиливал не один плагин. Ну я уже говорил - пишем либо модуль, либо расширение к модулю, если нам нужно что-то изменить. Код модуля остается прежним. Это некая прослойка.
Поясню. Стиль кодирования я не навязываю. Можешь говнокодить сколько хочется, но это всё в пределах модуля и ни на что не влияет. Сейчас же сложно анализировать большую кучу кода - что к чему относится, что за что отвечает. Вспоминаются слова моих бывших коллег, Java-кодеров: "Как вы тут вообще разбираетесь? Не видно ведь кто что делает. В Java, например, видно какой класс для чего написан.".
Валидатором можно оттестить именно применение того или иного модуля на разных страницах. Создал страницу - новый тест писать не надо, всё уже написано до вас.
Ну там не совсем библиотека была. Просто самописный кусок логики с использованием jQuery. В нем же и устанавливалось это свойство.
Ну не пойдет такая попытка. Не видно по коду что к чему относится. Зачем вообще эмулировать пространства имен, если они уже вшиты в браузер, спецификацию, валидатор и т.д.?
Ради того что бы один раз написать "удобный" код, придется постоянно его фиксить - сомнительное преимущество. Не лучше ли сразу огородится от всех и делать что хочется?

Хочу обратить внимание, что я ничего не придумываю, а пользуюсь уже готовыми инструментами. Всё в рамках стандартов.

Ты мне лучше расскажи, что не нравится в пространствах имен?

Хоть что-нибудь то скажите, что вы вообще думаете о такой архитектуре?

- подозреваю что реализация на клиенте будет работать очень медленно. или делать как GWT.

Откуда такие подозрения?

Мне кажется наоборот. Вот структура платформы:
V(HTML, CSS, DOM) - C(Platform) - M(Module 1, Module , Module 3...)

Общение между платформой и модулями происходит на объектном уровне. Т.е. быстро. Это ведь не работа с DOM.

После того, как модули сделали все необходимые изменения, контроллер направляет их в представление. Представление пачкой применяет все инструкции уже непосредственно в HTML, CSS и DOM. Понятное дело, что будут реализованы все возможные оптимизации на этом этапе.
Получается, что все действия модулей нагружать не будут.

Покажите мне код )
нужны примеры. а там будет видно как это все красиво и быстро.

Будет тебе код. Ещё годик погоди только. Шутка.

Скорость программы обеспечивает алгоритм. Если алгоритм неправильный - страдает реализация.

Чем профессионал отличается от начинающего кодера? Опытный программист способен выбрать правильный алгоритм (ну или направление) ещё до начала написания кода. Он и без кода может дать предварительные оценки.
Так что включи мозг.

Ты же сказал, что скорей всего будет медленно. Вот и объясни, на основании чего такие подозрения.

тому что xml нужно парсить. преобразовывать ваши модули во чтота, что понимает браузер. это все будет DOM манипуляции, а то как работает ишак с DOM методами все знают.

Это уже давно не XML :)
Сейчас речь идет о XHTML.

что XML, что XHTML один черт другого не слаще.

вы пытаетесь сделать вот это - http://ru.amplesdk.com/

То, что они используют пространства имен, не значит что это то же самое. Я всё придумал сам. Это вообще не то.

почему не видно? То же самое, только вместо двоеточия - дефис. Зачем эмулировать - это уже другой вопрос, раз пространства имен есть в стандарте, лучше использовать их

согласен, сомнительное

все нравится :) Просто у меня есть более актуальные проблемы

а сложно что-то сказать. Потому что это все пока что теория. Теоретически оно будет лучше, но непонятно для каких проектов (ведь серебрянной пули не существует, м?), насколько удобный будет интерфейс, надо ли будет фиксить ядро и т.д.

спорное утверждение, возможность оценки и ее достоверность порпорциальнальна задаче

Не тоже самое. Так браузер их понимает на уровне движка, что дает преимущества при поиске узлов. У меня дерево из >2000 нод перебирается за 25мс в ff. При этом ещё много нужной инфы собирается. По сути - это время инициализации платформы + ещё немного на другие расходы. А дальше всё на объектном уровне работает. Кэш.

Вот это сейчас самая важная проблема.

Интересная старая тема. И каково состояние на данный момент? Есть ли готовые варианты реализации?

Есть реализация.
Как я уже говорил, сейчас идет работа над объектной моделью. Если кто не правильно понял - я не пытаюсь создать свой DOM. Мне реально нужна и важна ваша помощь. jQuery - спасательный круг для дибилов, нехуй тратить на него свое время.
Если вы хотите начать создавать веб-ПРИЛОЖЕНИЯ - прошу принять участие.

x-yuri, спасибо за потраченное время и критику.

B~Vladi,
Меня давно интересует возможность внедрения в xhtml фрагментов с различными пространствами имён и их обработка динамически подгружаемым кодом. Так же интересен сахар для XPath выборок.
Хоть пока и не знаю где это можно применить, но всёравно интересно. Если это то что я думаю, то отпишись в личку.

Programming languages that barf on a syntax error do so because a partial executable image is a useless thing. A partial document is *not* a useless thing. One of the cool things about XML as a document format is that some of the content can be recovered even in the face of error. Compare this to our binary document friends where a blown byte can render the entire content inaccessible.
---
ну как же? полезность - весч сильно относительная. возьмём простое приложение, которое делает два запроса к бд, первый за сессией, второй за контентом. первый запрос содержит синтаксическую ошибку и падает. но позвольте! можно же выполнить второй запрос и вывести пользователю! давайте сделаем его и выведем пользователю хоть что-то!
и наоборот. какой-то умник написал <script> в результате чего хрен вы получите вместо контента, а ещё десяток всплывающих окошек в нагрузку, и регистрироваться на сервисе вам придётся заново, и извиняться перед друзьями, что завалил их спамом, а ещё не сможешь зайти на свой любимый сайт javascript.ru потому что внезапно стал участником ддос-атаки на него.
мягкость правил приводит к наплевательскому их исполнению. а страдают в итоге пользователи.
===
это уже поинтереснее. Но 1) это проблема решаемая, 2) почему из-за тех, для кого это важно должны страдать все? 3) для тех, для кого это важно - это не проблема, у них есть опытные специалисты и достаточно денег, 4) вместо xss получаем проблему с чисткой контента, создаваемого пользователями
---
1. лучше не допускать проблем, чем решать их после того, как они вылились в массовые беспорядки
2. страдать должен только тот разработчик. который допустил вывод неэкранированных данных и больше никто. ошибки парсинга хмл выявляются очень быстро при первичном тестировании. а при правильно выбранных инструментах исключаются вовсе. на моей памяти небыло ни одного случая связанного с невалидностью отдаваемого хмл. только один раз один умник вставил disable-output-escaping="yes" и благополучно получил уязвимость которая прошла через все этапы тестирования прямиком в лапы злостных кулхацкеров.
3. и эти специалисты не ноют, что битый хмл не будет показан пользователю. потому что знают, что у них он никогда битым не будет. а те, кто ноет - неявно подписываются тем самым под своей профессиональной непригодностью.
4. эту проблему мы получаем независимо от формата передачи. вопрос лишь в том, решать ли её или же стыдливо прятать голову в песок, притворяясь буд-то её на самом деле нет.
===
Кстати, БЭМ, по идее, близок к твоей задумке, только без XHTML-модулей.
---
основное преимущество лего - это возможность привязать сразу несколько компонент к одному тэгу, но одновременно это и его недостаток, так как наложение разных стилей и поведения на один элемент с высокой долей вероятности приводит к конфликтам. в результате всё-равно появляется куча вложенных дивов, дифференциирующих зоны ответственности компонент.
а вот в моей реализации через пространства имён - у каждой компоненты свой тэг, параметры которому задаются аттрибутами. инициализация виджетов происходит по мере загрузки страницы, при удалении из документа - вызывается деструктор.
а знаете как в лего передаются параметры? а вот так: onclick="return {name:'i\-metrika',counter:149814}" мне даже страшно представить как они это формируют с помощью xsl шаблонов о0"
===
Вообще, я говорил не о формате, а о DTD. Т.е. если мы используем документ в формате XHTML (расширение xhtml, content-type: application/xml+xhtml), то это уже указание на формат, а не какое-то там DTD, поэтому и парсится соответственно.
DTD XHTML прижился и исптользуется. Формат XHTML не используется. Потому что ишак клал на него.
Давайте далее, говоря о XHTML, подразумевать соответствие документа с DTD XHTML в формате HTML.
---
миме-тип никаким образом формат менять не может. формат - это прежде всего структура данных. если я jpeg картинку переименую в readme.txt - от этого она не перестанет быть картинкой. не смотря на то, что некоторые просмотрщики картинок не смогут с ним работать. дизайн xhtml специально задумывался таким, чтобы его можно было распарсить как html так и xml парсером. разные методы прасинга разумеется приводят к формированию разных моделей документа. формат - один. парсеров - два. чтобы включить xml парсер достаточно указать тип application/xml - это понимает даже ие. и тут к вашим услугам и возможность объявлять собственные сущности, и валидировать документ налету, и применять xsl трансформации. другое дело, что ие он не понимает xhtml элементы в полученном xml, но для него можно сделать фолбэк в виде простенькой xsl трансформации, которая заставит его воспользоваться html парсером к результату полученному после валидации, подстановки сущностей и xsl трансформации.
===
т.е. раз мы протестировали модуль и валидатор проверил разметку, это значит что больше тестировать нету смысла?
---
есть разные тесты. есть тесты самого модуля, а есть тесты корректности его использования. валидация вполне может справиться со вторым видом тестов. другое дело, что дтд конкретно не хватает для этого мощности. я склоняюсь к тому, что сам модуль должен следить за валидностью используемых им структур данных, так как ограничения могут быть самыми причудливыми.

спасибо, посмеялся :) но вторая сторона правды заключается в том, что он позволяет сконцентрироваться на более важных для тебя вещах ;)

а вообще, B~Vladi, советую выложить свой проект на github, если ты хочешь чтобы он быстрее развивался. В частности, ты узнаешь, например, что другие думают об этом. Но возможно что это все превратиться в нечто другое, не то, что ты хотел (чья-то реализация станет популярнее). Но это тоже не плохо, это может указывать на какие-то твои ошибки

:)

первый вариант - не понял: 1) он про ЯП, а не про документ; 2) и даже если превратить этот пример во что осмысленное, то получится, что: если при выдаче резальтатов поиска произошла ошибка - это не повод ничего не отображать. Второй довод имеет право на существование, но: 1) почему пользователи имеют возможность post'ить html-код, почему они не используют твой markdown-редактор, м? ;) 2) почему это должно быть обязательным для всех сайтов? 3) в конце концов, защиты от XSS не существует?

это не однозначное решение проблемы, это решение одной проблемы и появление другой

ога, пользователи недоступного сайта ни разу не пострадают, они просто уйдут на другой сайт. To err is human ;)

ну да, ну да, потому что эти специалисты - уже не люди :) А если серьезно, 1) на чем основана эта уверенность? 2) профессиональной непригодностью для чего? Для того чтобы разработать систему управления полетом космического корабля, бороздящего просторы галактики? p.s. программисты не ноют ;)

ну это уже не ко мне вопрос: в тему вызывается Kolyaj. Я БЭМ не использую, разве что может быть некоторые идеи мне близки, те что не касаются всяких оптимизаций. А почему ты решил, что они это с помощью xsl проворачивают?

в двух словах, ты слишком завышаешь требования к разработчикам вне зависимости от задачи. И если бы в сети не было столько мусора, как сейчас, она бы так не развилась. К тому же, простые смертные - это проверка решения на применимость, это мешает распространению излишне умных идей

что такое "защита от хсс"?

>> вопрос лишь в том, решать ли её или же стыдливо прятать голову в песок, притворяясь буд-то её на самом деле нет.
> это решение одной проблемы и появление другой
чтд

у них большинство сервисов на хсл-е

если бы правила парсинга хтмл не были так сложны в сети меньше бы было дырявых сайтов.

хм, и где подвох? Защита от внедрения на сайт кода злоумышленником. В контексте нашей беседы это, например, htmlpurifier

боюсь причинно-следственная связь осталась за кадром

и сеть бы развивалась другими темпами

отлично, а теперь попробуй с помощью htmlpurifer сделать невалидный хмл

мне как-то пох с какой скоростью развивается сеть. в ней и так полно дерьма. куда уж больше?

чтд

не понял, при чем тут xml и _не_валидный?

при том, что на выходе он генерирует ххтмл фрагмент

это типа такой окольный способ ответа на мой вопрос?

а что это за правильно выбранные инструменты и что ты вообще можешь посоветовать в плане xhtml?

Пока рано, а так да.
Главное, что бы идеология и архитектура сохранилась, а какая будет реализация - не важно.Ну так то он всё правильно говорит. Не умеешь работать с форматом - не берись.

Ну вот :(
Ещё кое-что надумал, пока пытался заснуть вчера... Асинхронность. Например (из прошлого html-кода):

this.parent.item.Style({
  display: 'none'
}, function(dataObject, property){
  // Представление изменилось
});

или:

this.parent.item.Event({
  click: false
}, function(dataObject, property){
  // Обработчик установлен
});

Так как всё происходит после выполнения кода, в недрах контроллера (платформы), сразу обработать результат не получится. Например, часто бывает нужно узнать размеры элемента сразу после изменения данных. Архитектура (которая у меня в голове и в черновиках) это позволяет сделать. Как вам такой код?!

на тот вопрос я не отвечал, так как не вижу смысла

любые инструменты, которые работают с документом не как со строкой, а как с деревом.

события надо не только вешать, но и убирать, поэтому лучше что-то типа такого:

var clickSpy= Spy( elem, 'click', function(){} ).listen() // создали и запустили прослушку
...
clickSpy.forget() // забили на прослушку
...
clickSpy.scream() // кричим другим агентам

delete this.parent.item.Event().click;

Это что такое? Модуль не может напрямую влиять на другие модули. Это чуть ли не основная цель всей архитектуры. Полная независимость.

ну асинхронность она определенно усложняет. Просто пока ее немного, это не мешает. А потом начинаешь изобретать цепочки вызовов, т.е. прячешь эту асинхронность. На github'е видел не одну библиотеку, в которой это есть. Например, можно так реализовать, через рекурсию, для небольших цепочек, на mootools:

var AsyncChain = new Class({
	Implements: [Events, Options],
	
	_chain: [],
	_state: {},
	
	initialize: function( options ){
		this.setOptions( options );
	},
	
	add: function( f ){
		this._chain.push( f );
		return this;
	},
	
	run: function(){
		run.of(this)(0);
		return this;
		
		function run( i ){
			var f = this._chain[i];
			if( ! f )
				return;
			f.of(this)( run.of(this).pass(i+1) );
		}
	},
    
	clear: function(){
		this._chain = [];
		return this;
	},
	
	set: function( options ){
		$extend( this._state, options );
		return this;
	}
});

пример использования:

var chain = new AsyncChain();
        chain.setOptions({
                'onFailure': onFailure.of(this).pass(chain),
                'onCancel': onCancel.of(this).pass(chain)
        })
             .set( options )
             .add( this._disableLink )
             .add( this._setPhotoUrl )
             .add( this._setPhotoDownloadUrl )
             .add( this._showThrobber )
             .add( photosession.getThumbnailPath )
             .add( photosession.setPhotoUploadUrl )
             .add( photosession.loadPhoto )
             .add( photosession.loadCropResize )
             .add( this._hideThrobber )
             .add( this._showDialog )
             .add( photosession.cropResize )
             .add( photosession.setThumbnailFormField )
             .add( this._loadThumbnail )
             .add( this._showThumbnail )
             .add( this._closeDialog )
             .add( this._enableLink )
             .run();

Не не не, Девид Блейн.

Вот, например, есть объект, описывающий тег:

var data = {
  value: 'text',
  display: false
}

Код модуля:

function module(data){
  // Изменяем данные
  data.text = 'new text';
  data.display = true;
}

Как это всё выглядит с наружи:

var data = getData(); // получаем объект data

// Ситуация - обрабатываем событие. Для этого передаем объект data всем модулям, которым он принадлежит
var modulesLength = modules.length;
while(modulesLength--){
  modules[modulesLength](data); // Модули сделали всё, что им необходимо
}

// Обновляем представление в соответствии с объектом data.
update(data);

Отсюда видно, что представление изменится только после выполнения обработчиков модулей. Что бы можно было учесть эту ситуацию - я и предложил это решение. Цепочки тут не нужны.

Согласен. Это выглядит как асинхронность на уровне кода, но по сути это событие.

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

но у тебя же нету другого выхода?