Не так давно была у меня задача написать один AJAX компонент. По ходу написания столкнулся с проблемой что существующие реализации "ООП движков на жабаскрипт" не удовлетворяют моим требованиям. Были проведены эксперименты с Prototype, Mootools, jQuery, YUI и др. Была перечитана куча форумов и веб-страниц, но удовлетворяющего решения найдено не было. В итоге, вооружившись терпением был написан свой небольшой фреймворк, который в данный момент я инициировал в виде OpenSource проекта под кодовым именем AJAX.OOP.
Предлагаю всем ознакомиться с проектом, попробовать его использовать, создать на его основе свой или поучаствовать в его развитии — на ваш выбор
Здравствуйте, ЖуК, Вы писали:
ЖуК>Здравствуйте, c-smile, Вы писали:
CS>>Предлагаю $parent поменять на $super. Это общеупотребимое наименование этой сущности.
ЖуК>Готов обсуждать это положение. Я так понимаю что ваш аргумент — это JavaScript ближе к Jave, чем к чему-либо ещё? ЖуК>Лично я пока что солидарен с реакцией sunnyman'а — название $parent было выбрано осознано. Возможно потому, что я более склонен к РНР . ЖуК>Но повторяюсь же — хотелось бы послушать еще аргументы и мнения — возможно и сделаем именно так как вы просите. Как вариант можно сделать алиас this.$parent = this.$super... а там уже кому как по душе
В JS v.2 эта сущность называется super. В JS v.1 super это зарезервированное слово, ничего не далает, но тем не менее.
parent/child в JS domain предполагает отношение владения но никак не отношение наследования.
Например parentNode() и firstChild(). функция $.parent() в jQuery опять же...
var $ = function( id) {
// Если получили в качестве аргументов элементы, то функция вернёт только первый.
// Лучше эту проверку поместить после следующей, чтобы всё таки функция прошлась по всему списку.if (Ajax.isElement( id)) return id;
var el = null;
if (arguments.length > 1) {
for (var i = 0, els = [], length = arguments.length; i < length; i++) {
els.push( $( arguments[i]));
}
return els;
}
return $d.getElementById( id);
};
Здравствуйте, ЖуК, Вы писали:
ЖуК>Здравствуйте, c-smile, Вы писали:
CS>>В JS v.2 эта сущность называется super. В JS v.1 super это зарезервированное слово, ничего не далает, но тем не менее.
CS>>parent/child в JS domain предполагает отношение владения, но никак не отношение наследования. CS>>Например parentNode() и firstChild(). функция $.parent() в jQuery опять же...
ЖуК>Спасибо за посыл на спецификацию ECMAScript Edition 4. Дождемся мы его кода-нибудь? В общем я предлагаю алиасы. Или это плохо? Какие мысли?
прочитав аргументы c-smile уже, трудно сказать насчет алиаса...
то, что надо super — здесь он хорошо проаргументировал.
CS>> Это общеупотребимое наименование этой сущности. CS>>parent/child в JS domain предполагает отношение владения CS>>Например parentNode() и firstChild(). функция $.parent() в jQuery опять же...
как и писал c-smile, надо следовать максимально близко к стандартам и общеупотребительной терминологии, так как другим будет проще юзать библиотеку ведь меньше надо будет "ломать" мозги на новый лад и новую терминологию, а значит меньше learning curve — что, увеличивает шансы на использование библиотеки многими разработчиками.
поэтому, как он писал, сделать super, вместо parent...
Здравствуйте, ЖуК, Вы писали:
ЖуК>Здравствуйте, sunnyman, Вы писали:
S>>прочитав аргументы c-smile уже, трудно сказать насчет алиаса... S>>то, что надо super — здесь он хорошо проаргументировал.
ЖуК>Ну с этим я уже согласился... Вопрос в другом — можно оставить this.$parent как алиас для this.$super — в этом случае можно будет использовать и так и так. Хорошо это или плохо — вот в чем вопрос?
Если названия алиасов уже относятся к разным по сути вещам в стандарте,
это будет только запутывать. Хорошо когда библиотеки придерживаются общего стиля со стандартом.
Лутше конечно один $super оставить.
Здравствуйте, sunnyman, Вы писали:
CS>>Предлагаю $parent поменять на $super. Это общеупотребимое наименование этой сущности. S>в качестве алиаса, предложил бы ключевое слово base S>в ряде технологий это слово используется S>т.е. $super == $base
Ну раз уж на то пошло, то и "parent" также используется в ряде технологий. В принципе для того, чтобы не плодить неразбериху, лучше иметь все-таки один акцесор. Так понятней и проще. Но я как и всегда — готов выслушать любые аргументы в пользу противоположной точки зрения.
Здравствуйте, ЖуК, Вы писали:
A>>А почему часть методов имеет названия в Pascal case, а часть — в Camel case? ЖуК>Эээммм... да. Согласен, некоторые вещи немного вводят в заблуждение. Вообще, изначально принцип задумывался такой: ЖуК>lowerCamelCase — для методов и свойств ЖуК>UpperCamelCase — для имен классов и метода Class (который собственно и используется для объявления классов) ЖуК>Как считаете — насколько критично вносить исправления? Стоит ли?
Во-первых, единообразие названий должно быть. Во-вторых, в JavaScript принято для свойств объекта использовать lowerCamelCase (если не считать решения от Microsoft). Лучше поправить.
Свойства идентификации браузеров можно переименовать, добавив перфикс "is". Это решит проблему с IE. Либо ввести одно строковое свойство browser, которое бужет принимать то или иное значение. Либо сделать это свойство числовым и добавить несколько "константных" свойств типа BROWSER_MSIE, и сравнивать так: Ajax.browser == Ajax.BROWSER_FIREFOX.
Свойство Version лучше записать в верхнем регистре, это будет символизировать его "константность".
ЖуК wrote:
> имен-браузеров видим UpperCamelCase, так у меня получилось из-за IE и > потом пошло-поехало, также как исключение получились свойства
Просто можно применить такое правило — кейс для аббревиатур точно такой же как и для слов. Т.е. класс будет называться class Ie, а фция ie(). Это позволяет красиво записывать подряд идущие аббревиатуры, типа class XmlDomDao, xmlDomDao() вместо class XMLDOMDAO, xMLDOMDAO(??).
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
ЖуК wrote:
> Переделал первім способом — через is. Второй действительно очень хорош, > но именно для данной задачи очень громоздкий как с точки зрения > реализации так и с точки зрения использования.
стырь отсюда: http://docs.jquery.com/Utilities/jQuery.browser
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
CS>Предлагаю $parent поменять на $super. Это общеупотребимое наименование этой сущности.
предлагаю оставить так, как есть,а не менять.
так читабельнее и понятней.
Здравствуйте, c-smile, Вы писали:
CS>Предлагаю $parent поменять на $super. Это общеупотребимое наименование этой сущности.
Готов обсуждать это положение. Я так понимаю что ваш аргумент — это JavaScript ближе к Jave, чем к чему-либо ещё?
Лично я пока что солидарен с реакцией sunnyman'а — название $parent было выбрано осознано. Возможно потому, что я более склонен к РНР .
Но повторяюсь же — хотелось бы послушать еще аргументы и мнения — возможно и сделаем именно так как вы просите. Как вариант можно сделать алиас this.$parent = this.$super... а там уже кому как по душе
Как водится накопал кучу багов — поэтому поставил пометку в релизе — бета Сильно не бейте — самому и писать и тестить крайне сложно — в процессе создания компонентов на основе либы — выковыриваю новые глюки. Если кто может помочь с тестированием — буду очень благодарен. Как водится тестировать лучше то что лежит в SVN'e, поэтому если кто заинтересован — пишите в личку — дам доступ к репозиторию...
Здравствуйте, c-smile, Вы писали:
CS>В JS v.2 эта сущность называется super. В JS v.1 super это зарезервированное слово, ничего не далает, но тем не менее.
CS>parent/child в JS domain предполагает отношение владения но никак не отношение наследования. CS>Например parentNode() и firstChild(). функция $.parent() в jQuery опять же...
Спасибо за посыл на спецификацию ECMAScript Edition 4. Дождемся мы его кода-нибудь? В общем я предлагаю алиасы. Или это плохо? Какие мысли?
Здравствуйте, sunnyman, Вы писали:
S>прочитав аргументы c-smile уже, трудно сказать насчет алиаса... S>то, что надо super — здесь он хорошо проаргументировал.
Ну с этим я уже согласился... Вопрос в другом — можно оставить this.$parent как алиас для this.$super — в этом случае можно будет использовать и так и так. Хорошо это или плохо — вот в чем вопрос?
Здравствуйте, Rn, Вы писали:
Rn>Если названия алиасов уже относятся к разным по сути вещам в стандарте, Rn>это будет только запутывать. Хорошо когда библиотеки придерживаются общего стиля со стандартом. Rn>Лутше конечно один $super оставить.
Прислушиваюсь к мнению большинства и поддерживаю здоровую тенденцию.
В общем пофиксил довольно много и добавил кое чего (включая данное изменение). В итоге выпустил новую версию для скачивания. Что и как поменялось — здесь:
Буду весьма признателен всем за комментарии, мысли, идеи, любую посильную помощь и баги.
Здравствуйте, ЖуК, Вы писали:
ЖуК>Не так давно была у меня задача написать один AJAX компонент. По ходу написания столкнулся с проблемой что существующие реализации "ООП движков на жабаскрипт" не удовлетворяют моим требованиям. Были проведены эксперименты с Prototype, Mootools, jQuery, YUI и др. Была перечитана куча форумов и веб-страниц, но удовлетворяющего решения найдено не было.
Чем не удовлетворили существующие фреймворки вроде Prototype или Microsoft AJAX Control Toolkit?
Здравствуйте, PaulMinelly, Вы писали:
PM>Чем не удовлетворили существующие фреймворки вроде Prototype или Microsoft AJAX Control Toolkit?
А еще, если по секрету, то мне всего-навсего нужно было 2 вещи — ООП-движок и хендлер Аякс-запросов. И я, честно говоря, не понял, почему мне в довесок все либы пытаются прикрепить +100-200 КБ кода Но это не самая большая беда (у всех есть минимизаторы + gzip — понятно, но тем не менее — факт остается фактом — при всех прочих у меня кода меньше. "прочие" — включают условия задачи — только аякс и ооп).
Куда больше меня не удовлетворяли реализации эмуляторов ООП-двигла (мне нужно было наследование с возможностью вызова любых парент-методов чего я к сожалению нигде не встретил и чтобы объекты были нормаьными — с работающим оператором instanceof на них). Поэтому я и принял решение сделать свою мини-либу — ООП+Аякс и ничего лишнего. При нормальной реализации ее можно будет довешивать готовыми компонентами.
Безусловно, я не берусь утверждать, что АБСОЛЮТНО нигде нет того, что я сделал — возможно где-то у кого-то и есть, но только найти мне его не удалось. Как результат — такой проект. Буду только счастлив если кому-то еще пригодится.
CS>Предлагаю $parent поменять на $super. Это общеупотребимое наименование этой сущности.
в качестве алиаса, предложил бы ключевое слово base
в ряде технологий это слово используется
т.е. $super == $base
Здравствуйте, ЖуК, Вы писали:
ЖуК>Предлагаю всем ознакомиться с проектом, попробовать его использовать, создать на его основе свой или поучаствовать в его развитии — на ваш выбор
А почему часть методов имеет названия в Pascal case, а часть — в Camel case?
Здравствуйте, anonymous, Вы писали:
A>А почему часть методов имеет названия в Pascal case, а часть — в Camel case?
Эээммм... да. Согласен, некоторые вещи немного вводят в заблуждение. Вообще, изначально принцип задумывался такой:
lowerCamelCase — для методов и свойств
UpperCamelCase — для имен классов и метода Class (который собственно и используется для объявления классов)
т.е.
Ajax.isString — метод
Ajax.Request — класс
но как видите не полочилось без исключений... например в свойствах имен-браузеров видим UpperCamelCase, так у меня получилось из-за IE и потом пошло-поехало, также как исключение получились свойства Connections, Version и методы Toggle(), Resolve().. каюсь — не досмотрел...
В остальных сущностях вроде все впорядке, включая предопределенные классы.
Как считаете — насколько критично вносить исправления? Стоит ли?
Здравствуйте, anonymous, Вы писали:
A>Свойства идентификации браузеров можно переименовать, добавив перфикс "is". Это решит проблему с IE. Либо ввести одно строковое свойство browser, которое бужет принимать то или иное значение. Либо сделать это свойство числовым и добавить несколько "константных" свойств типа BROWSER_MSIE, и сравнивать так: Ajax.browser == Ajax.BROWSER_FIREFOX.
Переделал первім способом — через is. Второй действительно очень хорош, но именно для данной задачи очень громоздкий как с точки зрения реализации так и с точки зрения использования.
трудно сказать насчет алиаса...
