Комментарии 51
параллели с Yii прослеживаются. Задумка удачная :)
Чем лучше/хуже Экспресса?
И если это ваша разработка, то желаю всяческих успехов!
И если это ваша разработка, то желаю всяческих успехов!
К сожалению, сейчас я не могу сравнить аутодафе с экспрессом по одной простой причине — я не писал на экспрессе сложных приложений, и не имею представления есть ли в нём и как реализована работы с пользователями, базой и тд
Думаю, что когда проблема с документацией аутодафе уйдет, сравнение обязательно появится.
Да, фреймворк пишем я и мой брат. Спасибо.
Думаю, что когда проблема с документацией аутодафе уйдет, сравнение обязательно появится.
Да, фреймворк пишем я и мой брат. Спасибо.
Это дело каждого, но в javascript-е принято переменные писать в стиле camelCase — это почти стандарт). А классы/конструкторы, как раз правильно — UpperCamelCase.
Обычно это называется mixedCase и CamelCase
Да, я знаю. Но где-то полтора года назад я перешел на именование переменных, свойств и методов с подчеркиванием, а для конструкторов оставил UpperCamelCase — мне стало легче читать свой код. А так кода много, я не могу пожертвовать удовольствием в разработке негласным стандартам.
Третья ложка дегтя может некоторым показаться медом. Лично я в Yii пользуюсь DAO. AR немного тяжеловат для сложных запросов.
Выглядит очень даже! Желаю успехов вам и вашему фреймворку!
Вопрос: можно ли прикрутить jade/haml?
Вопрос: можно ли прикрутить jade/haml?
А почему в блоге JavaScript а не Node.js?
или в блоге PHP
Причем тут PHP?
Просто тема без холивара, вот зачаток.
PHP-шный переписанный на node или приближение. Потому что для человека привыкшего к express.js, и вообще js его код и примеры выглядят диковато. Они выглядят как будто они написаны на PHP.
И как только Вы можете увидеть в конфиге приложения и одном классе php…
К php я имею очень мало отношения и последние 5 лет пишу приимущественно на js, поэтому как так получилось я не знаю :( С php фреймворк связывает только полностью переписанная с yii на асинхронный манер dao и ar, а также несколько принципов, которые мне показались логичными.
К php я имею очень мало отношения и последние 5 лет пишу приимущественно на js, поэтому как так получилось я не знаю :( С php фреймворк связывает только полностью переписанная с yii на асинхронный манер dao и ar, а также несколько принципов, которые мне показались логичными.
Ну то, что для Hello World-а нужно писать класс уже символизирует. А так я посмотрел часть исходников и пример блога
Просто иногда решения выглядящие хорошо для миниатюрного приложения не всегда также хороши для больших проектов.
Пара десятков контроллеров наследующихся друг отдруга с кучей действий, больше сотни правил маршрутизации — обычное дело для среднего сайта, в одном месте это не опишешь так, чтобы можно было быстро редактировать. Поэтому аутодафе изначально предлагает масштабируемую архитектуру.
Пара десятков контроллеров наследующихся друг отдруга с кучей действий, больше сотни правил маршрутизации — обычное дело для среднего сайта, в одном месте это не опишешь так, чтобы можно было быстро редактировать. Поэтому аутодафе изначально предлагает масштабируемую архитектуру.
А это плохо? :) Вот глянул и понял, что переписать свои контроллеры на JS будет не сложно, вероятно то же с вьюхами. С моделями затык будет, наверное.
Пожалуй модели — это самое безобидное. Они собирают информацию о всех полях из базы при запуске, так что описать надо только отношения моделей с другими моделями и правила валидации.
Пожалуй модели — это самое безобидное. Они собирают информацию о всех полях из базы при запуске, так что описать надо только отношения моделей с другими моделями и правила валидации.
(промахнулся ответом)
(промахнулся ответом)
Лично у меня модели используют паттерны DataMapper и Repository (в планах ещё UnitOfWork). То есть ни экземпляр модели, ни её класс вообще не знают о том, где они хранятся и хранятся ли вообще — так называемые POPOs — Plain Old PHP Objects — независимые ни от чего, кроме друг друга классы — ни от чего не наследуются, ничего не имплементируют и не содержат ссылок на объекты типа Storage. О хранении знает только контроллер и то на уровне вызова методов Repository — ему отдано на откуп вся логика хранения — хоть в оперативке, хоть вконтакт на стену объекты сериализуй :) ). Удобно, как минимум, для (юнит)тестирования — при тестировании модели (бизнес-логики) вообще о хранении задумываться не надо, при тестировании контроллера нужные объекты модели создаются простым new в самом контроллере и лишь репозиторий мокаем/стабим.
Не промахнулись, это у хабра глюки, отображал ещё минуту назад всё в одном «треде».
Не промахнулись, это у хабра глюки, отображал ещё минуту назад всё в одном «треде».
уже там — не знал о существовании блога и не поискал перед постом, каюсь…
Achievement Unlocked: Собери модули и назови это фреймворком.
В русском языке, как и во многих других, пробелы не ставятся после открывающей и перед закрывающей скобками. В коде так же рекомендую придерживаться какого-нибудь style guide, к примеру: goo.gl/gYHf
Ну и фреймворков в ноде очень не хватает, я знаю лишь о 48-ми: goo.gl/kwTlP
В русском языке, как и во многих других, пробелы не ставятся после открывающей и перед закрывающей скобками. В коде так же рекомендую придерживаться какого-нибудь style guide, к примеру: goo.gl/gYHf
Ну и фреймворков в ноде очень не хватает, я знаю лишь о 48-ми: goo.gl/kwTlP
Согласен, статья не раскрывает уникальные возможности аутодафе. Она предназначена познакомить с существованием фреймворка. Дальше интереснее.
Если подскажите в скольки из этих 48 фреймворков есть orm для mysql поддерживающая отношения, буду Вам крайне благодарен.
> Собери модули и назови это фреймворком
Да, мало фреймворков предостовляют готовый функционал для работы, чтобы не пришлось провести часы за выбором необходимых модулей, коих немало, как Вы упоменули. Аутодафе в каком-то роде делает выбор за тех, кому не хочется тратить свое время.
Спасибо, что рассказали про скобки — никогда не придавал этому значения и не знал этого. Про стайлгид — у фреймворка есть стиль кодирования, но он не описан, и наверно не соблюдается в абсолютно повсеместно. Возможно позже этому будет уделено отдельное внимание.
Если подскажите в скольки из этих 48 фреймворков есть orm для mysql поддерживающая отношения, буду Вам крайне благодарен.
> Собери модули и назови это фреймворком
Да, мало фреймворков предостовляют готовый функционал для работы, чтобы не пришлось провести часы за выбором необходимых модулей, коих немало, как Вы упоменули. Аутодафе в каком-то роде делает выбор за тех, кому не хочется тратить свое время.
Спасибо, что рассказали про скобки — никогда не придавал этому значения и не знал этого. Про стайлгид — у фреймворка есть стиль кодирования, но он не описан, и наверно не соблюдается в абсолютно повсеместно. Возможно позже этому будет уделено отдельное внимание.
>Если подскажите в скольки из этих 48 фреймворков есть orm для mysql поддерживающая отношения, буду Вам крайне благодарен.
Не подскажу; SQL не пользую, как и большинство нодовцев. Если у вас что-то отличное в положительную сторону от других решений, выпустите и продвигайте это отдельным модулем — будет проще и быстрее даст отклик.
Фреймворк это другой уровень и другие требования. Для фреймворка желательна какая-никакая идея, чтобы пользователь представлял во что это может вырасти через год. Авторритет разработчика, потому что объективных критериев оценки и сравнения разных архитектур почти нет. И какие-нибудь гарантии стабильности, желательно звучное имя компании в спонсорах/авторах.
И насчет выбора. Из вашей коллекции с моей совпадает лишь шаблонизатор dust. Прекрасный шаблонизатор, пожалуй, самый производительный из функциональных. Кстати сказать, его использует LinkedIn в своей мобильной платформе, так что на сегодня он используется в самом востребованном нодовском приложении.
Однако, dust в последний раз обновлялся этим летом, хуже того, последний коммит от автора был этим летом. По нодовским меркам это очень давно и я волнуюсь за их судьбу. Было бы прекрасно, если бы люди имеющие столько энергии чтобы собирать фреймворки посвятили себя от части поддержке любимых библиотек. Вот вы даже пишите о том что даст у вас «расширен», почему бы эти «расширения» не отправить обратно в репозиторий даста? Или сделать форк и развивать отдельно.
tl;dr
Есть время/желание — поддерживайте имеющиеся модули и пишите недостающие, «фреймворки» из них сами потом соберутся, если модули будут стоящими.
Не подскажу; SQL не пользую, как и большинство нодовцев. Если у вас что-то отличное в положительную сторону от других решений, выпустите и продвигайте это отдельным модулем — будет проще и быстрее даст отклик.
Фреймворк это другой уровень и другие требования. Для фреймворка желательна какая-никакая идея, чтобы пользователь представлял во что это может вырасти через год. Авторритет разработчика, потому что объективных критериев оценки и сравнения разных архитектур почти нет. И какие-нибудь гарантии стабильности, желательно звучное имя компании в спонсорах/авторах.
И насчет выбора. Из вашей коллекции с моей совпадает лишь шаблонизатор dust. Прекрасный шаблонизатор, пожалуй, самый производительный из функциональных. Кстати сказать, его использует LinkedIn в своей мобильной платформе, так что на сегодня он используется в самом востребованном нодовском приложении.
Однако, dust в последний раз обновлялся этим летом, хуже того, последний коммит от автора был этим летом. По нодовским меркам это очень давно и я волнуюсь за их судьбу. Было бы прекрасно, если бы люди имеющие столько энергии чтобы собирать фреймворки посвятили себя от части поддержке любимых библиотек. Вот вы даже пишите о том что даст у вас «расширен», почему бы эти «расширения» не отправить обратно в репозиторий даста? Или сделать форк и развивать отдельно.
tl;dr
Есть время/желание — поддерживайте имеющиеся модули и пишите недостающие, «фреймворки» из них сами потом соберутся, если модули будут стоящими.
Простите, а что символизирует название?
Когда мне нужно было озаглавить файл с фреймворком, я спросил ближайшего ко мне человека красивое слово. Так что не пытайтесь провести аналогию с сожением на костре или вынесением какого-либо приговора.
Просто один довольно известный капитан (не тот самый) говаривал: «как судно назовёшь, так оно и поплывёт». Хочется надеяться, что работа с фреймворком не даст повода воскликнуть: «так вот что они имели в виду, когда придумывали».
Но вообще удачи в начинании! :)
Но вообще удачи в начинании! :)
Было бы нелишне придумать красивую легенду выбора названия.
Людям нравятся красивые истории, пусть даже и не совсем правдивые.
Людям нравятся красивые истории, пусть даже и не совсем правдивые.
Меня всегда удивляло, зачем в такие фреймворки засовывают «управление пользователями», наверно чтоб потом люди бегали по интернетам спрашивая как это переопределить, чтоб использовать кастомную структуру базы и.т.д.
Всё что нужно это mvc, раутинг, orm, нормальный view engine.
Всё что нужно это mvc, раутинг, orm, нормальный view engine.
Управление пользователями включается только при подключении определенного модуля, и никоем образом не накладывает ограничение на структуру базы данных.
Подробнее в этой статье: goo.gl/dTbgH ( статья в заготовке и может содержать неточности )
Подробнее в этой статье: goo.gl/dTbgH ( статья в заготовке и может содержать неточности )
Управление пользователями частая задача и, как правило, довольно трудоемкая, особенно если нужна не только аутентификация, но и авторизация. Но к счастью, интерфейс этой задачи обычно простой и в нормальных фреймворках так или иначе предусмотрен. Другое дело, что не во всех фреймворках легко сменить реализацию этого интерфейса, особенно «на лету», выбирать её, скажем, в контроллере. Не все авторы, например, обычную аутентификацию с логином и паролем делают практически также как сторонними сервисами, чтоб одну на другую можно было поменять изменением одной строчки.
Почему dust, а не сменный движок шаблонов, ибо я вот пользуюсь Jade.
Мне нравится сходство с yii и не нравится шаблонизатор dust.
Надо как-то сделать чтобы не привязываться к шаблонизатору, но как это сделать я не знаю.
Надо как-то сделать чтобы не привязываться к шаблонизатору, но как это сделать я не знаю.
не знаю как другим, а мне кажется, что если вы хотите популяризировать свой фрейворк — сделайте десятой другой скринкастов под типовые задачи
«очень малая часть задокументирована» — всё, спасибо, не нужно. Фрейморки для того и пишутся, чтобы жизнь программиста была проще, а не сложнее.
Я не стану его использовать только из-за одного названия.
То что многое есть из коробки — это плюс. Желаю успехов в разработке.
Название проекта на французском не самый удачный вариант в айтишном англоязычном мире.
Название проекта на французском не самый удачный вариант в айтишном англоязычном мире.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Autodafé