>Или они предлагают сеттер называть setField, нарушив спецификацию java beans?
Опичание JavaBean как раз вроде бы говорит, что название сеттеров/геттеров может быть абстрагировано от названия приватных полей и даже более того: таких приватных полей может и не быть.
Поясняю.
Мне кажется, что запись «makeRe('Artist', '/artist/\d+')», возвращающая новый полноценный класс, менее магична, более проста и понятна, чем «class Artist(MyRe, '/artist/\d+'): pass».
Не вижу никаких проблем для наследования, либо не понимаю вашего вопроса.
Artist = '/artist/\d+'
Song = '/song/\d+'
Album = '/album\d+'
Правда, в данном случае мета-классу MyRe нужно будет озадачиться конвертацией аттрибутов.
Может быть, со мной что-то не так, но мне такой вариант действительно кажется более симпатичным, чем «class Artist(MyRe, '/artist/\d+'): pass».
Ответье всё-таки на вопрос.
В запросе с аргументами ?page=2&truncate_words=20 что именно является пользовательским вводом, непременно требующим обработки во вью, и на основе чего вы делаете такие суждения?
Считайте мой комментарий возражением на заявления о необходимости переработать «40% — 80%» проекта для добавления на страницу элемента, не затрагивающего бизнес-логику.
Передумать — право заказчика. Ваша, как разработчика, задача — заранее позаботиться о простоте последующих изменений. Хотя, конечно, если просят поправить сайт-визитницу из одной страницы, тут и 80% от времени всего проекта может оказаться мало :)
Предлагаю такой вариант:
вешаем по листнеру на события добавления сообщения и их чтение;
по обстоятельствам либо создаем модель для хранения новых данных, либо расширяем модель юзера;
позволяем view самому вытягивать нужные «для дизайна» данные.
В худшем случае тратим час с перекурами. Или я что-то упускаю?
А вы каких мультифункционалов подразумеваете? Если дизайнер-верстальщик, — готов поверить, что у него все хорошо. Если же дизайнер-программист, то в лучшем случае ужасным будет только какое-то одно из направлений, но вероятнее всего плохо будет всё. Исключения бывают, но уж оооочень редко.
Иными словами, нужен веб-дизайнер.
Дизайнер, который не понимает принципов вёрстки и рендеринга, с удовольствием будет выдавать «журнальные» макеты, а верстальщик возненавидит всех и вся.
Я пытался сказать о том, что использование AOP может позволить прозрачно разделить описание бизнес-объектов и таких общих вещей как управление транзакциями. Поверьте, в крупных долгосрочных проектах, где занято несколько разработчиков, а бизнес-объекты хочется переиспользовать между проектами, это очень упрощает жизнь.
При этом, как правило, все настройки этого транзакционного управления собираются в одном файле. И не надо оглядываться на крики в духе «ааа, килобайты иксэмэля, мы все умрём», потому что современние IDE с подсказками и автокомплитом превращают его редактирование в простеишую задачу.
И вы находите такой подход уместным для действительно больших систем (обсуждение ведь с этого началось)?
А можно посмотреть примеры живых проектов, которые построены по такому принципу? Сколько в них задействовано разработчиков и какое у вас соотношение расходуемого времени на багфикс/импрувы/рефакторинг?
Опичание JavaBean как раз вроде бы говорит, что название сеттеров/геттеров может быть абстрагировано от названия приватных полей и даже более того: таких приватных полей может и не быть.
А как у этого чуда с отладкой?
Почти «настоящий» шаблонизатор, с поддержкой include, extend, хелперами и прочими ненужностями.
Неплохо тормозит с включенным фаербагом :)
Artist = makeRe('/artist/\d+')
class RockArtist(Artist): pass
Только зачем? О.о
Мне кажется, что запись «makeRe('Artist', '/artist/\d+')», возвращающая новый полноценный класс, менее магична, более проста и понятна, чем «class Artist(MyRe, '/artist/\d+'): pass».
Не вижу никаких проблем для наследования, либо не понимаю вашего вопроса.
class Music(MyRe):
pattern = '/music'
Artist = '/artist/\d+'
Song = '/song/\d+'
Album = '/album\d+'
Правда, в данном случае мета-классу MyRe нужно будет озадачиться конвертацией аттрибутов.
Может быть, со мной что-то не так, но мне такой вариант действительно кажется более симпатичным, чем «class Artist(MyRe, '/artist/\d+'): pass».
Предлагаю заменить на что-то вроде makeRe('Artist', '/artist/\d+'), которое будет возвращать класс.
Или недостаточно красиво?
Жава-кода — совсем мало.
В запросе с аргументами ?page=2&truncate_words=20 что именно является пользовательским вводом, непременно требующим обработки во вью, и на основе чего вы делаете такие суждения?
Передумать — право заказчика. Ваша, как разработчика, задача — заранее позаботиться о простоте последующих изменений. Хотя, конечно, если просят поправить сайт-визитницу из одной страницы, тут и 80% от времени всего проекта может оказаться мало :)
вешаем по листнеру на события добавления сообщения и их чтение;
по обстоятельствам либо создаем модель для хранения новых данных, либо расширяем модель юзера;
позволяем view самому вытягивать нужные «для дизайна» данные.
В худшем случае тратим час с перекурами. Или я что-то упускаю?
Дизайнер, который не понимает принципов вёрстки и рендеринга, с удовольствием будет выдавать «журнальные» макеты, а верстальщик возненавидит всех и вся.
Я пытался сказать о том, что использование AOP может позволить прозрачно разделить описание бизнес-объектов и таких общих вещей как управление транзакциями. Поверьте, в крупных долгосрочных проектах, где занято несколько разработчиков, а бизнес-объекты хочется переиспользовать между проектами, это очень упрощает жизнь.
При этом, как правило, все настройки этого транзакционного управления собираются в одном файле. И не надо оглядываться на крики в духе «ааа, килобайты иксэмэля, мы все умрём», потому что современние IDE с подсказками и автокомплитом превращают его редактирование в простеишую задачу.
А можно посмотреть примеры живых проектов, которые построены по такому принципу? Сколько в них задействовано разработчиков и какое у вас соотношение расходуемого времени на багфикс/импрувы/рефакторинг?