XSLT: Идеологические вопросы / проблемы

Спасибо за ответ =)

> > Проблема №1
Язык — PHP. Рекомендации — понял. Только вот теперь появляется проблема с преобразованием данных из $this->_data в JSON. Скорее всего от формата JSON придётся отказаться. Буду думать…

> > Проблема №2
> Ссылки на примеры?
Ну да, на примеры. Но не по языку, а по организации XSL-шаблонов. Мне в основном нужен «образ и подобие», а дальше — я уж перейму

> > Проблема №3
Ну у меня и свой JS-шаблонизатор есть =) Только он скорее процедурный, чем декларативный. В этом то и загвоздка: непонятен принцип =(

альтернатива HTML5 прямо сейчас

В момент «наступления тупика разработки» хрома не было. Так что не считается )

альтернатива HTML5 прямо сейчас

> можно расширять таким способом обычный xhtml
Мне кажется, в этом случае теряется весь смысл статьи. Ведь тогда все «новые тэги» переименовать в DIV и присвоить каждому из них отдельный className

> есть такие слухи, что IE собирается переходить на WebKit
Идея будет считаться работоспособной не в момент перехода на WebKit, а в момент смерти IE6 и IE7 (а это будет ой как не скоро)

> И это уже вот прямо щас работает
А дайте ссылку, пожалуйста, на какую-нибудь страницу, где бы IE7 отобразил выдуманный тэг, используя ваши CSS-правила.

альтернатива HTML5 прямо сейчас

> При этом вы можете добавить в документ нужный
> вам доктайп или написать свой собственный DTD.
>…
> В будущем, если идея приживется…

Идея не приживётся. Она просто не рабочая. И это диагноз!
IE при любом раскладе не будет отображать страницу как HTML, и особенно если указать DTD:
— он либо будет отображать структуру XML-документа;
— либо покажет только текст и проигнорирует все выдуманные вами тэги и, как следствие: CSS не будет работать вообще.

альтернатива HTML5 прямо сейчас

Если для документа сервер выдаёт в заголовках Conent-Type: application/xml, то IE (и Opera версия меньше толи 7.5, толи 8.5) выдают структуру XML-документа.
Чтобы страница работала, нужно выдавать Content-Type: text/html. + для всех браузеров нужно указывать DOCTYPE XHTML.

Правда, если выдавать text/html, то идея уже не будет работать: придётся использовать HTML-тэги вместо выдуманных myhtml, handlers и пр.

(я экспериментировал с XML-страницами, но собирать я их хотел на сервере в Aptana Jaxer. но я тогда зашёл в тупик и перестал что-либо делать. если интересно, вот тестовая страница: joos.nnov.ru. Она работает во всех браузерах (вроде бы =))

Споры о шаблонизаторах: троллинг или умные мысли?

А как люди начинают «верить» в XSLT? (я тоже хочу =)

Классы в Javascript: вызов методов родительского класса

… исходя из этой какой-то теории…

Классы в Javascript: вызов методов родительского класса

> не, ну я ж уточнил — «абстрактно отойти от спецификации», а не кардинально

Мне кажется, здесь основной вопрос в подходе:
— можно знать как всё работает на самом деле, и разрабатывать, исходя из этого знания;
— можно объяснять реальное положение дел исходя из этой теории, и разрабатывать исходя из теории.
Это две крайности — все в какой-то степени используют оба подхода. И получается, что вроде бы делаем одно и тоже, а получается по разному =)

Классы в Javascript: вызов методов родительского класса

Тут весь вопрос в обосновании «исключений из правила»: если нельзя, но очень хочется, то можно.

Например, «штрих» может не быть «пустым интерфейсом».
В нём могут содержаться какие-то конечные функции/методы. Для них могут понадобится какие-то свои данные, которые в конечном итоге будут содержатся в thisObj.
Эту штуку нельзя будет назвать «штрихом» — это фактически будет «примесь» (если я всё правильно понял =)

С другой стороны — сейчас есть только понимание, а конкретных задач пока нет. Посмотрим как всё получится =)

Классы в Javascript: вызов методов родительского класса

Я плагинами и хотел реализовать «множественное наследование» (только чтобы не было косяков с именованиями) — получилось «как получилось» =)

Что касается данного «плагина», то в данный момент самом плагине содержатся только «дефолтные реализации методов» © — значит это как минимум «примесь»; плагин не содержит своих данных — значит это «штрих» =)
tenshi, посмотри пожалуйста, правильно ли я тебя понял.

Я сегодня во второй раз (надеюсь в последний) «наконец-то понял про штрихи и примеси».
Переименую функцию в JooS.Mixin (потому что в общем случае плагин будет «примесью»), но буду стараться, чтобы каждый отдельный плагин получался «штрихом».

Классы в Javascript: вызов методов родительского класса

Я погуглил, нашёл вот это lj.rossia.org/users/ringill/10156.html и наконец-то понял что такое «штрихи» и «примеси»!
Штрихи — это, действительно, примеси. Там, видимо, при компиляции должны накладываться ограничения на доступ к переменным. Т. к. эти решения должны быть реализованы на уровне языка, то как и с «инкапсуляцией в JS» это всё можно реализовать только «простейшими организационными мерами» ©

Как оказалось, у меня реализован этот механизм, но я назвал это «плагином»: JooS.Plugin =)
Суть в следующем: прототип класса расширяется каким-то объектом (у меня — набором функций другого абстрактного класса). Этот набор должен включать какую-то функцию «инициализации» этого штриха/примеси. Эта функция должна быть вызвана в конструкторе класса

