Pull to refresh
  • by relevance
  • by date
  • by rating

Автоматическая привязка URL к view

Django *
Я недавно «подсел» на Django и мне очень нравится этот фреймворк. Однако есть деталь, которая доставляет беспокойство. Это одновременное редактирование файла с моими views и файла urls.py при создании нового view. Я понимаю, что это связано с тем, что URL-ы и views вещи достаточно разные и для большей модульности лучше держать их раздельно, однако для небольших проектов было бы очень удобно иметь возможность править view и его настройки в одном месте.

Здесь я предлагаю такое решение, конечно же, завязанное на декораторах.

Читать дальше →
Total votes 24: ↑18 and ↓6 +12
Views 1.6K
Comments 12

Работа со сложными декораторами в Zend Framework

Zend Framework *

Введение


Zend Framework — замечательная система. Такое мнение у меня сложилось на протяжение долгого времени тесного «общения» с этой системой. И замечательная она не в силу каких-то сверхвозможностей, предоставляемых программисту, а в силу того, что система эта удивительным образом приглашает программиста к собственному усовершенствованию для его, программиста, блага, предлагая простой и в то же время мощный фундамент для собственных разработок.
Работая над проектом с использованием Zend Framework, решил попытаться по максимуму использовать его возможности и сразу же обратил внимание на компонент Zend_Form (я намеренно называю Zend_Form компонентом, а не классом, поскольку компонент Zend_Form состоит из класса Zend_Form и целого набора сопутствующих классов и интерфейсов). В документации сказано достаточно просто: «Zend_Form упрощает создание форм и управление ими в ваших веб-приложениях». В общем-то это так, но без предварительной подготовки с вас семь потов сойдёт прежде, чем вы сможете создать и отобразить одну более или менее сложную форму. Концептуально форма в Zend Framework состоит из:
  • элементов
  • декораторов
  • фильтров
  • валидаторов
Элементы — это, собственно, то, что мы понимаем под элементами формы: поля ввода, выпадающие списки и пр.
Декоратор — это вся верстка, которая логически связана с элементом формы (окружает его), но не является его частью. Проще говоря, декоратор — оформление элемента формы.
Читать дальше →
Total votes 10: ↑7 and ↓3 +4
Views 3.5K
Comments 19

(Python) Парочка полезных декораторов

Lumber room
import should
  
@should.give((5,2),7)
@should.give(("aa","bbb"),"aabbb")
@should.give(([1],[2,3]), [1,2,3])
@should.give((1,1),1) # test
def add(a,b):
  return a+b
  
@should.throw((1,0), Exception)
@should.throw((5,0), ZeroDivisionError)
@should.throw((5,0), TypeError) # test
@should.throw((5,1), TypeError) # test
def div(a,b):
  return a/b



>pythonw -u "should.py"
[!] add(1, 1) should give 1, but got 2.
[!] div(5, 1) should raise TypeError, but raised nothing.
[!] div(5, 0) should raise TypeError, but raised ZeroDivisionError.
>Exit code: 0


Читать дальше →
Total votes 26: ↑21 and ↓5 +16
Views 308
Comments 15

Паттерн проектирования «Декоратор» / «Decorator»

Perfect code *
Почитать описание других паттернов.

Проблема


Возложить дополнительные обязанности (прозрачные для клиентов) на отдельный объект, а не на класс в целом.

Описание


Для более детального понимания проблемы, рассмотрим конкретную ситуацию. Пусть имеется некоторый объект — «кнопка», принадлежащий классу объектов «Кнопка», на который понадобилось возложить дополнительные обязанности. Под обязанностями, в данном контексте, понимаются какие-либо особенности поведения объекта. В случае с кнопкой, можно рассмотреть поведение объекта при его отображении на экране. При этом, будем считать, дополнительными обязанностями — отображение рамки кнопки, надписи, иконки. Важно понимать, что все эти обязанности должны иметь возможность быть наложенными как одновременно, так и по отдельности. Очевидно, первое, что приходит на ум — порождение классов (механизм наследования). Для данной задачи возможно это и выход — расширить класс «Кнопка» семью (23-1 = 7) различными классами, сочетающими в себе всевозможные комбинации обязанностей. Это классы: «Кнопка_С_Надписью», «Кнопка_С_Рамкой», «Кнопка_С_Иконкой», «Кнопка_С_Надписью_И_Иконкой», «Кнопка_С Рамкой_И_Иконкой», «Кнопка_С_Надписью_И_Рамкой», «Кнопка_С_Надписью_И_Рамкой_И_Иконкой». А если таких обязанностей будет не три, а хотя бы десять, не говоря уже про неудобство работы с подобной структурой. Безусловно, порождение классов в таком случае — заведомо проигрышный вариант. Однако, из этой ситуации есть выход — паттерн «Декоратор».
Читать дальше →
Total votes 57: ↑46 and ↓11 +35
Views 68K
Comments 18

