LiquidLava MVC Framework

[kogarashisan]

Давайте по порядку.

Про велосипеды

Моя разработка делается по системе. Сперва я составляю документы, в которых расписаны сценарии: что должен делать фреймворк, и как именно. Потом на основе этих документов я составляю требования. Потом уже на основе требований делаю проэктирование. И только потом пишу код. Но фреймворк это действительно нереально сложная штука, поэтому с первого раза у меня не получился ни один слой.

Слой Scope + виды - я переписал раз 10 почти с нуля. И еще несколько раз частично. Причем был такой момент, когда я сказал "ну все, наконец то готово!". А потом достал маленькое требование из бэклога... "ё моё, опять все переделывать". Примерно после 7 раза.

Refresher - 3 раза с нуля
Шаблонизаторы - 3 раза с нуля
Data - 1 раз полностью, и много раз по кусочку
mixin.Observable - 1 раз полностью
Анимация - примерно раза 3...

Еще бывало за один рефакторинг я заменял штук 500 использований какой-то функции по всему коду. Так что у меня серьезная система, выбранная осознанно.

Насчет стиля кода

Локальные переменные у меня именуются через подчеркивание, даже если там лежит функция:

var my_cool_function, my_cool_variable

Но функция из API класса никогда не будет названа my_cool_function, правильно myCoolFunction.

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

Но примеры, которые привел fancy - они не все из моего кода.
Например, если у меня действительно есть что-то вот такое, то это нужно исправить:

if(n)
   a = 5;

В моем коде есть такие штуки, но в одну строку - в основном DEBUG проверки. Если к ним добавить скобки и разнести на 3 - то код становится практически нечитаемым, пробовал.

У меня всегда один var на функцию. Исключение - пример todo_app - им так нравится, и это их правила. Есть хорошая причина использовать один var на функцию - variable hoisting.
http://designpepper.com/blog/drips/v...ction-hoisting
Помогает избежать ошибок.

Приватные методы

Приватный метод - это не тот метод, который используется внутри фреймворка. Приватный метод - это метод, который нельзя вызывать извне. Тут у меня закралось подозрение, что вы, fancy, никогда не программировали на C++...

Если во фреймворке есть код, который используется только внутри фреймворка - то это мусорный код. У меня весь код - для программиста. Все методы в моих классах, даже приватные - можно переопределить (во всем фреймворке есть всего 3 исключения, которые нужно будет пометить как final, когда добавлю поддержку в ClassManager).

Надеюсь, правильно понял.

Насчет MooTools - мне тоже не нравится что он расширяет прототипы глобальных объектов.
Поэтому у меня есть Firestorm. Со временем я буду переписывать MooTools и переносить его функциональность в Firestorm, и там будет все как вы и написали. Когда тесты будут.

Про жесть

this.Text$broadcastInDOM();

О, это вызов родительского метода. Так работает моя система классов. И благодаря этому она такая быстрая. Предлагаю разобраться по учебникам. Если будут предложения получше, когда разберетесь - пишите.

var element = this._input_container.getDOMElement();

Тут все в полном порядке. "_input_container" - приватная переменная, getDOMElement - публичная функция. Все вместе - часть красивой и гибкой Системы. Что с этим не так?

API у меня - произведение искусства. Но не современного, в котором каждая мусорка это искусство, а старого. Когда люди еще читали книги про рефакторинг, паттерны, и шарили C++.

"пробуй себя в js в Москве"
Думаю, еще успею. И я уже давно не студент.
Кстати, mail.ru и Яндекс - это фактически иностранные фирмы на российском рынке.

[nerv_]

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

А у меня нет PHP движка и мне твой стиль буэээ К сожалению, люди приходят в js и не могут понять, что там другой стиль кода и продолжают бомбить в своем.

Я не против - пиши сколько угодно для себя. Но, если ты хочешь, чтобы твой код использовали другие, будь любезен camelCase.

[Safort]

kogarashisan,

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

