[-SkyNet-]

йухуу

ваш покорный слуга узнал о существовании jQuery Mobile

кстати вот Мини-курс по jQuery для дизайнеров

мини-курсы HTML гуглите сами, кто не в теме еще =)

Comments

[Bird]

Вот прям как доктор прописал - круто изложено, в первых строчках самое главное - как это работает! )

[Ка]

jQuery - зло

[-SkyNet-]

Ка обоснуйте

[Ка]

-SkyNet- Во-первых, ориентация на действия, а не на компоненты. Это удобно для небольших страничек, куда нужно вставлять ajax-овые функции, но как только пытаются делать чуть более сложные страницы, получается пахучая густая каша.
А во-вторых, самая большая беда именно в том, что из-за простоты jQuery, его начали использовать дизайнеры. И вобще, все кому не лень. "Нет, мы хотим использовать jQuery, потому что мы его уже использовали, и так тебе сможет помочь с проектом наш уборщик". В итоге, если кто-то говорит, что нужно пару багов в их проекте, завязанном на jQuery, можно быть на 100% уверенным, что столкнёшься с ОГРОМНОЙ БЛЯТЬ КУЧЕЙ ГОВНА, в которой ЧЁРТ НОГУ СЛОМИТ.

[-SkyNet-]

Ка не побоюсь показаться чайником, спрошу:
1) что имеется ввиду под "ориентация на действия, а не на компоненты" какие именно компоненты ? почему перед ними действия должны быть менее приоритетными в событийной среде?
2) что посоветуете для больших страничек?

насчет жопорукого кода - так это ж кросс платформенное явление

[Ка]

-SkyNet- от обращения на вы у меня баттхёрт

1. когда нет такой абстракции как "компонент" (например, "календарь" или "корзина" или "таблица заказов"), то по мере усложнения моделей получается штука, называемая "Spaghetti code", то есть простыня, которую потом, после определённого промежутка времени, или другому человеку, разбирать очень сложно. В противном случае, код получается удобно разложенным по полочкам, по классикам и по красивым методам, которые не просто списком лежат, а разграниченно, в соответствии со своей областью. Это очень легко разбирается.

2. я не большой специалист по rich interfaces и javasсript'овым фреймворкам, но, насколько я в курсе, чуть лучше ситуация состоит с prototype. Там по-крайней мере есть костыль для классов и наследования, которое сильно упрощает компоненто-ориентированное построение страниц, вместо захерачивания всей логики в тело документа и обработчики событий.

[-SkyNet-]

Ка тут налицо непонимание предметной области

дело в том, что в рамках самого фреймворка не может существовать понятия компоненты, так как эта абстракция - сугубо контекстная (определяется внутри приложения).
календарь и прочее, написанное на основе фреймворка назвается плагин, виджет или расширение (extension). для jQuery они живут на plugins.jquery.com

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

а prototype - это прежде всего библиотека прототипов, а уж потом - фреймворк. кстати, "костыль для классов" - это притянутая за уши реализация классической классо-ориентированной модели для "специалистов", не способных осознать прототипо-ориентированную идеологию самого языка Java sсript.

[Ка]

-SkyNet- блять. извини, но ты где вычитал эту хуйню, всё, что ты написал?

[-SkyNet-]

из личного опыта работы с различными фреймворками

а что именно так возмущает ? аргументы, факты ?

[Ка]

-SkyNet- из личного опыта работы с какими фреймворками? с CMS-ками? о да, там часто используется слово плагин.

Другой вопрос, что "компонент" - это очень общее понятие, и смысл его - изолированный подключаемый элемент, выставляющий наружу какие-то обработчики событий или сами свои события. Это даже может быть не UI-компонент, а, например, менеджер аутентификации. Который, в свою очередь, может собираться из пачки других компонентов со своим контроллером.

Отсутствие кодовой каши без чёткой и внятной структуры при использовании штук типа jQuery для построения UI сложных систем означает либо постоянный серьёзный контроль над качеством кода и изначально потраченного времени на написание "скелета" этой структуры, либо постоянный повышенный расход времени на простые вещи. Оба случая - утопия.

С prototype я вобще запутался. Почему jQuery - фреймворк, а Prototype - библиотека прототипов? Что такое тогда фреймворк? И не надо мне про хорошесть прототипного программирования, вижу много плюсов для того, чтобы делать разную МАГИЮ как в ruby-рельсах, но не понимаю, зачем весь этот оверхед и обфускация структуры для операций с UI и разговоров с веб-сервисом.

[-SkyNet-]

основной фреймворк, с которым работаю сейчас в PHP - это Yii, в JS - как раз jQuery.

фреймворк отличается от библиотеки тем, что он по сути является платформой разработки, расширяя язык и создавая некую обертку, с которой уже и происходят все манипуляции, тогда как необходимость в манипуляциях на уровне базовых возможностях языка зачастую отпадает совсем (пример - траверс DOM в jQuery с помощью функции $ и селекторов против рекурсивного обхода дерева DOM).
а библиотека - есть некая кладезь как правило неструктурированных инструментов (например, набор функций для работы с фтп - libftp). структура библиотеке полагается по мере увеличения объема - как раз во избежание не читаемой простыни кода. исторически сложилось, что в Prototype сначала появились расширения базовых объектов, а уже после - инструментарий траверса и манипуляций с элементами DOM, поэтому Prototype часто называют библиотекой.

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

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

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

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