Организация текучих (fluent) интерфейсов в Python

Python *
Вдохновлённый недавним постом про текучие интерфейсы на PHP, я сразу задумался как можно реализовать подобное на питоне проще и красивее (на питоне всегда всё проще и красивее). Предлагаю несколько способов в порядке поступления мыслей.



Читать дальше →
Total votes 63: ↑61 and ↓2 +59
Views 4.1K
Comments 34

JavaScript паттерны… для чайников

JavaScript *
Однажды вечером, сразу после того, как я закончил разбираться с наследованием в JS, мне пришла в голову идея, что пора бы заняться чем-нибудь посложнее — например паттернами. На столе внезапно оказалась книжка Gof, а на экране ноутбука появился труд с названием «JavaScript patterns».

В общем, спустя пару вечеров, у меня появились описания и реализации на JavaScriptе самых основных паттернов — Decorator, Observer, Factory, Mediator, Memoization (не совсем паттерн, а скорее техника, но мне кажется что она прекрасно в этот ряд вписывается) и Singleton.

Читать дальше →
Total votes 118: ↑108 and ↓10 +98
Views 170K
Comments 46

REST-провайдеры на базе Rails: кошмар с вьюхами

Round Lake corporate blog Ruby *Ruby on Rails *
Translation
С развитием браузерных MVC-фреймворков, Rails очень часто стали упоминать в контексте удобного фреймворка для REST-провайдеров. Мы тоже используем Rails для этой цели и достаточно долго. Есть, однако, очень большая проблема: представления. Вьюшки, которые описывают структуру JSON для ответа.

На первый взгляд, все просто отлично. Ничего кроме .to_json или RABL, в некоторых сложных случаях, не требуется. Но затем ситуация выходи из под контроля. И идут бесконечные циклы перебора JSON-билдеров в поисках лучшей жизни.

Проблема


Давайте возьмем для примера банковский сервис. Он состоит из 30 моделей. Каждая модель представлена CRUD-реурсом (в каждом по 3-4 расширяющих метода). В каждой модели 10-12 полей и это обычно длинные строки. И, конечно, все они связаны. Вплоть до 4-5 уровней belongs_to.

При этом важно помнить, что в реальной жизни JSON ответа – это не просто прямой дамп структуры модели. В нем постоянно встречаются условия (какой атрибут должен попасть в ответ? Зависит от другого атрибута) и кастомные методы.

Проблема представлений заключается в том, что клиенту REST-сервиса нужен уникальный набор полей модели для каждой такой модели и _для каждого метода_ этого REST-ресурса. И не забудьте про вложенные сущности.
Что же делать?
Total votes 39: ↑35 and ↓4 +31
Views 7.4K
Comments 40

Понимаем декораторы в Python'e, шаг за шагом. Шаг 1

Website development *Python *
Translation
Tutorial

На Хабре множество раз обсуждалась тема декораторов, однако, на мой взгляд, данная статья (выросшая из одного вопроса на stackoverflow) описывает данную тему наиболее понятно и, что немаловажно, является «пошаговым руководством» по использованию декораторов, позволяющим новичку овладеть этой техникой сразу на достойном уровне.

Итак, что же такое «декоратор»?


Впереди достаточно длинная статья, так что, если кто-то спешит — вот пример того, как работают декораторы:
def makebold(fn):
    def wrapped():
        return "<b>" + fn() + "</b>"
    return wrapped
 
def makeitalic(fn):
    def wrapped():
        return "<i>" + fn() + "</i>"
    return wrapped
 
@makebold
@makeitalic
def hello():
    return "hello habr"
 
print hello() ## выведет <b><i>hello habr</i></b>

Те же из вас, кто готов потратить немного времени, приглашаются прочесть длиииинный пост
Total votes 119: ↑106 and ↓13 +93
Views 324K
Comments 35

Понимаем декораторы в Python'e, шаг за шагом. Шаг 2

Website development *Python *
Translation
Tutorial

И снова доброго времени суток всем читателям!
Спасибо, за проявленый интерес к первой части перевода, надеюсь, вторая вас так же не разочарует.


Итак, в первой части данной статьи мы совершили базовое знакомство с декораторами, принципами их работы и даже написали свой вручную.
Однако, все декораторы, которые мы до этого рассматривали не имели одного очень важного функционала — передачи аргументов декорируемой функции.
Что ж, исправим это недоразумение!
Читать дальше →
Total votes 73: ↑67 and ↓6 +61
Views 169K
Comments 25

Использование фильтра сервлетов для «всплытия» страницы из фрейма

Google App Engine *Google API *
Sandbox
Добрый день!

