ШАБЛОН ЭЛЕКТРОННОЙ ФОРМЫ

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

Изобретение относится к шаблонам электронной формы.

УРОВЕНЬ ТЕХНИКИ

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

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

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

РАСКРЫТИЕ ИЗОБРЕТЕНИЯ

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

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

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

Фиг.1 показывает примерную рабочую среду.

Фиг.2 показывает примерное отображаемое представление существующего шаблона электронной формы.

Фиг.3 - последовательность операций примерного процесса для предоставления возможности разработчику упаковывать созданные разработчиком аспекты.

Фиг.4 показывает представление на фиг.2 с рамкой выбора.

Фиг.5 показывает представление для разработчика примерного текущего шаблона электронной формы.

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

Фиг.7 показывает представление на фиг.5 с добавлением примерных упакованных созданных разработчиком аспектов.

Фиг.8 показывает представление для разработчика примерного текущего шаблона электронной формы, имеющего существующую структуру данных.

Фиг.9 показывает представление на фиг.8 с добавлением примерных неструктурных аспектов.

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

ОСУЩЕСТВЛЕНИЕ ИЗОБРЕТЕНИЯ

Обзор

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

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

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

Примерная рабочая среда

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

Фиг.1 показывает в общем случае одну из таких рабочих сред 100, содержащую компьютер 102 и доступный источник 104 данных, имеющий доступный считываемый компьютером носитель 105. Показан компьютер, содержащий процессор 106 и считываемый компьютером носитель 108. Процессор может обращаться к считываемому компьютером носителю и/или выполнять находящуюся на нем программу. Считываемый компьютером носитель содержит существующий шаблон 110 электронной формы, средство 112 упаковывания аспектов, имеющее пользовательский интерфейс 114 аспекта, приложение 116 разработки, имеющее пользовательский интерфейс 118 разработки, и текущий шаблон 120 электронной формы. Средство упаковывания аспектов и приложение разработки показаны отдельно, но они могут быть объединены.

Средство упаковывания аспектов может предоставлять возможность пользователю упаковывать один или большее количество существующих созданных разработчиком аспектов (упакованные аспекты обозначены позицией 122) для последующего добавления к другому шаблону электронной формы, такому как текущий шаблон 120 электронной формы. Упакованные созданные разработчиком аспекты 122 содержат структурный аспект 124 и неструктурные аспекты 126. Неструктурные аспекты могут содержать различные настройки для шаблона формы, например, аспект 128 связи между данными, аспект 130 бизнес-логики, аспект 132 режима редактирования, аспект 134 форматирования и аспект 136 способа отображения.

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

Примерный существующий шаблон электронной формы

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

Отображаемое представление 200 существующего шаблона электронной формы 110 показано на фиг.2. Данное представление показывает шаблон электронной формы для ввода информации о продаже шин с полями для ввода данных для имени 202 продавца шин, номера 204 служащего, типа 206 шин, цены 208 шин, полной стоимости 210, типа 212 автомобиля, имени 214 клиента, улицы 216 клиента, города 218 клиента, штата 220 клиента и почтового индекса 222 клиента.

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

Существующий шаблон электронной формы имеет другие (неструктурные) аспекты, созданные его разработчиком. Некоторые из них являются визуальными, и таким образом их просто видеть в данном отображаемом представлении. Одним из таких аспектов является форматирование. Форматирование может определять шрифт, размер и цвет текста в и вокруг полей для ввода данных, например, текст «Запись о продаже шин», «Компания по продаже шин Acme», «Семейное предприятие», «Имя продавца:», «Номер служащего:», «Тип шины:», «Цена шины:», «Полная стоимость:», «Информация о клиенте», «Тип автомобиля:», «Имя клиента:», «Улица:», «Город:», «Штат:» и «Почтовый индекс:». Другой визуальный аспект - способ отображения. Этот аспект может определять цвет и размер полей для ввода данных. Поля для ввода данных 212, 214, 216, 218, 220, 222 и текст «Информация о клиенте», например, находятся в пределах затененного обведенного пунктирной линией поля, отмеченного как 224. Это затененное обведенное пунктирной линией поле является одним из аспектов способа отображения существующего шаблона электронной формы.

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

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

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

Каждый из этих неструктурных аспектов может быть связан со структурным аспектом, в данном случае с соответствующими структурами данных в существующем шаблоне электронной формы. В одном из вариантов осуществления каждую из этих связей можно отделять от соответствующей структуры. Эта возможность отделения описана более подробно ниже.