Просто в js-сообществе так принято.

[fancy]

А у меня нет PHP движка и мне твой стиль буэээ К сожалению, люди приходят в js и не могут понять, что там другой стиль кода и продолжают бомбить в своем.

Я не против - пиши сколько угодно для себя. Но, если ты хочешь, чтобы твой код использовали другие, будь любезен camelCase.

kogarashisan,

Просто в js-сообществе так принято.

+1

Хочешь чтобы начали пользоваться люди, пиши в js стиле, а не в PHP или perl.

Единственное что крутое в твоем проекте, это сам факт, что ты делаешь аналог Angular.
Начни с нормального API, а уж потом можешь говорить что у тебя что-то супер мега классное

Мне очень нравится MooTools, но я не пользуюсь им именно из-за 2 ньюасов в API.

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

[kogarashisan]

Вы услышаны. Я подумаю, что с этим делать.

Начни с нормального API, а уж потом можешь говорить что у тебя что-то супер мега классное

Главное что в функциональном плане с ним все в порядке.

Единственное что крутое в твоем проекте, это сам факт, что ты делаешь аналог Angular.

"единственное"? и не просто "аналог", а лучший аналог.

[fancy]

Приватный метод - это не тот метод, который используется внутри фреймворка. Приватный метод - это метод, который нельзя вызывать извне. Тут у меня закралось подозрение, что вы, fancy, никогда не программировали на C++...

API у меня - произведение искусства. Но не современного, в котором каждая мусорка это искусство, а старого. Когда люди еще читали книги про рефакторинг, паттерны, и шарили C++.

В далеком прошлом, 2 года использовал C++.
Знал очень многое про него.
Сейчас немогу уже вспомнить элементарные вещи из него.
Это как с иностранным языком, не изучаешь забываешь так как будто и не учил.

Паттерны и шаблоны проектирования изучал очень серьезно.
Скажу дилетантский языком.
Для RIA - достаточно классов, ClassManager по типу виджетов и задач, Observe, Template - вроде все... непомню, чтобы еще какие то особо пригодились.
А еще для данных, простым языком MVC.
Но я пользуюсь свои модифировнным вариантом MVC.
Короче просто модели и все)) и без всей мути с контролемами и view.
Долго описывать как это ))
А так можно и Adapter и proxy еще использовать.
Я не готовился выступать про Design Patterns на конференции
Чтобы дать аккадемический ответ, надо дня 3 все повторить.
Паттернов штук 200, только нужны из них максимум 5-7.
Чем проще тем лучше.
Вон C11 Standart в 1500 страниц, даже из профи мало кто читал.

Поищу про _, с терминами и т.д., чтобы не звучало по дилетантски.

[melky]

Короче просто модели и все)) и без всей мути с контролемами и view.

flux, russian edition

[fancy]

Опять сумбур. Но нет времени делать классный анализ и выкладки.

Поищу про _, с терминами и т.д., чтобы не звучало по дилетантски.

Просмотрел несколько книг, никак найти не могу.
Толи в книге Мука по ActionScript видел, то ли в Definite JavaScript Guide 6.

Придется дилетантски опять объяснять и повторить то что писал.
Если есть кто помнит исправьте.
Вроде именно private методы принято начинать с _.
Т.е. этот метод точно не будет для API.
Но я таким подходом не пользуюсь.
даже private методы у меня идут без _.
А у вас, как было ранее сказано методы для API c _.

Отдельно стоит сказать про использование $ в методах и переменных.
Тоже советую этим пользоваться, в самом крайнем случае.
У меня это используется только в этом месте.
Для классов, для внутреннего именования класса.
Т.е. предположим класс называется, напишу в стиле MooTools, как оно должно быть, а не как сейчас.