В одном проекте мне потребовалось сохранять контакты в Google Contacts. Это несложно — надо только авторизоваться через OAuth в Google и получить ключ доступа. Но дело в том, что при этом делается переход на сайт Google, где собственно происходит авторизация и подтверждение доступа приложения к контактным данным. Я же предполагал делать работу с контактом в iframe, а в целях предотвращения clickjacking'а Google не позволяет этого делать. Стало быть, требуется как-то сделать, чтобы страница OAuth открывалась в главном окне, а не во фрейме. Мой вариант решения — под катом.
Читать дальше →
Total votes 3: ↑3 and ↓0 +3
Views 5.2K
Comments 2

«Декораторы проверки» для Views

Django *

Рассуждаем про декораторы


Каждый из нас не раз использовал декоратор login_required и скорее всего писал похожий декоратор(скажем для проверки пустая ли корзина). Давайте рассмотрим что делает данный декоратор:
поговорить про декораторы
Total votes 29: ↑27 and ↓2 +25
Views 7K
Comments 11

Декоратор (Перевод с английского главы «Decorator» из книги «Pro Objective-C Design Patterns for iOS» Carlo Chung)

Development for iOS *Objective C *
Обычно, делая фотографии, вы не задумываетесь, как оформите их потом. Вы фотографируете просто потому, что хотите поймать момент. Скажем, одну из фотографий вы затем распечатали, потом решили поместить в рамку с необычным стеклом. Но позже вы могли бы поместить ту же фотографию в другую рамку, если бы захотели. Даже несмотря на то, что вы изменили рамку, картинка осталась той же, потому что вы просто что-то добавляли к ней, но не изменяли ее при этом.

В объектно-ориентированном программировании заимствовали похожую идею добавления поведения к другим объектам без потери их исходных особенностей, т. е. расширенный объект будет улучшенной версией того же самого класса (фото в рамке). Любое «улучшение» (рамка) может быть наложено и снято динамически. Мы называем этот паттерн проектирования Декоратором, так как декоратор может добавляться к другому декоратору или исходному объекту для расширения его свойств, оставив исходное поведение нетронутым.

Читать дальше →
Total votes 21: ↑17 and ↓4 +13
Views 19K
Comments 2

Управление сложностью в проектах на ruby on rails. Часть 1

Designing and refactoring *Ruby on Rails *
В этой серии статей я соберу бОльшую часть своего опыта разработки на Ruby on Rails. Эти методики позволяют контролировать сложность и облегчают сопровождение проекта. Большинство из них придумал не я, и, по возможности, буду указывать источник.

Основная проблема проектов на RoR в том, что, как правило, всю логику пытаются уместить в модели, контроллеры и представления. Т.е. код находится только в моделях(ActiveRecord::Base), контроллерах, хэлперах и шаблонах. Такой подход приводит к печальным последствиям: код становится запутанным, долго делаются фичи, появляются регрессии, у разработчиков пропадает мотивация. В качестве примера можно посмотреть на исходники redmine.

Выход из данной ситуации довольно-таки очевидный. Будем делать проекты не на ruby on rails, а с использованием ruby on rails. Как это будет выглядеть: мы никуда не уходим от MVC и Rails, просто пересмотрим Model, View, Controller. Для начала расширим понятие модели. Модель — это не просто класс-наследник ORM. Модель — это вся бизнес логика приложения. Модель включает в себя: модели, сервисы, политики, репозитории, формы и другие элементы, которые я опишу далее. Так же расширим представления. Представления — это шаблоны, презентеры, хелперы, билдеры форм. Контроллеры — это все то, что связано с обработкой запросов: контроллеры, responders.
Читать дальше →
Total votes 22: ↑16 and ↓6 +10
Views 19K
Comments 17

Построение модульной архитектуры приложения на Forwarding-декораторах (авторский перевод)

PHP *Programming *System Analysis and Design *
Sandbox
Когда разработчик планирует архитектуру своего будущего веб-приложения, полезно подумать о его расширяемости заранее. Модульная архитектура приложения может обеспечить хорошую степень расширяемости. Существует довольно много способов, как такую архитектуру реализовать, но все они сходны в своих фундаментальных принципах: разделение понятий, самодостаточность, взаимная сочетаемость всех компонентов.

Однако есть один подход, который именно в PHP можно встретить довольно редко. Он включает использование нативного наследования и позволяет патчить код «более лучше»(с). Мы называем этот способ “Forwarding Decorator”. Нам он представляется достаточно эффективным, и, кстати, эффектным тоже, хотя последнее не так важно в продакшене.

Как автор оригинальной англоязычной статьи "Achieving Modular Architecture with Forwarding Decorators", опубликованной на SitePoint, я представляю вам авторскую версию перевода.
Читать дальше →
Total votes 15: ↑15 and ↓0 +15
Views 9.7K
Comments 12