Упаковывание аспектов для многократного использования

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

На фиг.3 показан примерный процесс 300 для предоставления пользователю возможности упаковывать аспекты, такие, которые созданы разработчиком и находятся в существующем шаблоне электронной формы. Процесс 300 показан как последовательность этапов, представляющих отдельные операции или действия, выполняемые элементами рабочей среды 100, показанной на фиг.1, такими как средство 112 упаковывания аспектов и пользовательский интерфейс 114 аспекта. Этот и другие раскрытые процессы могут воплощаться в любых соответствующих аппаратных средствах, программном обеспечении, аппаратно-программном обеспечении или в их комбинации; в случае программного обеспечения и аппаратно-программного обеспечения эти процессы представляют последовательность операций, воплощаемых как выполняемые компьютером команды, которые хранятся на считываемом компьютером носителе 108 и выполняются процессором 106.

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

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

Предполагают, например, что разработчик шаблона формы хочет многократно использовать аспекты полей для ввода информации о клиенте (поля 212, 214, 216, 218, 220 и 222). Разработчик формы может захотеть иметь эти аспекты в наличии для многократного использования в других шаблонах формы, таких как запись об обслуживании, предназначенная для записи информации об обслуживании автомобиля, например, о ремонте тормозов автомобиля.

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

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

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

Аспекты могут упаковываться отдельно и сохраняться локально или в удаленном источнике, например, как шесть аспектов, сохраненных в удаленном источнике 104, показанные на фиг.1: структурный аспект 124; аспект 128 связи между данными; аспект 130 бизнес-логики; аспект 132 режима редактирования; аспект 134 форматирования; и аспект 136 способа отображения. Аспекты могут упаковываться и сохраняться с использованием языка разметки (например, расширяемого языка разметки «XML»), языка преобразования (например, языка преобразования таблицы стилей XML), расширяемого языка таблицы стилей (например, расширяемого языка таблицы стилей), схемы (например, XML схемы) или как гипертекстовый машинный язык (HTML), например.

Средство упаковывания аспектов может также упаковывать аспекты в компонент, компонент содержит структурный аспект, который можно отделять от связанных неструктурных аспектов (например, показанные структурные аспекты, содержащиеся в неструктурных аспектах 126 на фиг.1). Этот компонент может содержать структурные и неструктурные аспекты, упакованные фактически для предоставления возможности добавления неструктурных аспектов к шаблону электронной формы без необходимости добавления также структурного аспекта.

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

Этот компонент содержит структурный аспект, представленный структурными свойствами полей информации о клиенте (212, 214, 216, 218, 220 и 222 на фиг.2), где они упорядочены в представление существующего шаблона электронной формы и где они находятся в пределах существующей структуры данных шаблона электронной формы.

Этот компонент также содержит неструктурные аспекты полей информации клиента. Он содержит аспект форматирования, в данном случае шрифт, размер и цвет текста в и вокруг полей для ввода данных, например, «информация о клиенте», «тип автомобиля:», «имя клиента:», «улица:», «город:», «штат:» и «почтовый индекс:». Компонент также содержит аспект способа отображения, например, затененное обведенное пунктирной линией поле, отмеченное как 224 на фиг.2. Он также содержит аспект связи между данными для автоматического заполнения полей город и штат, основываясь на почтовом индексе.

На этапе 308 средство упаковывания аспектов может создавать значок или другой графический символ для помощи в будущем при графическом выборе упакованного аспекта(ов).

Продолжая обсуждение иллюстративного варианта осуществления, примерное представление 502 компонента, озаглавленного «информацию о клиенте», показано на фиг.5. Это представление компонента содержит значок, представляющий более мелкое упрощенное представление части существующего шаблона электронной формы, из которого упакованы аспекты компонента. Эта фиг.5 также показывает представление 504 для разработчика текущего шаблона 120 электронной формы, который находится в процессе создания. Текущий шаблон электронной формы содержит текстовое поле, в которое нельзя вводить информацию, показывающее заголовок текущего шаблона электронной формы «запись об обслуживании» 506.

После этапа 306 и/или этапа 308 считываемый компьютером носитель 108 на фиг.1 может перейти (или через средство упаковывания аспектов, или через приложение разработки, или иным образом) к выполнению этапов процесса 600, сформулированных ниже. В одном из вариантов осуществления переход от процесса 300 к процессу 600 происходит автоматически, таким образом добавляя аспекты, выбранные в процессе 300, в текущий шаблон электронной формы 120 без дополнительного взаимодействия с пользователем или разработчиком.