Mt.Class('Mt.Panel', {
   extend: Mt.Event/Mt.Observe, либо 'Mt.Event'

Так вот внутри класса у меня идет определение названия класса
$class: 'Mt.Panel'


Теперь еще раз про слишком длинные названия методов.

var element = this._input_container.getDOMElement();

Можно ввести внутри фреймворка список кратких названий переменных.
Итог, делаем красиво

var el = this.inputEl;

слишком красиво...

Надо сокращять длинные названия. Не все.
Но уж совсем элементарные вроде
this.getElement()
делаем хотя бы
this.getEl()
Это настолько очевидно и просто, что El - это Element


Еще один момент, уж думайте сами нужно вам или нет
Я пользуюсь
Ссылка на this.
Сейчас если и пользуются такой ссылкой то через "self'

var self = this;

   self.show();

Я вместо self, использую me.
Не помню уже где первый раз это встретил.
Но это делает код мега красивым и удобным.

var me = this;

   me.show();

Еще один плюс таких ссылок, особенно для ООП библиотек, которые
в методе раз 5 - 20 обращаются к друг методам или свойствам -
сокращение код.

Все способы которые есть для уменьшения код, я использую - делает на ~30% код меньше ...
Т.е. весит проект minified до такой оптимизации 300кб, а после оптимизации 210-250$
Для меня это было критично.

[fancy]

flux, russian edition

Не думаю.
Этот flux все равно слишком многое делает сложно.
Скорее у меня более красивый подход внутренней RIA либы
на которой вконтакт работает.
При желание можете покопаться как у них там что)))

Только у меня все в разы красивей ))
И я не пользуюсь require как они, нет необходимости.
хотя им без require никак.

У них вместо шаблонизации, как то так

.innerHTML = '<div class="class-name">' +
myVar +
....;

Вот и вам и ответ на виртуализацию DOM, которая в React.


Про React хочу сказать.
То что они преподносят как прорыв, не факт что таковым является да круто... Но на деле, полный rerender редко когда нужен.
И никто не будет каждые 1-5 секунд делать rerender 5000 + строк для table например.
Не знаю на чем работает facebook, какая js либа, но vk гораздо быстрей за счет клиентского рендеринга и кучи фишек.
У них вообще очень много классно сделано.
Помню у меня была своя fx либа - css3 не решает до сих пор всех моментов, приходится иметь свое решение.
Так вот, у них fx сделано так красиво и просто.
не ожидал такого решения.
Молодцы.

Иногда чувствую себя внештатным сотрудником контакта )))
Я их код вдоль и поперек изучил))
Некоторые моменты исправил бы, но все равно их код классный...
На их внутренней либе можно делать полноценный продукт, который может стать лучше всех современных JS UI фреймворков.

[fancy]

Еще про React
Уж раз про него заговорили

Минус первый.
Это тоже самое что CoffeeScript только не в стиле ruby и только ради того чтобы писать вот это

React.render(<MarkdownEditor />, mountNode);

render: function() {
    return (
      <div className="MarkdownEditor">
        <h3>Input</h3>
        <textarea
          onChange={this.handleChange}
          ref="textarea"
          defaultValue={this.state.value} />
        <h3>Output</h3>
        <div
          className="content"
          dangerouslySetInnerHTML={{
            __html: converter.makeHtml(this.state.value)
          }}
        />
      </div>
    );
  }

Ладно может так надо было, но идем дальше.
Во что они превращают это

Минус два

render: function() {
    return (
      React.createElement("div", null, 
        React.createElement("h3", null, "TODO"), 
        React.createElement(TodoList, {items: this.state.items}), 
        React.createElement("form", {onSubmit: this.handleSubmit}, 
          React.createElement("input", {onChange: this.onChange, value: this.state.text}), 
          React.createElement("button", null, 'Add #' + (this.state.items.length + 1))
        )
      )
    );
  }

Это ж получается для каждого тега надо вызвать функцию, и думаю не маленькую.
Повторю их заявление, что типа мы берем и просто все перерендерим.
Что это значит?
Это значит что еще надо заново поставить обработчики событий на dom.

И где тут прорыв в производительности?
Они такой гемор*** делают из очень простой задачи.