Шаблон электронной формы



Шаблон электронной формы
Шаблон электронной формы
Шаблон электронной формы
Шаблон электронной формы
Шаблон электронной формы
Шаблон электронной формы
Шаблон электронной формы
Шаблон электронной формы
Шаблон электронной формы

 


Владельцы патента RU 2413987:

МАЙКРОСОФТ КОРПОРЕЙШН (US)

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

 

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

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

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

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

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

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

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

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

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

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

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

Фиг.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.

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

Заключение

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

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

2. Способ по п.1, в котором этап приема результата выбора включает в себя прием результата выбора менее чем всех аспектов, которые можно выбирать графически.

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

4. Способ по п.1, в котором этап предоставления возможности включает в себя предоставление возможности выбора одного или более неструктурных аспектов.

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

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

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

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

9. Способ по п.8, в котором этап предоставления возможности включает в себя предоставление возможности выбора через воспроизводимое представление шаблона электронной формы.

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

11. Способ по п.8, в котором этап упаковывания включает в себя упаковывание и сохранение выбранного созданного разработчиком аспекта(ов), используя расширяемый язык разметки.

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

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

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

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

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

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



 

Похожие патенты:

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

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

Изобретение относится к области передачи данных, в частности к пересылке упрощенной информации, содержащей текст, рассчитанной на приемники простой конструкции, и к передаче информации, содержащей текст и иные данные, предназначенной для принимающих устройств с расширенными функциями, причем приемники обоих типов предусматривают считывание потока данных
Изобретение относится к кодированию числовых данных и передачи структур данных в телекоммуникационной системе, основанной на IP-протоколе

Группа изобретений относится к области конверсии данных, причем первые данные имеют первую табличную структуру, вторые данные имеют вторую табличную структуру. Техническим результатом является повышение точности, а также обеспечение возможности применения данного способа для множества различных структур данных. Способ содержит этапы, на которых: 1) идентифицируют данные, имеющие первую табличную структуру; 2) идентифицируют область обхода данных; 3) совершают проход для каждой ячейки данных из упомянутой области обхода данных, при этом: 4) формируют во внутренней базе данных для каждой ячейки данных буфер для идентифицированного контекста; 5) идентифицируют контекст для первой ячейки данных; 6) идентифицируют контекст для следующей ячейки данных; 7) итеративно выполняют этапы 5) и 6) до тех пор, пока не будет совершен проход для каждой упомянутой ячейки данных из упомянутой области данных; 8) сериализуют полученную базу данных во внутренний формат данных XML; 9) применяют к полученному файлу XML шаблон таксономии, причем шаблон таксономии выбирается в зависимости от второй табличной структуры данных; 10) осуществляют конверсию полученного файла XML в данные, имеющие вторую табличную структуру, в соответствии с примененным к нему шаблоном таксономии. 4 н. и 30 з.п. ф-лы, 4 ил.

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

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

Изобретение относится к средствам удаления повреждений стилей из основанных на расширяемом языке разметки (XML) документов. Технический результат заключается в уменьшении вероятности повреждения содержимого файла. Считывают информацию о стилях, связанную с основанным на XML документом. Определяют по меньшей мере один из ряда неиспользуемых, поврежденных и продублированных стилей посредством сопоставления определений стилей для этого документа с частями, которые относятся к стилям, в пакете документов. Удаляют по меньшей мере один из упомянутого ряда неиспользуемых, поврежденных и продублированных стилей, не открывая основанный на XML документ в полнофункциональном приложении, которое связано с основанным на XML документом. Определяют поврежденные диапазоны имен. Удаляют поврежденные диапазоны имен из основанного на XML документа. 3 н. и 16 з.п. ф-лы, 7 ил.

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