Добавление созданных разработчиком аспектов

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

Примерный процесс 600, который обеспечивает разработчику возможность добавлять упакованный созданный разработчиком аспект к шаблону электронной формы, показан на фиг.6. Процесс 600 показан как последовательность этапов, представляющих отдельные операции или действия, выполняемые элементами рабочей среды 100, показанными на фиг.1, такими как приложение 116 разработки и пользовательский интерфейс 118 разработки.

На этапе 602 приложение разработки (и его пользовательский интерфейс) предоставляет возможность выбора упакованного созданного разработчиком аспекта. Приложение разработки может выполнять это графически или иным образом. В одном из вариантов осуществления приложение разработки также обеспечивает возможность выбора стандартных встроенных элементов управления (не показаны). В этом варианте осуществления стандартные встроенные элементы управления можно выбирать и использовать подобно упакованному созданному разработчиком аспекту.

Продолжая обсуждение иллюстративного варианта осуществления, приложение разработки представляет представление 504 для разработчика текущего шаблона 120 электронной формы, показанное на фиг.5. Приложение разработки предоставляет возможность графического выбора упакованных созданных разработчиком аспектов, представленных с помощью компонента 502.

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

На этапе 606, если разработчик выбирает добавление структурного аспекта или не указывает, следует или нет добавлять структурный аспект, то приложение разработки переходит по пути «Нет» на этап 608. Если разработчик явно выбирает добавление структурного аспекта, то приложение разработки переходит по пути «Да» на этап 610.

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

На этапе 608 приложение разработки определяет, содержит или нет текущий шаблон электронной формы структуру данных, подобную структуре данных структурного аспекта и/или на которую неструктурный аспект может отображаться. Если нет, то приложение разработки переходит по пути «Нет» на этап 610. Если да, то приложение разработки переходит по пути «Да» на этап 612.

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

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

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

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

Фиг.7 показывает такое добавление упакованных созданных разработчиком аспектов компонента к текущему шаблону 702 электронной формы.

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

В качестве примера на фиг.8 отображают второй иллюстративный вариант осуществления, который показывает представление 802 для разработчика текущего шаблона 804 электронной формы, имеющего существующую структуру данных. Этот текущий шаблон электронной формы является стандартным шаблоном формы, спроектированным для того, чтобы выставлять счет клиентам. Поскольку шаблон формы соответствует стандарту (установленному или промышленностью, или компанией - разработчиком программного обеспечения для выставления счетов, или другим образом), разработчик формы, возможно, не захочет изменять структуру ее данных, поскольку это может сделать намеченное использование шаблона формы трудным или невозможным. Этот шаблон формы содержит различные средства управления, такие как поля для ввода данных и кнопки выбора.

На этапе 608 приложение разработки определяет, что набор 806 полей для ввода данных (показаны в пределах обведенного пунктирной линией поля) имеет структуру данных, подобную структуре структурного аспекта компонента информации о клиенте, показанного на фиг.8 как 502. Этим набором можно управлять, например, с помощью схемы, подобной схеме структурного аспекта компонента информации о клиенте. Этот набор может иметь подобную структуру частично из-за своих свойств, соответствующих свойствам полей информации о клиенте на фиг.2. Набор полей 806 содержит, подобно полям информации о клиенте на фиг.2, шесть полей для ввода данных, причем два из них разрешают ввод текста или цифр, три разрешают ввод только текста, и один разрешает ввод только цифр.

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

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

Компонент информации о клиенте содержит, в качестве повторения, три неструктурных аспекта, которые показаны на фиг.1: аспект 128 связи между данными; аспект 134 форматирования; аспект 136 способа отображения. На этапе 614 приложение разработки отображает каждый из них на подобную структуру данных текущего шаблона электронной формы и добавляет их к текущему шаблону электронной формы.

Такое добавление неструктурных аспектов показано частично на фиг.9. Эта фигура представляет дополнительные аспекты форматирования и способа отображения на представлении для разработчика. Аспект связи между данными, который предназначен для автоматического заполнения полей штат и город, не показан. Форматирование показано с помощью добавления текста, имеющего шрифт, размер и цвет, который также показан на фиг.2 с помощью полей «информация о клиенте» 902, «тип автомобиля:» 904, «имя клиента:» 906, «улица:» 908, «город:» 910, «штат:» 912 и «почтовый индекс:» 914. Способ отображения показан с помощью затененного обведенного пунктирной линией поля, отмеченного как 916.

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

Заключение

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