Не так давно была у меня задача написать один AJAX компонент. По ходу написания столкнулся с проблемой что существующие реализации "ООП движков на жабаскрипт" не удовлетворяют моим требованиям. Были проведены эксперименты с Prototype, Mootools, jQuery, YUI и др. Была перечитана куча форумов и веб-страниц, но удовлетворяющего решения найдено не было. В итоге, вооружившись терпением был написан свой небольшой фреймворк, который в данный момент я инициировал в виде OpenSource проекта под кодовым именем AJAX.OOP.
Предлагаю всем ознакомиться с проектом, попробовать его использовать, создать на его основе свой или поучаствовать в его развитии — на ваш выбор
CS>Предлагаю $parent поменять на $super. Это общеупотребимое наименование этой сущности.
предлагаю оставить так, как есть,а не менять.
так читабельнее и понятней.
Здравствуйте, c-smile, Вы писали:
CS>Предлагаю $parent поменять на $super. Это общеупотребимое наименование этой сущности.
Готов обсуждать это положение. Я так понимаю что ваш аргумент — это JavaScript ближе к Jave, чем к чему-либо ещё?
Лично я пока что солидарен с реакцией sunnyman'а — название $parent было выбрано осознано. Возможно потому, что я более склонен к РНР .
Но повторяюсь же — хотелось бы послушать еще аргументы и мнения — возможно и сделаем именно так как вы просите. Как вариант можно сделать алиас this.$parent = this.$super... а там уже кому как по душе
Как водится накопал кучу багов — поэтому поставил пометку в релизе — бета Сильно не бейте — самому и писать и тестить крайне сложно — в процессе создания компонентов на основе либы — выковыриваю новые глюки. Если кто может помочь с тестированием — буду очень благодарен. Как водится тестировать лучше то что лежит в SVN'e, поэтому если кто заинтересован — пишите в личку — дам доступ к репозиторию...
Здравствуйте, ЖуК, Вы писали:
ЖуК>Здравствуйте, 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 опять же...
Здравствуйте, 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, Вы писали:
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 — в этом случае можно будет использовать и так и так. Хорошо это или плохо — вот в чем вопрос?
Здравствуйте, ЖуК, Вы писали:
ЖуК>Здравствуйте, sunnyman, Вы писали:
S>>прочитав аргументы c-smile уже, трудно сказать насчет алиаса... S>>то, что надо super — здесь он хорошо проаргументировал.
ЖуК>Ну с этим я уже согласился... Вопрос в другом — можно оставить this.$parent как алиас для this.$super — в этом случае можно будет использовать и так и так. Хорошо это или плохо — вот в чем вопрос?
Если названия алиасов уже относятся к разным по сути вещам в стандарте,
это будет только запутывать. Хорошо когда библиотеки придерживаются общего стиля со стандартом.
Лутше конечно один $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
Здравствуйте, sunnyman, Вы писали:
CS>>Предлагаю $parent поменять на $super. Это общеупотребимое наименование этой сущности. S>в качестве алиаса, предложил бы ключевое слово base S>в ряде технологий это слово используется S>т.е. $super == $base
Ну раз уж на то пошло, то и "parent" также используется в ряде технологий. В принципе для того, чтобы не плодить неразбериху, лучше иметь все-таки один акцесор. Так понятней и проще. Но я как и всегда — готов выслушать любые аргументы в пользу противоположной точки зрения.
Здравствуйте, ЖуК, Вы писали:
ЖуК>Предлагаю всем ознакомиться с проектом, попробовать его использовать, создать на его основе свой или поучаствовать в его развитии — на ваш выбор
А почему часть методов имеет названия в Pascal case, а часть — в Camel case?
Здравствуйте, anonymous, Вы писали:
A>А почему часть методов имеет названия в Pascal case, а часть — в Camel case?
Эээммм... да. Согласен, некоторые вещи немного вводят в заблуждение. Вообще, изначально принцип задумывался такой:
lowerCamelCase — для методов и свойств
UpperCamelCase — для имен классов и метода Class (который собственно и используется для объявления классов)
т.е.
Ajax.isString — метод
Ajax.Request — класс
но как видите не полочилось без исключений... например в свойствах имен-браузеров видим UpperCamelCase, так у меня получилось из-за IE и потом пошло-поехало, также как исключение получились свойства Connections, Version и методы Toggle(), Resolve().. каюсь — не досмотрел...
В остальных сущностях вроде все впорядке, включая предопределенные классы.
Как считаете — насколько критично вносить исправления? Стоит ли?