Pull to refresh
21
0
Майк Зимин @mihazimin

User

Send message
Здесь, кстати, и кроется ответ на то, о чем все спорят выше.

На сегодняшний день Rich Internet Applications (RIA) и AJAX, — две технологии, которые могут быть использованы для написания полноценных web applications.

Первая, — flash based, вторая, — JavaScript based.

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

А раз появляется желание, то мы его и удовлетворили, для этого заюзали что могли, — символ решетки.

Думаю, кстати, что если ТБЛ написать, то он возможно согласится, что в URL просто тупо надо добавить возможность таких запросов, только уже не полулегальным через решетку а цивилизованным, — через специальные конструкции, — возможно какой-то другой символ.
Огромное спасибо за подсказку.
При всем уважении к вашему опыту, всё таки считаю, что технология имеет право на жизнь.

Отделять обычные якори от jR предполагается (в большом тексте это написано) по простому правилу: есть двоеточие после символа решотки, — значит, — jR, нету, — значит обычный якорь. Всё это решаемо.

Ещё раз повторю: это не «стандартная функциональность». И я не вижу сейчас способов сделать что-то подобное по-другому.
Передача через GET кирилицы, — это не большее загрязнение URL, чем использование jR. Одинако это грязно.
HTTP GET и jR были созданы для разных потребностей, их нельзя сравнивать, просто лучше выписать, — какие характеристики имеет один способ, какие другой.

Если коротко, — то при использовании jR не происходит обращение к серверу (если страница в кеше), а GET удобно использовать для seo-шников совместно с mod_rewrite, допустим (чтоб красиво было).

Каждый метод хорош, и имеет свои характерные отличия от других.
Если застандартизировать jR, то никто путаться не будет, а копаться в коде, который был написан полгода назад всегда будет сложно.
Якорь. Вы имеете конструкцию
Да так было в HTML, но с приходом XML/XHTML/RDF его можно и нужно использовать для других целей. Т.е. теперь это, — указатель на какую-то часть, допустим, XML документа.

Конечно, использования '#' для передачи параметров JavaScript не описано стандартом, но и не особо запрещено, если честно.

Всё что там сказано, — это то, что часть после решотки должна удовлетворять [a-zA-Z][a-zA-Z_.:-]*
Ух ты, спасибо. Вот и применение в реально работающем проекте.
Хотя я конечно догадывался, что не первые мы стали такое внедрять. Все кто хотели увидеть применения, — ссылка выше.
Остается одна проблема - продемонстрировать переход к новой информации в строке адреса для пользователя. Наверняка есть какое-то решение без использования символа "#".

К сожалению, нет. Если вы меняете url, то запрос будет отправляться на сервер если точно такого-же запроса небыло раньше. Единственное исключение, — это использовать символ '#'. Если бы в W3C сделали подобные конструкции в URL, то я бы и не предлагал использовать '#'.
Perfect article. Всё верно.
Дело в том, что разные языки в разной мере подвержены заимствованиям из других языков. Так вот русский язык, — очень сильно этому подвержен.
Это может не нравиться, этим можно гордиться, но это факт.
Интерес представляет то, что при «заимствованиях» слово, естественно, может обогатиться, изменить звучание.
Например: семпл, семплик, семплюшечка, семпля.

Хотя я с вами полностью согласен в том, что о значении слов забывать не надо и
комфортабельный = удобный. Поэтому ставлю вам плюс.
Кстати, насчет HAML (если интересно). Всё таки у него есть проблемы:
http://mihazimin.habrahabr.ru/blog/24383…
К тому же в HAML сегодня есть очень большая проблема, решение которой (если это решение создатели создадут) будет навряд ли красиво смотреться синтаксически:

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

<div><img src="..." /></div>

В HAML можно сделать лишь так:

<div>
<img src="..." />
</div>

Что будет интерпретировано большинством браузеров как тег div, а в нём по порядку:

1. TextNode (" ")
2. ElementNode (img)
3. TextNode (" ")

А это может реально отразиться на вёрстке, т.к. браузеры, при некоторых обстоятельствах, отрисуют эти TextNode, т.е. пробелы.

И это очень большая проблема, которая стоит на пути "индустриального" применения HAML в более-менее крупных,серьёзных проектах.

Поэтому, думаю, что HAML хорош, конечно, но XOWML (как его приемник), возможно уже сейчас, — лучше, т.к. по крайней мере позволяет писать любой XHTML код, а не набитый иногда категоричекси-ненужными текстнодами.
Вы не запутались в том, чего хотели?

Нет. И ваши комментарии сделают эту идею ещё лучше, потому что, банально, - в споре рождается истина.

Итак, насчет VIM. Всё таки в вашем примере генерируется код

<img src="images/elephant.jpg" width="240" height="181" />

а в мое:
.Image{%img src="images/elephant.jpg" width="240" height="181"{}}
генерит

<div class="Image"><img src="images/elephant.jpg" width="240" height="181" /></div>

т.е. Image в примере это произвольное название класса, в принципе, не связано с тегом img. Поэтому надо пересчитывать :)
Спасибо. Первый позитивный комментарий.
Нет, это немного другое. Всё таки мне как верстальщику намного понятнее видеть перед глазами код XOWML, чем XHTML.

http://mihazimin.habrahabr.ru/blog/24383…

Синтаксис XHTML содержит большую избыточность. Этого не отрицают в W3C, они и сами разрабатывают human-readable нотации для XML-based языков.
Не понял что вы имеете ввиду, поясните, пожалуйста.
Потому что и сам Тим Бернерс Ли (создатель HTML и вообще мега чел) говорит, что XML не является удобным для чтения его людьми. XML был придуман для удобства ПО. (И эти надежды он оправдал).
Для языка RDF вот например есть несколько нотаций. RDF/XML — для обмена данными между машинами и человеко-читаемый (human-readable) язык N3.
Я и не ставил целью при создании этого языка заменить XHTML. Нет, я его люблю. Но, всё таки дерево тегов (тем более когда большинство из них являются div) можно представлять и в более удобной форме.
И помоему, нам эту более удобную форму найти удалось.
Да,да я ждал этот вопрос. Кстати, если вы заметили, то я в тегах к этой записи указал HAML. В принципе XOWML и возник как ответ на HAML.
Что мне не нравится в HAML, так это его очень большая зависимость от отступов.
Да, в языке Питон отступы как элемент синтаксиса использованы с умом, сошлашусь, отчасти, что и YAML хорош (хотя имхо JSON лучше).
Но вот рассмотрим такой пример, - есть у нас один HAML файл и второй;
а мы хотим все дерево тегов из первого файла вставить в определенное место файла второго, но тогда придется подправлять у этого первого файла отступы во всех строках, что, по-моему, не очень хорошо.

С XOWML таких проблем не будет.

Насчет кривой поделки всё таки не соглашусь. При продумывании синтаксиса были учтены многие существующие языки и их особенности.

Верстальщику ничего не надо учить, чтобы начать верстать на XOWML (достаточно знать XHTML и CSS). Количество строчек в XOWML файле будет всегда совпадать с количеством строк в HTML файле, поэтому, допустим, отлаживать скрипты будет удобно (номера строчек сбиваться не будут).
Ещё из вкусностей то, что невалидность в текстовых редакторах будет достаточно легко светить.

А создать ПО для перевода XOWML в XHTML тоже будет достаточно легко (это требование тоже учитывалось при дизайне языка). Может даже десятком регэкспов всё обойдется (продумать надо).
Незнаю, а что конкретно в этой идее плохого?

Information

Rating
Does not participate
Location
Россия
Date of birth
Registered