[-SkyNet-]

а Prototype - библиотека прототипов потому, что она содержит набор прототипов. Java sсript - прототипо-ориентированный язык, то есть не включает в себя понятие класса, там прототипы являются метафорой объектов, создаваемых на их основе. Prototype содержит те самые костыли для реализации классов для удобства разработчикам, которым не придется вникать в идеологию языка, а дает возможность писать приложения на основе философии и принципов ООП, как они привыкли в своем C++, PHP и пр., но это не является органичным для Java sсript и имеет недостатки.

[Ка]

фреймворк отличается от библиотеки тем, что он по сути является платформой разработки, расширяя язык и создавая некую обертку

В хаскелле или ruby, больше сходу ничего на ум не приходит, можно понаделать какой-нибудь метамагический DSL, но даже это не будет расширением языка, а всего лишь штукой, которую можно на нём сделать. Не то, чтобы я не понял твою мысль, но хочу предостеречь разговор от скатывания в евангелизм с придиранием к неключевым словам. Prototype - это фреймворк, и привнесение каких-то исторических соображений только отвлекает от сути.

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

Дэ, тут один из корней проблемы. Я пытаюсь объяснить, что плохо в jQuery в общих терминах, принятых в Computer Science, а ты мне рассказываешь про определения из вполне определённых фреймворков, с которыми тебе доводилось работать.

далее,
>> в иерархии фреймворка (да и приложения, реализованного на его основе), модуль является крупнейшей единицей. Исходник jQuery, например, — это один файл, состоящий из набора функций и небольшого куска кода для сетапа. Что ты тут хочешь назвать модулем? Ты уверен, что из этого нельзя собрать приложение вобще без чётко определённой иерархии, и что так не делают минимум 60% jQuery-кодеров?

>> как раз модуль является отдельностоящим изолированным элементом Как раз нет. Модуль - ни разу не изолированный и не отдельностоящий элемент, только очень немногие модули, в самом низу иерархии, не имеют зависимостей от других модулей. Модуль может состоять из чего угодно, где критерий включения - логическая совместимость. Обычно есть какой-нибудь модуль "utilities" со всякими простенькими костылями, "core", "UI", "services" и прочее. На самом деле есть всякие энтерпрайзные паттерны архитектур (особенно Microsoft'овский отдел яйцеголовых ими любит заниматься), но я лично никогда с ними на практике не сталкивался. Оффтоп, да.

>> под компонентой приложения как правило понимают вот это ты зря, "как правило" под "компонентом" понимают совсем не это. Я не знаю, из каких лекций ты это взял, и не знаю, как с этим спорить. Просто отошлю к истории, откуда это понятие взялось, там всё написано.

>> но это не является органичным для Java sсript и имеет недостатки О, прошу уточнений. Только чётко и по делу, недостатков не по делу прототипирования я тебе могу накидать легко, ровно как и реальных практических достоинств ООП. Чуть сложнее - недостатков прототипов по делу, сам толком не пользовался, нужно будет подумать.

>> для удобства разработчикам, которым не придется вникать в идеологию языка, а дает возможность писать приложения на основе философии и принципов ООП расскажи мне, как охуенно вникают в идеологию javasсript люди, использующие jQuery. Также ракажи, кому вобще нужно вникать в идеологию javasсript, исключая самих разработчиков этих фреймворков. И что вобще в этом плохого? Я не говорю о базовых, важных даже для простых вещей, свойствах языка, которые сразу воспримет любой опытный программист с достаточным уровнем общей грамотности, конечно.

[-SkyNet-]

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

вообще - о чем суть спора ? я попросил обосновать почему же jQuery зло.
я все же не поверю, что jQuery зло потому что он не КОО =) КОО по сути не может быть альтернативой других идеологий ввиду того, что каждая парадигма лучше там, для чего ее придумали. во фреймворке jQuery нет и не может быть никаких компонент, так как это обертка инструментов JS для траверса и манипуляций DOM плюс набор вспомогательных функций (кажется, я повторяюсь). тут нечего обобщать в отдельные компоненты.
а одним файлом jQuery сделали чтобы было удобно подключать.
недостатков jQuery тем более в общепринятых терминах я так и не дождался, но думаю что уже обойдусь.

теперь тема про кодовую кашу. как она может зависеть от структуры фреймворка? если минимизированный jQuery в исходнике записан в одну строчку, то что - код на его основе такой же должен быть ?

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

а недостатки костыльного ООП в JS очевидны - прежде всего отсутствие уровней доступа к методам и свойствам (public, protected, private). остальные нюансы не очень хорошо помню, но в общих словах - недостатки костыльного метода (в любом деле) состоит в неполной реализации парадигмы.

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