Видимо, мне не удалось полностью донести, в чем суть Sqimitive. Она не запрещает иметь много или мало методов. Это основа для твоего мини-фреймворка, который специфичен для данного приложения. Нужно несколько источников и кэширование? Напиши методы, используй ООП и все будет DRY и KISS.
У тебя один опыт, у меня другой. Мнений столько же, сколько программистов. По моем опыту модели имеют один источник (иначе бы это были разные модели). У тебя не так? Сделай по-своему. Много кода это не займет, зато будет работать именно так, как ты хочешь.
В примере я пытался показать, как технически происходит наследование (по крайней мере, как это выглядит снаружи). Я не хотел вдаваться в детали цепочек prototype, какая разница между prototype и __proto__, что такое hasOwnProperty() и прочего. Сказав «два независимых класса-прототипа» я, действительно, схитрил, но это не меняет того, что наследование с точки зрения привычного ООП в JavaScript нет. Это и было целью примера, и на мой взгляд она никуда не делась.
А если для одной и той же модели данные приходят из разных мест в разных форматах, как это лавировать?
Сейчас штатно в assignResp нельзя передать набор других правил (они берутся из _respToOpt), но я думаю добавить во второй аргумент (options) параметр, который будет использоваться вместо _respToOpt самой модели.
В этом случае «assignResp_pusher» может быть алиасом для вызова assignResp(resp, {map: resp-to-opt}).
Zav, давай всё же будем объективны. Если у «полноценных» модели набор fetch/parse одни на один класс (как в Backbone), то чем они лучше Sqimitive/assignResp? В последнем случае ты можешь его настроить по-разному в рамках одной модели или коллекции — правила для трансформации, источник данных, что-то ещё.
Только тут такой момент — любые данные укладываются в модель. Исключения очень редки.
Это кому как. Мне лично кажется лишним создавать отдельную модель на каждый вид — особенно если там 1-2 флага, которые внутри этого вида только и используются.
Ты же пишешь код не в самой библиотеке, а в подключаемом компоненте
А, я понял, что ты изменяешь их собственный код. К компонентам у меня претензий нет. Но у меня был очень яркий опыт одного из первых проектов, где я использовал Backbone. Я расширял и расширял его (Backbone), пока в итоге проект не разросся до 3к строк + еще 4к строк «расширений». Это было неповоротливым и медленным. Конечно, ошибки проектирования/опыта имели значение, но всё равно не решающее. Это не единичный пример.
На мой взгляд, надстройки над библиотекаим наподобие Marionette страдают как раз этим — пытаясь заткнуть дыри изначально отсутствующего функционала они производят на свет намного больше кода, чем это нужно.
Пойми меня правильно — это всё лишь инструменты, и каждый выбирает инструмент, который ему удобен.
Конечно, у каждого свой подход. И я отдаю себе отчёт, что мой — довольно редкий :)
Что касается решений в других фреймворках — я их ищу и изучаю постоянно. Я не бегаю от новых идей.
На главной странице есть кнопка Costumize — бери что надо.
Не буду спорить, так как CanJS не знаю.
Не вижу причин атрибутов с датакастами, конвенторами данных и т.п. где-нибудь кроме моделей :-)
Просмотри ещё раз про state-based programming. Опции — они полезны не только в моделях, более того, они наиболее полезны именно в представлениях. Смотри на мир шире. Не обязательно для каждого чиха создавать свой API.
Ну так метод и реализуется в модели. Причем реализуется одной строкой, если не специфичный. В результате получаешь ощутимо меньше кода.
А если у модели нет ID? Специфичный ID? Как ты реализуешь общую версию этого метода? Придётся его перекрывать в потомках? А как они отреагируют на составной ID (из нескольких полей)?
Зачем вообще обобщённое понятие ID? Его можно избежать, добавив только там, где нужно. Кода на это потребуется минимумально.
Накручивать абстракции вокруг базовых классов или бекэнд?
Абстракции. Если в твоём проекте/тебе удобно использовать виды, модели и коллекции — наследуй от Sqimitive 3 класса, будут тебе обычные M-C-V. Так я делаю и не вижу в этом каких-либо проблем. Если же у тебя какой-то проект на 1000 строчек, который не будет развиваться — тебе, может, и одного хватит.
Бэкенд это другая тема.
Большинство библиотек позволяют их модифицировать не мешая основному коду программы, тем самым получаем свою сборку, которая легко обновляется до более новых версий.
Хорошая библиотека не должна модифицироваться, это на мой взгляд грубое нарушение принципов модульности. Естественно, если делается свой форк — это одно, но отдельный форк на каждый проект? По-моему перебор. Иначе бы не было такого понятия, как плагины (которые я видел в том же CanJS).
И про обновление ты явно хватил. Обновить Knockout с парой-тройкой плагинов? Ты знаешь его настолько хорошо, чтобы лазить в нутрях?
Бонусом является то, что код отлично оттестирован, в отличии от самописного.
Дело-то в том, что избыточный код не всегда даёт тебе всё, что нужно, и его тоже приходится доделывать. Либо искать, где там разработчики расставили свои капканы и почему твоя логика не согласуется с их. Я особенно сильно это прочувствовал, воюя с Backbone'овским sync.
Мне нравится подход, когда ты точно знаешь как что работает, и что происходит.
Это мне близко и я лишь говорил о том, что 1600 с комментариями и 11.5к — это всё же разные степени «когда ты точно знаешь как что работает». Я не уверен, что даже удалив все комментарии ты сможешь разобраться в таком объеме быстрее, чем в Sqimitive. Но, может быть, дополнительная функциональность для тебя более важна, и это нормально. Просто это не мой выбор, я вообще довольно аскетичен в выборе средств и инструментов.
.е. на выходе имеет 1.5 тысячи строк для изучения. Уже не так страшно, да?
Да, не так. Но, насколько я понял, CanJS это около 6к?
Нет, первый раз слышу. Бегло просмотрел API и код — на первый взгляд кажется того же масштаба, что и Ember. Модули, много кода, разные компоненты. Особенно конструкции вроде таких меня сразу вгоняют в тоску:
Sqimitive — это полная противоположность. Здесь ничего нет, всё собирается вами, используя тонко подогнанный и маленький набор универсальных инструментов… А дальше — как глина. Хотите коллекции, модели и виды? Не вопрос, просто наследуйте их (кстати, оба проекта Belstone как раз и используют разделение на M-C-V, потому что это удобно).
Просто я не вижу, зачем разделять их на уровне библиотеки, так как все свойства т.н. моделей (атрибуты), коллекций (фильтрация + вложенность) и представлений могут быть полезны для любого другого типа класса. Не хотите — не используйте вложенность в моделях, это ваше дело.
Больше того, имена методов я специально выбирал не совсем стандартные (можно было назвать add, а не nest) — именно для того, чтобы их можно было перекрыть и назвать в соответствии со стилем в вашем проекте. Нужен getById? Сделайте его, используя доступные методы. Аналогично со всем прочим.
Трюк в том, что при распределении работ в команде тебе достаточно знать интерфейс класса, и не задумываться как оно там внутри работает и выбирается.
Всё верно, поэтому Sqimitive в серьёзном проекте напрямую не будет использоваться — между ним и приложением будет небольшая (или большая) прослойка-переход в виде тех же M-C-V. Её ведь всё равно приходится делать на том же Backbone. Потому что всегда свой подход хоть в чём-то, но не совпадает с подходом авторов библиотеки.
Либо чуть более сложной конструкцией, с конкретизацией как тянем данные
Важно соблюдать баланс между «преднаписанным» API и временем, которое требуется на его изучение. Можно подумать, что если в Ember почти 50к строк кода, то вам ни строчки не придётся писать самому. Ан-нет, костыли будут точно так же, как и при использовании другой библиотеки. Ещё и грузится дольше будет. (Ну, я утрирую, конечно.)
Короче, из Sqimitive можно сделать основу для любого проекта, имея в её, гм, основе компактный код вместо многотысячных библиотек, которые так и так приходится доделывать. Кому-то такой подход нравится, кому-то нет.
Вопрос такой: что если мы наследуемся от метода, в котором уже реализован +, и в нашем тоже есть +. Они оба выполнятся или будет перекрытие?
Так вы наследуете не метод, вы перекрываете (с =) или расширяете (в других случаях) цепочку событий. Если у вас в базовом классе уже есть +event, а в потомке — ещё один +event, то в цепочке первым окажется метод (обработчик события) базового класса, после которого пойдёт метод потомка.
Представьте, что когда вызывается extend() вы блок events берётся и передаётся в NewClass.on({events}). Это и есть наследование в стиле Sqimitive.
Если есть желание, могу через скайп показать код пары проектов.
Я действительно думал над этим, но в итоге решил оставить как есть, чтобы не было путаницы, какой класс наследовать. По задумке, когда вы используее Sqimitive, то наследуете в вашем приложении базовый класс, где собственно Sqimitive.Sqimitive используете единожды, а дальше вы упоминаете его только как App.MyBaseObject или App.Sqimitive (понятно, что ограничений тут никаких нет).
Не только Backbone. Мне не встречалась ни одна библиотека, где было бы вменяемо сделано наследование. Собственно, именно это и было основной причиной для создания своего велосипеда. Результат мне нравится.
Рискую быть закиданным помидорами, но до отдельных тестов для Sqimitive я уже не добрался. Хватило и тех, которые писал для связанных проектов. Впрочем, это всегда можно поправить.
Decloak точно для той же сети, MAC совпадает? Сети могут быть и безымянные, по идее, хотя мне не попадались и имя всегда раскрывалось. Можете попробовать ещё wifite — он похож на airdump-ng, запустить и наблюдать.
См. третий абзац в «Скрытые сети… такие скрытые» — airdump-ng после успешного раскрытия заменит <length: 0> на имя сети, а в правом углу появится сообщение.
Не уверен, что bridged будет работать — он ведь подключает адаптер к физической сети, а не устройству. Я лично делал через usb — если адаптер внешний (а иногда даже если внутренний — все равно на usb сидит), то его подключаешь как обычное внешнее устройство в vmware, из хоста оно «вынимается», а внутри виртуалки работает замечательно.
Правда, я не пользовался готовым образом, а ставил как обычно.
У тебя один опыт, у меня другой. Мнений столько же, сколько программистов. По моем опыту модели имеют один источник (иначе бы это были разные модели). У тебя не так? Сделай по-своему. Много кода это не займет, зато будет работать именно так, как ты хочешь.
Хоть тот же to-do app или его кнопка «view source»:
github.com/ProgerXP/Sqimitive/blob/master/demo/demo.js
Сейчас штатно в assignResp нельзя передать набор других правил (они берутся из _respToOpt), но я думаю добавить во второй аргумент (options) параметр, который будет использоваться вместо _respToOpt самой модели.
В этом случае «assignResp_pusher» может быть алиасом для вызова
assignResp(resp, {map: resp-to-opt}).Это кому как. Мне лично кажется лишним создавать отдельную модель на каждый вид — особенно если там 1-2 флага, которые внутри этого вида только и используются.
А, я понял, что ты изменяешь их собственный код. К компонентам у меня претензий нет. Но у меня был очень яркий опыт одного из первых проектов, где я использовал Backbone. Я расширял и расширял его (Backbone), пока в итоге проект не разросся до 3к строк + еще 4к строк «расширений». Это было неповоротливым и медленным. Конечно, ошибки проектирования/опыта имели значение, но всё равно не решающее. Это не единичный пример.
На мой взгляд, надстройки над библиотекаим наподобие Marionette страдают как раз этим — пытаясь заткнуть дыри изначально отсутствующего функционала они производят на свет намного больше кода, чем это нужно.
Конечно, у каждого свой подход. И я отдаю себе отчёт, что мой — довольно редкий :)
Что касается решений в других фреймворках — я их ищу и изучаю постоянно. Я не бегаю от новых идей.
Не буду спорить, так как CanJS не знаю.
Просмотри ещё раз про state-based programming. Опции — они полезны не только в моделях, более того, они наиболее полезны именно в представлениях. Смотри на мир шире. Не обязательно для каждого чиха создавать свой API.
А если у модели нет ID? Специфичный ID? Как ты реализуешь общую версию этого метода? Придётся его перекрывать в потомках? А как они отреагируют на составной ID (из нескольких полей)?
Зачем вообще обобщённое понятие ID? Его можно избежать, добавив только там, где нужно. Кода на это потребуется минимумально.
Абстракции. Если в твоём проекте/тебе удобно использовать виды, модели и коллекции — наследуй от Sqimitive 3 класса, будут тебе обычные M-C-V. Так я делаю и не вижу в этом каких-либо проблем. Если же у тебя какой-то проект на 1000 строчек, который не будет развиваться — тебе, может, и одного хватит.
Бэкенд это другая тема.
Хорошая библиотека не должна модифицироваться, это на мой взгляд грубое нарушение принципов модульности. Естественно, если делается свой форк — это одно, но отдельный форк на каждый проект? По-моему перебор. Иначе бы не было такого понятия, как плагины (которые я видел в том же CanJS).
И про обновление ты явно хватил. Обновить Knockout с парой-тройкой плагинов? Ты знаешь его настолько хорошо, чтобы лазить в нутрях?
Дело-то в том, что избыточный код не всегда даёт тебе всё, что нужно, и его тоже приходится доделывать. Либо искать, где там разработчики расставили свои капканы и почему твоя логика не согласуется с их. Я особенно сильно это прочувствовал, воюя с Backbone'овским sync.
Это мне близко и я лишь говорил о том, что 1600 с комментариями и 11.5к — это всё же разные степени «когда ты точно знаешь как что работает». Я не уверен, что даже удалив все комментарии ты сможешь разобраться в таком объеме быстрее, чем в Sqimitive. Но, может быть, дополнительная функциональность для тебя более важна, и это нормально. Просто это не мой выбор, я вообще довольно аскетичен в выборе средств и инструментов.
Да, не так. Но, насколько я понял, CanJS это около 6к?
Нет, первый раз слышу. Бегло просмотрел API и код — на первый взгляд кажется того же масштаба, что и Ember. Модули, много кода, разные компоненты. Особенно конструкции вроде таких меня сразу вгоняют в тоску:
Из 11 строк только одна несёт полезную нагрузку.
Sqimitive — это полная противоположность. Здесь ничего нет, всё собирается вами, используя тонко подогнанный и маленький набор универсальных инструментов… А дальше — как глина. Хотите коллекции, модели и виды? Не вопрос, просто наследуйте их (кстати, оба проекта Belstone как раз и используют разделение на M-C-V, потому что это удобно).
Просто я не вижу, зачем разделять их на уровне библиотеки, так как все свойства т.н. моделей (атрибуты), коллекций (фильтрация + вложенность) и представлений могут быть полезны для любого другого типа класса. Не хотите — не используйте вложенность в моделях, это ваше дело.
Больше того, имена методов я специально выбирал не совсем стандартные (можно было назвать add, а не nest) — именно для того, чтобы их можно было перекрыть и назвать в соответствии со стилем в вашем проекте. Нужен getById? Сделайте его, используя доступные методы. Аналогично со всем прочим.
Всё верно, поэтому Sqimitive в серьёзном проекте напрямую не будет использоваться — между ним и приложением будет небольшая (или большая) прослойка-переход в виде тех же M-C-V. Её ведь всё равно приходится делать на том же Backbone. Потому что всегда свой подход хоть в чём-то, но не совпадает с подходом авторов библиотеки.
Важно соблюдать баланс между «преднаписанным» API и временем, которое требуется на его изучение. Можно подумать, что если в Ember почти 50к строк кода, то вам ни строчки не придётся писать самому. Ан-нет, костыли будут точно так же, как и при использовании другой библиотеки. Ещё и грузится дольше будет. (Ну, я утрирую, конечно.)
Короче, из Sqimitive можно сделать основу для любого проекта, имея в её, гм, основе компактный код вместо многотысячных библиотек, которые так и так приходится доделывать. Кому-то такой подход нравится, кому-то нет.
Так вы наследуете не метод, вы перекрываете (с =) или расширяете (в других случаях) цепочку событий. Если у вас в базовом классе уже есть +event, а в потомке — ещё один +event, то в цепочке первым окажется метод (обработчик события) базового класса, после которого пойдёт метод потомка.
Представьте, что когда вызывается
extend()вы блок events берётся и передаётся вNewClass.on({events}). Это и есть наследование в стиле Sqimitive.Напишите в личку подробности.
Sqimitive.Sqimitiveиспользуете единожды, а дальше вы упоминаете его только какApp.MyBaseObjectилиApp.Sqimitive(понятно, что ограничений тут никаких нет).Рад, что тексты понравились.
Правда, я не пользовался готовым образом, а ставил как обычно.