http://beatle.joos.nnov.ru/ — теперь тут «анимированные PNG» можно таскать по странице мышкой.
( это ссылка на «абстрактный класс», а это ссылка на расширенный через штрих/примесь класс )

Классы в Javascript: вызов методов родительского класса

Поэтому, я думаю, сложностей не будет.

Сложности — только организационные. Если будет задача (например, «админка на питоне в виде расширения к FF =)»- всё будет интересно и просто; не будет задачи — будет всё наоборот

да ну не о стандартах я говорю

я имел ввиду «стандарт-дефакто», а не w3c какой-нибудь )

А вот что будет — посмотрим =)

+1: Посмотрим =) Это же самое, кстати, и про майкрософт можно сказать:
Сейчас они против, а через год-два, если с коммерческой точки зрения будет выгодно (пусть даже косвенно), поменяют своё решение.

Классы в Javascript: вызов методов родительского класса

Ничего я не отрицаю, просто в JS классов то нету. Всё ж открыто; конструкции вида

(function() {
// код
})();

… удобны, но не всегда. Так что, имхо, все попытки «открыть только интерфейс работы с данными» превратятся в разработку костылей (я осознаю, что JS-код статьи многие тоже считают костылём =))

простой, понятный, эффективный и легко поддерживаемый код.

Это такой код, к виду которого привыкло большинство или разработчик… Да и нет для JS критериев «понятности», «простоты» и «удобства»! Такой уж язык.

рефакторить код с «иерархией классов» довольно сложно

Рефакторить сложно только «мегобайты кода». Мне кажется это не про JS (точнее — это не про околосайтовые задачи).

Классы в Javascript: вызов методов родительского класса

Перефразирую классика:
> > ES4 (JS2) питон, к сожалению (или к счастью =)) обломался
> к счастью ;)

Это я к тому, что он не станет стандартом-«языком браузеров», как JS (из-за IE в первую очередь). Хотя, от Microsoft можно чего угодно ожидать: в IE8 — стремление к стандартам, в IE9 — питон, в IE10 — ES4 =))

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

Классы в Javascript: вызов методов родительского класса

> наследование и инкапсулящия противоречат друг другу
заметьте — я ни слова не сказал про инкапсуляцию =)

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

Классы в Javascript: вызов методов родительского класса

В вашем коде есть баг. Вот как эго воспроизвести:

var C1 = Class.create({ init: function() { alert("C1"); } });
var C2 = C1.extend({
 init: function() {
  alert("C2");
//  debugger;
  this.super('init')();
 }
});

var C3 = C2.extend({ });
var C4 = C3.extend({
 init: function() {
  alert("C4");
  this.super('init')();
 }
});

var obj = new C4();

* This source code was highlighted with Source Code Highlighter.

Ожидается, что выскочит 3 алерта: С4, С2, С1. А на самом деле работа скрипта закончится ошибкой «too much recursion» =(

Разница между нашими подходами в том, что вы — наследуете друг от друга классы, а я — функции.

Классы в Javascript: вызов методов родительского класса

Потому что $super ссылается на одноимённую функцию родительского класса. В другой функции текущего класса такая ссылка недоступна.

Компоненты в Unobtrusive JavaScript

> скрипты могут не прогрузиться из-за ограничения на длину урла
В этом случае скриптов будет несколько. Например, вот тут: covex.in.nnov.ru/technology/799495.html

С нэймспейсами не всё так гладко — страницы могут быть не совсем валидным XML, третий FF стал как-то по другому работать с ними… А вообще +1. Надо покопать в эту сторону.

Компоненты в Unobtrusive JavaScript

Основная концепция «ненавязчивости» — не в порядке загрузки, а в необязательности JS. Следуя этому принципу разработчик должен обойти все подводные камни в виде «непредсказуемого интерфейса» — это решаемо.

Вы исходите из того, что «сначала загружается картинка, а потом — JS». Это не так.
Сначала загружается HTML, а потом всё остальное. При чём тяжёлая картинка и скрипты могут и должны загружаться параллельно (и скорее всего скрипты загрузятся быстрее).

(а рыбийглаз я увидел когда я знал только document.write и onclick='...' — тогда это было огого)

Классы в Javascript: вызов методов родительского класса

Я исходил от другого. У Python и JavaScript немного разное положение:
Python — серверный язык. Как я понял — он возник после PHP, Perl и всего такого — не нужен он дизайнерам и оформителям интерфейсов. Изучать его будут люди, знающие другие языки программирования (начинающие — не в счёт =)

JavaScript — язык браузера… Перед написанием придумал аргумент: «Вот, глянте ка, на компани.яндекс.ру в вакансиях только разработчик интерфейсов есть» (а там ещё аж 2 вакансии — JS и JS-гуру =). Пойду с другой стороны.

Кроме него ничего нет. Даже его нет — есть jQuery и т.п. Всеобщий накопленный багаж знаний о языке позволяет либо делать какие-нибудь поделки, например через onmouseover и onmouseout менять картинку; либо делать простые вещи используя простой фреймвёрк. Это может сделать любой. Непрограммист, желая войти на рынок труда в качестве «разработчика интерфейсов», легко в него войдёт. Программист же не захочет, потому что если не копать глубже — это «не язык, а лажа какая-то» (я так не думаю, — Прим.ред.).

Вобщем, естественный отбор, эволюция и всё такое =)