Шаблоны документов нужны для автоматического заполнения полей и таблиц в документах MS Word данными из базы. Это позволяет создавать такие документы как Заявка, Счет, Накладная, Счет-фактура, Договор, Акт и многое-многое другое. Их можно печатать, отправлять по почте и т.п.

Как работают шаблоны документов?

В любой таблице появляется пункт меню Шаблоны документов .

Выбор этого меню открывает список шаблонов документов по данному объекту.

Выбрав шаблон и нажав кнопку Заполнить вы получите заполненный документ .

Подготовка к использованию шаблонов документов

Эти настройки достаточно произвести один раз.

• Создайте карточку для объекта Шаблон документа . Добавьте в нее поле Название .
• Создайте таблицу для объекта Шаблон документа . Добавьте в нее поля Название и Файл .

Настройка шаблона документа

После перелогина выберите меню Настройки - Шаблоны документов. Появится диалог, в котором происходит настройка шаблонов документов.

Описание зон окна:

1. Список всех шаблонов по всем объектам.
2. Объект шаблона.
3. Поля объекта шаблона.
4. Поля объектов дочерних связей, если они есть.

В разделе Документ находятся следующие кнопки:

• Создать - создает новый документ в MS Word.
• Открыть - открывает ранее сохраненный документ MS Word или предлагает указать имеющийся.
• Сохранить - сохраняет документ MS Word и отмеченные поля.
• Закрыть - закрывает документ MS Word без сохранения.

В третьей и четвертой зоне находятся поля, которые вставляются в документ. Там есть кнопки:

• Изменить - переименовывает поле, чтобы оно могло быть более коротким.
• Вставить - вставляем поле в документ MS Word туда где стоит курсор.

В четвертой зоне на отмеченном поле можно щелкнуть правой кнопкой и задать сортировку.

Пример настройки шаблона

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

1. Добавляем новый шаблон , нажав кнопку Добавить (слева).
2. Создаем новый документ нажав кнопку Создать . Открывается MS Word с новым чистым документом.
3. Отмечаем нужные поля и вставляем их в документ. Для этого нужно:
   1. Установить курсор в документе в нужное место.
   2. Выделить нужное поле в программе и нажать кнопку Вставить .

Если требуется, настройте сортировку в таблицах.

Вот так выглядит настройка шаблона документа в программе:

А так выглядит сам шаблон документа с полями:

Заполнение шаблона документа

Для использования шаблонов документов нужно для пользователя и для объекта дать соответствующее разрешение . Затем:

1. Открыть таблицу нужного объекта.
2. Выделить нужную запись в таблице.
3. Выбрать меню Еще - Шаблоны документов .
4. Выделить нужный шаблон и нажать кнопку Заполнить .

В результате получим заполненный шаблон.

Теперь вы можете распечатать этот документ или сохранить его, если требуется.

Дополнительная информация

• Используйте поля не более 255 символов длиной (по версию 1.12).
• Не закрывайте вручную документ в MS Word. Закрывайте его только через программу кнопкой Закрыть .
• Используйте поля дочерних объектов только в таблицах MS Word.
• Используйте в таблицах специальный шаблон [N] для порядковой нумерации данных в таблицах.
• В сетевой версии располагайте шаблоны по сетевому пути.
• При вставке поля дочернего объекта вы увидите число, не удаляйте его. Это код связи. Он нужен.
• Если вы решили переименовать поле, то сначала переименуйте его, а потом вставляйте.
• Заполняются только поля, отмеченные галочкой.
• Используются только поля объекта и поля дочерних объектов. Поля дочерних объектов дочерних объектов использовать нельзя.
• В одном шаблоне можно использовать сразу несколько таблиц дочерних объектов.
• Путь к шаблону документа может быть относительный (начинается с точки):
  .\Шаблоны\Счет.doc
• Двойной клик по элементу иерархии ставит на нем флаг и вставляет в документ.

Хотя стандарты шаблонов опубликованы уже давно, они все еще распространены недостаточно широко. Конечно, трудно использовать нечто, не поддерживаемое вашим компилятором, - наверное, это первая причина, по которой большинство программистов C++ не умеет работать с шаблонами. К счастью, сейчас все основные компиляторы уже вошли в двадцатый век, так что эта проблема уже отпала. Остается лишь понять, что такое шаблон, как обойти все синтаксические ловушки, но прежде всего - для чего он все-таки нужен. Эта глава не ограничивается обзором синтаксиса. В ней также рассматриваются основы безопасности типов в C++, причем особое внимание уделяется шаблонам.

Что такое шаблоны и зачем они нужны?

Интерфейс простого класса-коллекции (на примере связанного списка) выглядит так:

class ListNode { private:

ListNode* next; void* data;

ListNode(void* d, ListNode* n = NULL) : next(n), data(d) {} ~ListNode() { delete next; }

void* Data() { return data; } ListNode* Next() { return next; }

Заметили что-нибудь особенное?

Проблемы

Прежде всего, в глаза бросаются все эти void* . И вы, и я прекрасно знаем, что на самом деле за ними кроется нечто совершенно иное. Где-то в клиентском коде придется сделать что-нибудь подобное:

for (ListNode* n = listHead; n != NULL; n = n->Next()) f((Foo*)n->Data());

Иначе говоря, вам придется постоянно приводить void* к конкретному типу Но как убедиться в том, что полученный указатель действительно имеет тип Foo* ? Здесь придется рассчитывать только на себя, потому что компилятор со словами «Надеюсь, ты знаешь, что делаешь» умывает руки. Допустим, вы уверены, что ваше использование класса надежно по отношению к типам. Но можно ли гарантировать, что другой программист не выкинет какую-нибудь глупость и не занесет в коллекцию объект другого типа? Если вы свято верите в это, я рекомендую держаться подальше от рискованных инвестиций и вложить деньги в правительственные бумаги, вряд ли вам повезет в этой жизни.

Вторая проблема заключается в том, что элементы списка не знают, на какой тип они указывают. Предположим, вам хочется, чтобы деструктор списка удалял не только сами узлы, но и данные, на которые они ссылаются. Нельзя передать оператору delete указатель void* и надеяться, что он сам выберет нужный деструктор.

Обходные решения

Одно из возможных решений - потребовать, чтобы все объекты вашей коллекции происходили от общего предка. В этом случае void* можно будет заменить указателем на базовый класс, создавая хотя бы видимость порядка. Если деструктор базового класса является виртуальным, по крайней мере мы сможем переписать деструктор ListNode так, чтобы при самоубийстве он уничтожал и содержимое списка. Но если этот базовый класс имеет производные классы, вы наверняка вернетесь к необходимости выполнения ненадежных операций приведения к этим производным типам.

Другое обходное решение - создать список, рассчитанный на конкретный тип. Скажем, для ведения списка объектов класса Foo создается класс-коллекция ListOfFoos . В этом случае вам не придется выполнять приведения типов, если Foo не имеет производных классов. Но стоит ли плодить классыдвойники, которые отличаются только типами, с которыми они работают? Конечно, вырезание и вставка в текстовых редакторах - замечательная вещь, а сценарии обработки текстов помогают быстро размножить код. Но если вам потребуется изменить представление всех этих списков, дело неизбежно кончится масштабной головной болью.

В прошлом подобные проблемы часто решались с помощью макросов #define :

#define ListNode(Type) \ class ListNode##Type { \ private: \

ListNode##Type* next; \ Type* data; \

ListNode##Type(Type* d, ListNode* n = NULL) : next(n), data(d) {} \ ~ListNode() { delete next; } \

void* Data() { return data; } \ ListNode* Next() { return next; } \

Если вы нечаянно забудете поставить знак \ , компилятор разразится громкими негодующими воплями, но при должной осторожности эта методика работает. Символы ## означают конкатенацию. Конструкция становится еще уродливее, но с этим приходится мириться - вы должны обеспечить уникальность имен типов коллекций. Такая методика обладает многочисленными недостатками. Если функции класса не являются подставляемыми (inline), вам придется создавать для них дополнительные макросы и следить, чтобы они были реализованы в одном модуле компиляции. У некоторых компиляторов возникают проблемы со слишком длинными макросами. Директивы #define не могут быть вложенными, поэтому рекурсивные, безопасные по отношению к типам структуры данных отпадают. Хуже всего, что при обнаружении ошибки в макросе отладчик складывает руки и сообщает, что где-то в макросе допущена ошибка, но не указывает конкретного номера строки.

Шаблоны - усовершенствованные макросы

На сцену выходит механизм шаблонов - усовершенствованный макропроцессор для директив #define . Шаблоны представляют собой ничто иное, как макросы без всех перечисленных ограничений. Они могут быть вложенными. Вам не придется беспокоиться о дублировании их функций. Большинство отладчиков C++ при возникновении ошибки правильно указывает строку шаблона. Размер шаблона не вызовет никаких проблем. Наконец, вам не придется уродовать свою прекрасную программу закорючками вроде \ и ## .

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

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

Для чего нужен шаблон

Благодаря шаблону определяется внешний вид сайта. Он является основой, с помощью которой совокупность всех рабочих элементов (плагинов, модулей, компонентов) функционирует в должном режиме.

Участь шаблонов на CMS Joomla невосполнима, поскольку корректное отображение сайта без них является невозможным. Как можно заметить системой даже не предусмотрено возможности отключения всех шаблонов одновременно. Напротив одного из них обязательно должна стоять желтая звездочка, обозначающая «По умолчанию».

Что такое шаблон в Joomla

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

Каждый Джумла шаблон состоит из:

• Файла index.php, который отвечает за структуру всех страниц вашего сайта.
• Файла style.css, благодаря которому на веб-проекте регулируется оформление блоков страницы. Сюда относится стилистика написания и цвет шрифтов, их смещение и т.п.
• XML-файл, отвечающий за установку шаблона через админ-панель Joomla.

В свою очередь существует два вида шаблонов для Джумла:

1. Site Template . Что дословно переводится как шаблон сайта.
2. Backend Template . Словосочетание в переводе обозначающее - шаблон административной части сайта.

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

И в заключение для облегчения поиска чистых шаблонов, оставлю для вас несколько проверенных мною адресов.

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

Базовый план тегов

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

Базовый план скоринга

Базовый план скоринга позволяет идентифицировать контакты по уровню вовлечения. Этот процесс автоматически добавляет или вычитает баллы на основе активности контактов (открытия писем, клики, подписки на рассылку). и постоянно изменяет баллы в зависимости от действий, совершаемых подписчиками.

Предложение демо-версии

В целях повышения продаж можно использовать шаблон Предложение демо-версии . С его помощью можно создать процесс для таргетинга квалифицированных контактов и их добавления на конкретный этап воронки CRM. Этот процесс может использоваться как для новых, так и для существующих контактов:

• существующие контакты получают приглашение, в котором вы просите их подтвердить интерес в демо-версии продукта;
• новые подписчики получают письмо для подтверждения запроса демо-версии.

На последнем шаге процесс присваивает теги контактам, чтобы определять их для будущих кампаний и рассылок.

Этот шаблон одобрен экспертом по конверсии Талией Вульф. 


Присвоение тегов контактам на основе баллов

В целях повышения конверсии и продаж можно использовать шаблон Присвоение тегов контактам на основе баллов . Шаблон помогает создать процесс, который:

• запускается при подписке новых контактов на конкретный список рассылки;
• ждет заданное время, пока контакты не наберут нужное количество баллов;
• присваивает теги на основе баллов, чтобы вы могли определять лидов, готовых к продающей презентации.

Этот шаблон одобрен экспертом по конверсии Талией Вульф.

Все чаще и чаще я слышу от разработчиков и читаю в статьях, что шаблоны проектирования (они же дизайн-паттерны) никому не нужны. Мол, они появились во времена «цветения» UML, RUP, CASE систем и прочих чересчур «сложных» инструментов, подходов и практик. А сейчас самое важное - это код рабочий написать, да побыстрее. На умные толстые книжки ни у кого нет времени, разве что для прохождения собеседования. Тех, кто хочет обсудить данную тему, прошу под кат.

Немного воспоминаний из молодости

Когда я учился в университете, нам преподавали в рамках одного из курсов шаблоны проектирования. На тот момент они казались мне чем-то наподобие сферического коня в вакууме, потому что практического опыта их применения я не имел (это был третий или начало четвертого курса много лет назад). Запомнить кто из них кто тоже было достаточно сложно, не говоря уже о тонкостях и деталях. Тем не менее, вопросы по шаблонам проектирования задавали в обязательном порядке на каждом собеседовании на работу. Кандидатам приходилось раздувать щеки и доказывать как круты разные шаблоны (особенно Singleton), видя их в жизни максимум раз-другой на страницах книжек.

Но ведь совсем не глупые люди придумали шаблоны проектирования:

• В 70-ые годы архитектор Кристофер Александр начал дело и сформулировал набор шаблонов проектирования.
• Его дело в IT подхватили в далеком 1987 году небезызвестные Кент Бэк и Вард Каннингем , составив шаблоны проектирования для популярного языка программирования Smalltalk.
• Еще один легендарный в IT человек Эрих Гамма написал докторскую диссертацию на эту тему в 1988-1990 .
• И наконец, в начале 90-ых известная «банда четырех» в составе все того же Эриха Гаммы, Ричарда Хелма, Ральфа Джонсона и Джона Влиссидсома опубликовала легендарную книгу «Design Patterns: Elements of Reusable Object-Oriented Software» .

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

Через некоторое время работы я начал замечать, что даже теоретические знания шаблонов проектирования помогают мне понять чужой код гораздо быстрее . А это особенно важно на старте вашей карьеры, когда вам надо вникать в существующие проекты без опыта работы. Например, встречая класс с суффиксом Builder, я понимал, что его добавили с целью упрощения и изоляции логики построения сложных объектов. Я сразу легко находил как им пользоваться и применять в своем коде. Повсюду были разбросаны представители шаблона Singleton, совершить ошибку при инициализации которых так легко без знаний правил применения. В коде, с которым я работал, обильно встречались Facade, Visitor, Chain of Responsibility, Iterator, Adapter, Decorator, Proxy, Strategy, Template Method и прочие популярные шаблоны проектирования.

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

А как без шаблонов?

Время шло… Я достаточно быстро привык к повсеместному применению шаблонов проектирования и мне стало сложно работать без них. Я начал понимать для чего на собеседовании у кандидатов спрашивают о них (конечно, если не просто «для галочки»). Тут речь даже не об обязательном применении шаблонов проектирования, а об упрощении общения между разработчиками. А это тот процесс, который занимает ключевое место в разработке - обсуждение архитектуры и дизайна конкретного решения задачи.

Первый важный параметр - это время, которое тратится на обсуждение и принятие решения (я надеюсь, что у вас решения принимает не один бородатый Senior Senior Global Product Software Architect). Представьте себе как сложно было бы быстро объяснить кому-то, что нужно реализовать Decorator: «нам нужно сделать класс, которому мы передадим в конструкторе экземпляр другой реализации того же интерфейса и который будет добавлять логику к вызову этих методов, не меняя их основного поведения...» А ведь еще за кадром остались куча мелочей и нюансов. И это для мелкой детали вашего дизайна, которых в большинстве решений десятки, а то и сотни. Мы даже не трогаем сложные и серьезные архитектурные шаблоны.

На примере с Decorator легко понять второй важный параметр - одинаковое понимание дизайна решения задачи в головах всех членов команды. При размытости формулировки каждый может понять решение по-разному, а это чревато проблемами. Ведь реализация может сильно отличаться от обсуждаемой задумки. А это приведет к дополнительному времени на ревью кода и переделки.

Третий важный параметр - понимание работы сторонних инструментов и библиотек. На данный момент практически в каждом проекте используется множество сторонних решений. Чтобы их использовать правильно и не наступать на грабли, архитектор и разработчик должны понимать как что устроено. А для этого используются общеизвестные шаблоны, которые призваны сильно упростить понимание и сравнить с альтернативными решениями.

В жизни мы активно используем примеры для описания ситуаций, предметов, поступков. Чтобы объяснить кому-то какую-то концепцию, мы базируемся на общеизвестных знаниях и выстраиваем примеры на их основе. «Такой же здоровый как Вася», «так же тяжело как после 5 км пробежки», «плохо как с бодуна», «кислый как лимон» и т.д. Подобные выражения мы используем в своей речи постоянно и даже не замечаем этого. Для нас их применение проще чем детальное описание и это позволяет вашему собеседнику лучше вас понять.

Следующий уровень

Если вы заметили, что вы не пытаетесь вспомнить детали реализации шаблона проектирования, а просто можете изложить детали его применения своими словами, то вы переросли уровень Shu в известной восточной философии Shuhari (я когда-то давно писал о ее применимости к Agile подходам и практикам). На уровне Shu вы просто следуете шаблонам и не можете осознать их полезность, тонкости и влияние. На уровне Ha вы уже все осознаете и можете сознательно отказываться от определенных шаблонов, критиковать решения на их базе, видоизменять некоторые шаблоны под конкретную ситуацию и контекст.

На уровне Ha я настоятельно рекомендую прочитать отличную книгу «Refactoring to Patterns» от Джошуа Кериевски. В ней рассказывается о том, как находить в коде неподходящие или плохо примененные шаблоны проектирования, а потом посредством рефакторинга приводить их к верным и подходящим решениям. Эту книгу стоит читать именно на уровне Ha, потому что до этого она будет для вас просто пустым звуком.

У как же уровень Ri ? На этом уровне вы и вовсе перестаете задумываться о применении шаблонов. Решения рождаются натурально на базе ваших знаний и навыков, которые вы накопили с годами. Где-то вырисовываются одни шаблоны, где-то ваши собственные наработки, которые стали для вас шаблонами в данном контексте. В голове у вас перестает работать цепочка «от шаблона к решению» и остается только «от решения к шаблону». Тогда вместо вопросов о конкретных шаблонах проектирования на собеседовании вы переходите к открытым вопросам о применимости данного инструмента и примерах из реальной жизни…

Заключение

Шаблоны проектирования - это один из инструментов разработчика, который помогает ему сэкономить время и сделать более качественное решение. Как и любой другой инструмент, в одних руках он может принести много пользы, а в других - один только вред. Я попытался донести на примерах, что конкретно дадут вам шаблоны проектирования и как к ним стоит относиться. Надеюсь, мне это удалось…

P.S. На одном из моих тренингов хвалили книгу по шаблонам проектирования для начинающих «Head First Design Patterns» . Лично сам не читал, потому как достаточно владел темой из других источников и недоверительно отношусь к такого формата книгам.