Потребовалось для собственных целей решить следующую задачку — для одной таблички (File) для каждой записи автоматом рассчитывать количество внешних записей, связанных через foreign key. Задача решалась для конкретной структуры таблички File, но при желании решение можно переделать на более универсальное.

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

Основной причиной было то, что количество внешних связей до таблицы File может меняться в процессе разработки и постоянно переделывать запрос было бы просто неразумным. Планировалась некая модульность в самой системе, поэтому точно неизвестны все конечные таблицы.

Недавно на хабре была вот такая статья про мототележку. Почитал, вдохновился, заказал себе и решил написать маленький отчет про эту игрушку после её жмакания.

Осторожно, под катом картинки.

Случилось недавно так, что понадобилось в одном проекте использовать компонент TabControl. Стандартный компонент, ничего необычного, достаточно удобный. Нюанс заключался в том, что нужно было использовать свой тип вкладок на основе перегруженного TabPage. Кроме этого, необходимо было позволить пользователю добавлять вкладки самому в процессе работы. Выглядеть оно должно было примерно так:


Радует, что стандартные компоненты позволяют делать с ними достаточно много извращений.

Недавно начал переводить старый самописный движок с PHP на ASP.NET и столкнулся с несколькими моментами, связанными с шаблонами Smarty и возможностями представлений ASP.NET MVC. Сразу оговорюсь, что подход можно применять и для веб-проектов, но там, возможно, потребуется допилка. Итак.

Во-первых, с самого начала возникла необходимость из шаблона обращаться к методам основного объекта веб-приложения (назовем его Main) — например, конфигурация, менеджер тем, к методам вызывающего контроллера и так далее. Стандартный класс System.Web.Mvc.ViewPage не предоставляет удобного функционала для этого. Конечно, можно добраться до свойства ViewContext.Controller, сделать приведение типа и работать в шаблоне с кодом вида <%=((IndexController)ViewContext.Controller).CurrentTheme.Name%>, но тут возникает вопрос читабельности кода и удобства его написания вообще. Я пошел по пути расширения функционала System.Web.Mvc.ViewPage (а заодно System.Web.Mvc.MasterPage и System.Web.Mvc.UserControl) и добавления в него свойства ControlHelper, которое возвращает объект-помощник, делающий доступными необходимые возможности.

Во-вторых, возникла необходимость в представлениях не задавать прямой путь MasterPageFile, а размечать его дополнительными тегами а-ля «CurrentTheme.SiteMaster», «UserTheme.SiteMaster» и т.п. К сожалению, при записи подобной строки в атрибут MasterPageFile директивы Page я получал ошибку синтаксического анализатора, ругавшегося на отсутствие файла "~/Views/{CurrentTheme.SiteMaster}". Единственное найденное решение — создание своего атрибута для директивы Page, например MasterPagePath:

<%@ Page Language="C#" MasterPagePath="{CurrentTheme.SiteMaster}" Inherits="..." %>