что такое код бихайнд
Сервелат, анимация и старый добрый code-behind
Решил немножко покопаться в Silverlight, да смастерить на нём что-нибудь прикольное. Это прикольное, конечно, должно шевелиться, переливаться и плавно подёргиваться, ибо вебдваноль у нас или где? :). И вот тут мне пришлось столкнуться с неплохой, по сути, системой анимаций в WPF/Silverlight. Покурив MSDN, я бодренько приступил к написанию анимаций в XAML. Одну написал, вторую, третью… А потом мне захотелось сделать так, чтобы они шли в определённой последовательности. И вот тут-то я и понял, что XAML, зараза, очень избыточный. Для описания интерфейсов он подходит идеально: сразу видно, что к чему относится и надобность в визуальном редакторе отпадает чуть менее, чем полностью. Но вот когда пытаешься написать в этом XAMLе какую-то логику, начинает проявляться вся его несуразность. Покурив гугл, я был сильно удивлён тем, что большинство людей упорно пытаются впихнуть в XAML абсолютно всё. Ругаются, путаются в коде, плачут, но продолжают писать. Прямо как те мыши с кактусом, чесслово. И тут мне пришла идея аккуратно описать анимации обычным кодом на C#. Мы, так сказать, олдфаги, рисовали интерфейс прямыми вызовами к WinAPI, неужто нас какие-то анимации испугают? 🙂
В результате получился вот такой портабельный класс AnimationBag. Портабельный он потому, что его безо всяких изменений можно использовать как в WPF, так и в Silverlight.
Как видно из кода, класс предельно простой. Вот пример использования.
Сам класс представляет собой что-то вроде словаря с ключами — именами анимаций и значениями — анимациями. В методе InitAnimations в коллекцию добавляются две анимации, при этом указывается имя, контрол, над которым будет производится действо, свойство этого контрола и сам объект анимации. Его можно создавать ручками, а можно добавить статические хэлперы к уже имеющемуся методу для DoubleAnimation. Кроме всего прочего, метод AddAnimation может принимать два делегата, которые будут выполняться до и после самой анимации. Например, здесь после завершения анимации “fadeOut” сразу запускается “fadeIn”.
В итоге, получился довольно удобный механизм, позволяющий описывать анимации одной строкой кода вместо килобайтов перегруженного XAML.
Код программной части и XAML в WPF
Этот раздел состоит из следующих подразделов.
Предварительные требования
В этом разделе предполагается, что вы читали XAML в WPF и имеете некоторые базовые знания о среде CLR и объектно-ориентированном программировании.
Code-Behind и язык XAML
Язык XAML включает функции уровня языка, позволяющие связывать файлы кода с файлами разметки с стороны файла разметки. В частности, язык XAML определяет директивуLanguage Features X:Class, директиву x:Subclassи директиву КС:классмодифиер. Точно то, как должен быть создан код и как интегрировать разметку и код, не является частью того, что указывает язык XAML. Она остается в таких платформах, как WPF, для определения способа интеграции кода, использования XAML в моделях приложения и программирования, а также действий сборки или другой поддержки, которые требуются для всех этих платформ.
Код программной части, обработчик событий и требования к разделяемому классу в WPF
Разделяемый класс должен быть производным от типа, который является резервным для корневого элемента.
Обратите внимание на то, что при поведении действия сборки компиляции разметки по умолчанию можно оставить пустое производные в определении разделяемого класса на стороне кода программной части. Скомпилированный результат предполагает, что резервный тип корня страницы будет базисом для разделяемого класса, даже если он не указан. Однако использовать такое поведение не рекомендуется.
Обработчик должен соответствовать делегату для соответствующего события в системе резервных типов.
x:Code
Ограничения встроенного кода
Рекомендуется избегать или ограничивать использование встроенного кода. С точки зрения архитектуры и философии программирования, обеспечение разделения между разметкой и кодом программной части обеспечивает гораздо более отличающиеся роли конструктора и разработчика. На более техническом уровне код, написанный для встроенного кода, может быть неудобным для записи, так как вы всегда пишете в XAML созданный разделяемый класс и можете использовать только сопоставления пространства имен XML по умолчанию. Поскольку нельзя добавлять using инструкции, необходимо полностью определить множество вызовов API. Сопоставления по умолчанию WPF включают большинство, но не все пространства имен CLR, которые есть в WPF сборках. вам придется полностью квалифицировать вызовы типов и членов, содержащихся в других пространствах имен CLR. Кроме того, нельзя определить что-либо за пределами разделяемого класса во встроенном коде, и все сущности кода пользователя, на которые вы ссылаетесь, должны существовать в виде члена или переменной в созданном разделяемом классе. Некоторые функции программирования, такие как макросы или #ifdef глобальные переменные или переменные сборки, также недоступны. Дополнительные сведения см. в разделе Тип данных, встроенный в x:Code.
Как перевести фразу «code-behind» на русский?
Сабж. Всю голову сломал;).
Для справки: при использовании технологий ASP.NET, WPF, Silverlight, части кода, которые отвечает за UI и логику обработки событий от UI разделяются. Вот, эти самые файлы, которые содержат логику обработки событий и называются code-behind.
Кто знает как нормально и понятно перевести фразу code-behind на русский язык?
В избранное В избранном 0
15 комментариев
Есть еще много хороших специализированных словарей на www.lingvodics.com/ но там их надо выменивать у хозяина.
ASP.NET Web Page Code Model
An ASP.NET Web page consists of two parts:
blah blah blah
ASP.NET provides two models for managing the visual elements and code — the single-file page model and the code-behind page model. The two models function the same, and you can use the same controls and code for both models.
Модель кода веб-страниц ASP.NET
Веб-страница ASP.NET состоит из двух частей:
бла бла бла
В ASP.NET реализовано две модели управления визуальными элементами и кодом: однофайловая модель страницы и модель страницы с выделенным кодом. Обе модели работают одинаково, и в них обеих используются одни и те же элементы управления и код.
2. Результаты 1 — 10 из примерно 465 000 для выделенный код. (0, 24 секунд)
Модель кода в Visual Studio
Пока что мы рассказали только о том, как проектируются простые веб-страницы, и из каких частей состоит интерфейс Visual Studio. Но прежде чем приступать к серьезному кодированию, нужно обязательно разобраться в некоторых базовых деталях модели кода ASP.NET. Поэтому в данной статье речь пойдет о доступных вариантах использования кода для программирования веб-страниц и том, как события ASP.NET привязываются к коду.
Visual Studio поддерживает две модели для кодирования веб-страниц:
Внутритекстовый код
Эта модель удобна, поскольку позволяет хранить все в одном месте безо всяких излишеств и потому часто применяется для кодирования простых веб-страниц.
Отделенный код (code-behind)
Эта модель подразумевает создание для каждой веб-страницы ASP.NET двух файлов: файла разметки (.aspx) с дескрипторами HTML и дескрипторами элементов управления, и файла кода (.cs) с исходным кодом страницы (при условии, что для программирования веб-страницы применяется язык C#). Такая модель обеспечивает более удобную схему организации, позволяя отделять пользовательский интерфейс от программной логики, что очень важно при создании сложных страниц.
Чтобы лучше понять, в чем состоит разница между моделями внутритекстового и отделенного кода, не помешает рассмотреть какую-нибудь простую страницу. В следующем примере показан код разметки для страницы по имени WebForm1.aspx, который отображает текущее время в текстовой метке и обновляет страницу всякий раз, когда в ней выполняется щелчок на кнопке. В случае использования модели внутритекстового кода эта страница будет выглядеть следующим образом:
Приведенные ниже коды файлов WebForm1.aspx и WebForm1.aspx.cs демонстрируют, как эта же страница будет поделена на две части в случае использования модели отделенного кода:
Единственное реальное отличие между примером с внутритекстовым кодом и примером с отделенным кодом состоит в том, что в последнем случае класс страницы больше не является неявным, а наоборот — объявляется как класс, содержащий все методы страницы.
В целом, модель отделенного кода предпочтительнее использовать для сложных страниц. Хотя модель внутритекстового кода является немного более компактной для небольших страниц, с увеличением объема кода и HTML-разметки с ними становится гораздо проще иметь дело по отдельности. Вдобавок модель отделенного кода является более чистой с концептуальной точки зрения, поскольку явно отображает созданный класс и импортированные пространства имен. И, наконец, она также еще позволяет веб-дизайнеру улучшать разметку страниц, не затрагивая код, написанный разработчиком.
Связывание файлов отделенного кода со страницами
Определять местонахождение связанного кода можно несколькими способами. В более старых версиях ASP.NET было распространено использование атрибута Src для указания на исходный код либо атрибута Inherits для указания на имя скомпилированного класса. Однако обе эти возможности имеют свои индивидуальные особенности.
Например, с помощью атрибута Inherits вы должны предварительно компилировать код, что довольно-таки утомительно (и может вызвать проблемы в командах разработчиков, поскольку стандартной возможностью является компиляция каждой страницы в отдельную DLL-библиотеку сборки). Но реальная проблема состоит в том, что оба подхода вынуждают объявлять каждый веб-элемент управления, который вы собираетесь использовать, с помощью переменной экземпляра. В результате получается большой объем стереотипного кода.
Связывание дескрипторов элементов управления с переменными страниц
При запросе веб-страницы в окне браузера ASP.NET сначала отыскивает связанный с ней файл кода, а затем генерирует объявление переменной для каждого присутствующего в ней серверного элемента управления (т.е. для каждого элемента, у которого имеется атрибут runat=»server»).
Например, предположим, что есть текстовое поле по имени txtInput:
ASP.NET сгенерирует для него следующее объявление переменной экземпляра и объединит его с классом страницы с помощью «волшебного» механизма частичных классов:
Кстати, вы заметите, что переменные элементов управления всегда объявляются с помощью ключевого слова protected (обозначающего защищенный доступ). Все дело в способе, которым ASP.NET использует наследование в модели веб-страниц. Существуют следующие уровни:
Ваш класс отделенного кода (например, WebForm1) наследуется от класса Page, чтобы получить этот базовый набор функциональных возможностей веб-страницы ASP.NET.
Когда вы компилируете свой класс, ASP.NET добавляет в него кое-какой дополнительный код (с помощью «волшебного» механизма частичных классов). В этом генерируемом автоматически коде все имеющиеся на странице элементы управления определяются как защищенные переменные, чтобы можно было получать к ним доступ в коде.
Связывание событий с обработчиками событий
Большая часть кода страницы ASP.NET помещается внутрь обработчиков событий, реагирующих на события веб-элементов управления. С помощью Visual Studio добавить в код обработчик событий можно одним из трех способов:
Ввести его вручную. В этом случае метод добавляется непосредственно в класс страницы. Необходимо указать соответствующие параметры, чтобы сигнатура обработчика событий в точности соответствовала сигнатуре события, которое вы собираетесь обрабатывать. Также понадобится отредактировать дескриптор элемента управления, чтобы он связывал элемент управления с соответствующим обработчиком событий, добавив атрибут OnИмя_события.
Дважды щелкнуть на элементе управления в представлении визуального конструктора. В этом случае Visual Studio создаст обработчик события по умолчанию для этого элемента управления (и соответствующим образом настроит дескриптор элемента управления). Например, двойной щелчок на странице приводит к созданию обработчика события Page.Load, а двойной щелчок на кнопке — обработчика события Click.
Выбрать событие в окне Properties. Выделите элемент управления и щелкните на кнопке с изображением молнии в окне Properties. Вы увидите список всех событий, предоставляемых этим элементом управления. Дважды щелкните на поле рядом с событием, которое собираетесь обработать, и Visual Studio автоматически сгенерирует обработчик события в классе страницы и настроит дескриптор элемента управления:
Второй и третий способы наиболее удобны. С другой стороны, третий способ самый гибкий, поскольку позволяет выбрать уже созданный ранее метод в классе страниц. Просто выберите событие в окне Properties и щелкните на стрелке раскрывающегося списка справа. Вы увидите список методов класса, которые соответствуют сигнатуре, ожидаемой этим событием. Затем в списке можно выбрать метод для его подключения, как показано на рисунке выше.
В Visual Studio используется автоматическое образование цепочек событий, как показывает директива Page. Автоматическое образование цепочек событий основано на двух базовых принципах:
Все обработчики событий страницы подключаются автоматически на основании имени обработчика событий. Другими словами, метод Page_Load() автоматически вызывается во время загрузки страницы.
Все обработчики событий элемента управления подключаются с использованием атрибутов в дескрипторе элемента управления. Атрибут носит то же имя, что и событие, но имеет префикс On.
Например, если вы собираетесь обработать событие Click элемента управления Button, необходимо лишь установить атрибут OnClick в дескрипторе элемента управления с именем обработчика событий, который вы собираетесь использовать.
Этот подход служит для создания элементов управления «на лету».
Индусский код в Микрочипе
Те кто общался с саппортом микрочипа, наверное замечал что зачастую попадает на индийский департамент конторы, и все-бы ничего если бы не подозрение что весь микрочип разом переехал в Бомбей и набрал индийских бездомных школьников для написания своих библиотек.
Не подумайте, что я сейчас пытаюсь гнуть расово верную линию — не имел опыта общения конкретно с индусами, но точно знаю что среди наших их тоже достаточно (не верите — наберите «95» в гугле), но понятие «индусского кода» появилось давно и закрепилось довольно прочно, хотя вы и не найдете его в политкорректной википедии (но гугол о нем точно знает).
Индусский код (не индийский или индейский) — жаргонное нарицательное название для программного кода крайне низкого качества, использующего простые, но порочные принципы «copy-paste».
Почему именно индусский?
По слухам в Индии с некоторых времен существует практика оценки производительности труда программиста на основе количества написанного кода. Чем больше кода, тем больше программист работает, и, следовательно, выше его оклад. Шустрые индусы быстро сообразили, как обманывать неквалифицированных заказчиков.
Полезное замечание от kaladhara
Житель Индии — индиец, а индус — это последователь любого направления индуизма. Таким образом даже чукча преклонных годов, исповедующий шиваизм (и, вероятно пишуший на с++) — индус.
0. Больше кода — больше профит!
Самое важное, что надо запомнить нанимаясь получив работу в микрочипе: «Они-таки платят за строки кода!». Поэтому любыми способами увеличивайте объемы исходных текстов. Совет общий, так что без примеров, включайте фантазию.
1. Классика жанра
Классика жанра индусского кино кода незыблема со времен его появления, для разминки попробуйте угадать что скрывается за этим куском кода, содержащемся в файле «MDD File System\SD-SPI.c» на строчке 1042:
2. Копипаст
В отсутствии фантазии подойдет и копи-пейст, хотя по слухам многие работодатели проверяют код на копипаст, микрочип видимо не из их числа. Запомните, для срубания бабла индусским кодом никогда не используйте макросы — они зло и безобразно уменьшают код. В пример кусок, повторяющийся раз двадцать в файле «MDD File System\FSIO.c»:
Соотношение 10:1 в пользу первого варианта, а с учетом двадцатикратного повторения в абсолютных величинах это несколько сот рупий!
3. Линейный код
Использование циклов — зло. Линейная программа работает значительно быстрее, не тратя времени на операторы условий и переходы, и содержит больше строк кода.
Инициализация структур должна быть побайтной, не надо писать простые инициализаторы типа:
4. Изобретаем велосипед или деньги из пробелов
На очередную мысль меня навела идея функции FileObjectCopy в файле «MDD File System\FSIO.c» на строчке 6065, подозреваю что если бы у них было больше разных структур то появились бы и другие SomeObjectCopy
The FileObjectCopy function will make an exacy copy of a specified FSFILE object.
Если «exacy» == «exact» как следует из кода, то это профитная замена прямого присвоения структур — стандартной операции в ANSI C, a сделанное компилятором, оно должно быть и быстрее и компактнее так как используются аппаратные FSR/INDF регистры. Для разных объектов подойдет memcpy(d, s, sizeof(s)) и работает он тоже быстро, во всяком случае его ассемблерная реализация.
Ну есть еще мелочи для раздувания кода, которыми можно добавить пару — тройку строк, типа:
Даже если это исключительно для того чтобы сделать переменную read-only то такого макроса вполне достаточно, чтобы компилятор выругался где надо:
5. Комментарии с фанатизмом
Комментируйте все подряд, кроме самых не очевидных кусков (см пример 1.) Если вы еще не достигли полного просветления и в вашей индусской программе случайно осталось две-три функции — создайте «шаблон описания функции», включите туда умные слова-разделы, в разделе «Description» перечислите еще раз все что было написано выше, но развернуто. Особенно эффект умножения строк кода проявляется с функциями типа «FSerror()» из примера выше.
6. Используйте особенности архитектуры
Все что было написано выше — общие советы для новичков на пути просветления, применимые к любой программе, практически на любом языке. Но настоящие поклонники Шивы используют все возможности для создания хаоса. Учитывая кучерявость гарвардской архитектуры PIC контроллеров, настоящие гуру индусского кода откроют для себя невообразное число возможностей использования специфических директив и прочих особенностей кривизны реализации си в компиляторах.
Пишите код таким образом, чтобы он даже не мог компилироваться под разными версиями компиляторов, и используйте все специфические #pragma. В этом случае каждая функция будет присутствовать в версиях как минимум для двух компиляторов и трех-четырех архитектур PIC, итого до 8 крат увеличения кода.
Еще раз удвоить количество кода вам поможет то, что указатели RAM и ROM в компиляторах под PIC разные, то есть «char*» не может быть преобразован явно или неявно к «const char*» в хайтеке или «const rom char*» в микрочипе. Что вобщем-то проблем в хайтеке не вызывает совсем, так как void, far и const указатели могут адресовать всю память и применяться как к ROM так и RAM. Но в микрочиповской реализации си это может привести к созданию двух функций: одной работающей с ROM, а второй с RAM — чистый профит. Никогда не следует довольствоваться одной функцией, работающей с оперативной памятью (а при необходимости загружающей туда константы из ROM).
И последнее, всегда используйте инлайн-ассемблер даже в случаях когда ваш код значительно длиннее и медленнее чем то, что делает компилятор из нормальной си программы. Ассемблер выглядит круто и большинство не заподозрят какое скудоумие было приложено при его создании, а также будут считать что программа написана одним из оптимальнейших из возможных методов.