Вполнение Javascript в XML

[vflash]

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

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

[B~Vladi]

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

[x-yuri]

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

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

Ради того что бы один раз написать "удобный" код, придется постоянно его фиксить - сомнительное преимущество. Не лучше ли сразу огородится от всех и делать что хочется?

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

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

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

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

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

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

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

[B~Vladi]

То же самое, только вместо двоеточия - дефис.

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

насколько удобный будет интерфейс

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

[SV0L0CH]

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

[B~Vladi]

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

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

[SV0L0CH]

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

[tenshi]

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 трансформации.
===
т.е. раз мы протестировали модуль и валидатор проверил разметку, это значит что больше тестировать нету смысла?
---
есть разные тесты. есть тесты самого модуля, а есть тесты корректности его использования. валидация вполне может справиться со вторым видом тестов. другое дело, что дтд конкретно не хватает для этого мощности. я склоняюсь к тому, что сам модуль должен следить за валидностью используемых им структур данных, так как ограничения могут быть самыми причудливыми.

[x-yuri]

jQuery - спасательный круг для дибилов

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

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

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

ну как же? полезность - весч сильно относительная. возьмём простое приложение, которое делает два запроса к бд, первый за сессией, второй за контентом. первый запрос содержит синтаксическую ошибку и падает. но позвольте! можно же выполнить второй запрос и вывести пользователю! давайте сделаем его и выведем пользователю хоть что-то!
и наоборот. какой-то умник написал <script> в результате чего хрен вы получите вместо контента, а ещё десяток всплывающих окошек в нагрузку, и регистрироваться на сервисе вам придётся заново, и извиняться перед друзьями, что завалил их спамом, а ещё не сможешь зайти на свой любимый сайт javascript.ru потому что внезапно стал участником ддос-атаки на него.
мягкость правил приводит к наплевательскому их исполнению. а страдают в итоге пользователи.

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

1. лучше не допускать проблем, чем решать их после того, как они вылились в массовые беспорядки

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

2. страдать должен только тот разработчик. который допустил вывод неэкранированных данных и больше никто. ошибки парсинга хмл выявляются очень быстро при первичном тестировании. а при правильно выбранных инструментах исключаются вовсе. на моей памяти небыло ни одного случая связанного с невалидностью отдаваемого хмл. только один раз один умник вставил disable-output-escaping="yes" и благополучно получил уязвимость которая прошла через все этапы тестирования прямиком в лапы злостных кулхацкеров.

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

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

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

основное преимущество лего - это возможность привязать сразу несколько компонент к одному тэгу, но одновременно это и его недостаток, так как наложение разных стилей и поведения на один элемент с высокой долей вероятности приводит к конфликтам. в результате всё-равно появляется куча вложенных дивов, дифференциирующих зоны ответственности компонент.
а вот в моей реализации через пространства имён - у каждой компоненты свой тэг, параметры которому задаются аттрибутами. инициализация виджетов происходит по мере загрузки страницы, при удалении из документа - вызывается деструктор.
а знаете как в лего передаются параметры? а вот так: onclick="return {name:'i\-metrika',counter:149814}" мне даже страшно представить как они это формируют с помощью xsl шаблонов о0"

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

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

[tenshi]

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

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

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

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