О декораторах, сквозной функциональности, CQRS и слоеной архитектуре

Website development *.NET *Designing and refactoring *C# *
Разработчик SimpleInjector очень любит «декораторы», особенно в сочетании с дженериками вида
QueryHandler<TIn, TOut>, CommandHanler<TIn, TOut>.

Такой подход позволяет «навешивать» на обработчики то, что принято называть cross-cutting concerns без регистрации и смс interception и особой уличной магии вроде Fody или PostSharp.

CQRS не top level architecture, поэтому хочется иметь такие-же декораторы и для классических Application Service. Под катом я расскажу как это сделать.
Читать дальше →
Total votes 12: ↑11 and ↓1 +10
Views 16K
Comments 21

О декораторах в Python

OTUS corporate blog Python *
Translation

Всем привет!


Перевод статьи подготовлен для студентов курса «Web-разработчик на Python». Интересно развиваться в данном направлении? Запишитесь на День Открытых Дверей курса и пообщайтесь вживую с преподавателем: онлайн-трансляция 23 июля в 20:00 по мск.!



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

Читать дальше →
Total votes 32: ↑22 and ↓10 +12
Views 14K
Comments 5

Принцип DRY на примере Laravel

PHP *Programming *Designing and refactoring *Laravel *
Tutorial
Рассмотрим простой модуль, отвечающий за добавление новых пользователей.

И на его примере увидим, какие возможности открывает применение принципа DRY.

Для меня принцип DRY (Don't Repeat Yourself) всегда воплощался в двух основных определениях:

  1. Дублирование знаний — всегда нарушение принципа
  2. Дублирование кода — не всегда нарушение принципа

Начнем с контроллеров содержащих минимальное количество логики.
Читать дальше →
Total votes 12: ↑11 and ↓1 +10
Views 6.5K
Comments 20

Могучие Typescript Декораторы — как работают, во что компилируются и для каких прикладных задач применимы

TypeScript *

Каждый Ангуляр разработчик видел декораторы в тайпскрипт коде. Их используют, чтобы описать Модули, сконфигурировать Dependency Injection или настроить компонент. Другими словами, декораторы используются, чтобы описать дополнительную информацию, или метаданные, для фреймворка или компилятора (в случае Ангуляра). При чем, Ангуляр лишь один из примеров. Существуют многие другие библиотеки, использующие декораторы для простоты и наглядности кода, как декларативный подход. Как .NET разработчик в прошлом, я вижу много сходства между TS декораторами и .NET аттрибутами. Наконец, набирающий популярность NestJS фреймворк для бекенд приложений (абстракция над Node), также построен на интенсивном использовании декораторов и декларативном подходе. Как это все работает и каким образом использовать декораторы в своем коде, чтобы он был более удобным и читабельным? Мы все понимаем, что после компиляции TS кода мы получаем Javascript код. В котором нет понятия декоратор, как и многих других Typescript особенностей. Поэтому для меня наиболее интересным является вопрос, во что превращается декоратор после компиляции. Занимаясь этим вопросом, я сделал выступление на митапе в Минске и хочу поделиться статьей.


Читать дальше →
Total votes 19: ↑19 and ↓0 +19
Views 14K
Comments 33

Кастомные декораторы для NestJS: от простого к сложному

QIWI corporate blog Node.JS *TypeScript *

image


Введение


NestJS — стремительно набирающий популярность фрeймворк, построенный на идеях IoC/DI, модульного дизайна и декораторов. Благодаря последним, Nest имеет лаконичный и выразительный синтаксис, что повышает удобство разработки.


Декораторы или аннотации — наследники аспектов, которые позволяют декларативно описывать логику, модифицировать поведение классов, их свойств, аргументов и методов.


Технически декораторы — это просто функции, но их вызовом полностью управляет компилятор.
Важная особенность заключается в том, что в зависимости от контекста, сигнатуры аргументов будут различаться. Материалов на эту тему существует довольно много, однако мы сосредоточимся на специфике, связанной непосредственно с Nest.

Читать дальше →
Total votes 29: ↑29 and ↓0 +29
Views 6.5K
Comments 4

Декларативный подход в Angular

TINKOFF corporate blog Website development *JavaScript *Angular *TypeScript *

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

Если говорить кратко, в compliant-механизме для обеспечения его технических характеристик используют деформацию. В то время как в традиционной технике (rigid body) гибкость зачастую является негативным качеством материала, сompliant-механизмы используют ее для передачи силы и движения в нужном направлении, вместо соединений из нескольких подвижных деталей.

Узнать, к чему это я
Total votes 35: ↑35 and ↓0 +35
Views 7.4K
Comments 5
1