EA201201059A1 20130930 Номер и дата охранного документа [PDF] EAPO2013/PDF/201201059 Полный текст описания [**] EA201201059 20120828 Регистрационный номер и дата заявки US13/330,785 20111220 Регистрационные номера и даты приоритетных заявок EAA1 Код вида документа [pdf] eaa21309 Номер бюллетеня [**] СИСТЕМА И СПОСОБ УПРАВЛЕНИЯ ВЕБ-ФОРМАМИ И ДИНАМИЧЕСКИМ СОДЕРЖИМЫМ ВЕБ-САЙТОВ Название документа [8] G06F 9/44 Индексы МПК [RU] Бобыкин Антон Валерьевич, [RU] Тормасов Александр Геннадьевич Сведения об авторах [RU] ОБЩЕСТВО С ОГРАНИЧЕННОЙ ОТВЕТСТВЕННОСТЬЮ "ПАРАЛЛЕЛЗ РИСЕРЧ Сведения о заявителях
 

Патентная документация ЕАПВ

 
Запрос:  ea201201059a*\id

больше ...

Термины запроса в документе

Реферат

[**]

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


Полный текст патента

(57) Реферат / Формула:

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


Евразийское (21) 201201059 (13) A1
патентное
ведомство
(12) ОПИСАНИЕ ИЗОБРЕТЕНИЯ К ЕВРАЗИЙСКОЙ ЗАЯВКЕ
(43) Дата публикации заявки 2013.09.30
(22) Дата подачи заявки 2012.08.28
(51) Int. Cl. G06F 9/44 (2006.01)
(54) СИСТЕМА И СПОСОБ УПРАВЛЕНИЯ ВЕБ-ФОРМАМИ И ДИНАМИЧЕСКИМ СОДЕРЖИМЫМ ВЕБ-САЙТОВ
(31) (32) (33)
(71)
(72)
13/330,785
2011.12.20
Заявитель:
ОБЩЕСТВО С ОГРАНИЧЕННОЙ ОТВЕТСТВЕННОСТЬЮ "ПАРАЛЛЕЛЗ РИСЕРЧ" (RU)
Изобретатель:
Бобыкин Антон Валерьевич, Тормасов Александр Геннадьевич
(RU)
(57) Управление динамическим содержимым вебсайта, включая создание статического содержимого, присвоенного динамическому содержимому, с неизменяемыми сценариями, создание активного содержимого для обработки динамического содержимого, со скрытыми элементами и элементами, содержащими только представление визуальных меток, передачу статического содержимого пользователю; выбор ссылок на активное содержимое в рамках статического содержимого, запрос на сервере описания активного содержимого, передачу активного содержимого пользователю, отображение активного содержимого; редактирование динамического содержимого и визуальных представлений данных, запрошенных пользователем, представление первой формы документа, созданной на основе HTML представления серверных данных и неизменяемых сценариев, и который включает в себя такие элементы; создание запроса в отношении данных, необходимых для текущей визуализации формы, создание второго представления соответствующих данных в другой форме, обеспечение второго представления соответствующих данных для отображения в веб-обозревателе, сохранение содержимого веб-сайта на сервере и обеспечение его общедоступности.
СИСТЕМА И СПОСОБ УПРАВЛЕНИЯ ВЕБ-ФОРМАМИ И ДИНАМИЧЕСКИМ СОДЕРЖИМЫМ ВЕБ-САЙТОВ
Авторы изобретения: Антон Бобыкин
Александр Г. Тормасов
ПЕРЕКРЕСТНЫЕ ССЫЛКИ НА РОДСТВЕННЫЕ ЗАЯВКИ
[0001] Настоящая заявка является продолжением заявки на патент США № 11/953,170, от 10 декабря 2007 года, под названием "СИСТЕМА И СПОСОБ УПРАВЛЕНИЯ ВЕБ-ФОРМАМИ И ДИНАМИЧЕСКИМ СОДЕРЖИМЫМ ВЕБ-САЙТОВ", которая представляет собой постоянную заявку от временной заявки на патент США № 60/869,388, от 11 декабря 2006 года под названием "СПОСОБ УПРАВЛЕНИЯ ДИНАМИЧЕСКИМ СОДЕРЖИМЫМ ВЕБ-СТРАНИЦЫ", включенную в данное описание в полном объеме посредством ссылки.
ПРЕДПОСЫЛКИ СОЗДАНИЯ ИЗОБРЕТЕНИЯ
Область техники, к которой относится изобретение [0002] Настоящее изобретение в целом относится к разработке веб-сайта, и, в частности,
к способу, системе и программному продукту для ЭВМ и предназначено для
управления динамическим информационным наполнением веб-сайта.
Предшествующий уровень техники [0003] Текущие тенденции развития в области управления ресурсами предприятия (ERP)
или в тесной связанной с ней области управления взаимоотношениями с
заказчиками (CRM) включают в себя перемещение некоторого объема
функциональности программного обеспечения ERP/CRM с клиентской части в
сторону серверной. Обычно это обусловлено тем фактом, что поддержка
множества аппаратных платформ, многочисленных операционных систем и
огромного количества версий операционных систем (или
разного/развивающегося аппаратного и программного обеспечения) является
очень обременительной для отдела информационных технологий предприятия.
Техническое обслуживание такого программного обеспечения класса ERP,
необходимость выполнения частых обновлений, и т.д., все это делает такое
программное обеспечение класса ERP относительно ресурсоемким. В то же самое
время поставщикам такого программного обеспечения также необходима
поддержка многочисленных аппаратных и программных платформ, требующая дополнительных усилий со стороны разработчика, дополнительной поддержки со стороны поставщика и так далее.
[0004] В существующем уровне техники известны формы на базе веб-обозревателя, где форма отображается для пользователя на веб-странице, а пользователь может заполнить такую форму данными. Такое традиционное программное обеспечение на базе веб-обозревателя может работать с кодом HTML. Однако функциональность таких форм явно ограничена, а интерфейс между формами и действительным программным обеспечением, который использует данные в этих формах, также достаточно ограниченный.
[0005] Обычно веб-сайты отображают для пользователя некоторую информацию, которую они получают из базы данных. Связь между отображаемыми отформатированными отчетами и таблицами базы данных поддерживается программным обеспечением для ЭВМ. Значительная часть ресурсов операционной системы используется для создания форм отчетов и форматирования данных, отображаемых на веб-сайте.
[0006] Традиционные способы не предлагают никаких возможностей создания универсальных графических форм отчетов, которые бы могли быть заполнены универсальными данными. Частично это имеет место в силу того факта, что не может быть замещен собственный интерфейс базы данных. Структура базы данных задает определенный формат запросов, затрудняя создание универсальной формы, которая бы заполнялась универсальными данными.
[0007] Однако, при создании интерфейсов пользователя или при выполнении других операций, таких как создание двойных отчетов, нет необходимости в создании собственных форм базы данных, поставляемых вместе с системой управления базой данных (СУБД). С другой стороны, прямой доступ к базе данных с клиентской ЭВМ обладает некоторым числом недостатков, как, например, увеличение трафика и вычислительные издержки, связанные с выполнением сценариев, которые должны быть обработаны интерпретатором команд непосредственно на клиентской ЭВМ.
Таким образом, существует потребность в эффективном вычислительном способе для создания универсальных форм отчетов, которые могут заполняться универсальными данными, а также в системе и способе, которые позволят
предприятию создавать пользовательские заполняемые формы, основанные на бизнес логике, которые не являются ресурсоемкими, с точки зрения предприятия, которые можно использовать повторно, и которые являются максимально детализированными.
[0008] .
СУЩНОСТЬ ИЗОБРЕТЕНИЯ
[0009] Настоящее изобретение в целом относится к разработке веб-сайта, и, в частности, к способу, системе и программному продукту для ЭВМ для управления динамическим содержимым веб-сайта. Предлагаемый способ применяет обработку элементов базы данных за счет использования активных дескрипторов. Активные дескрипторы содержат в себе обобщенные описания элементов базы данных, свойства которых могут со временем изменяться.
[0010] Для описания объектов базы данных используют динамические дескрипторы. Таким образом, можно минимизировать требования к созданию элементов управления. Созданные элементы управления являются универсальными и могут быть использованы для обработки нескольких классов объектов.
[ООН] Каждый объект класса обладает своими атрибутами, дополнительными описаниями объекта класса. Предлагаемый способ позволяет использовать микро ядро СУБД, которое не сохраняет информацию об атрибутах. Вместо этого атрибуты класса определены активными дескрипторами каждого определенного экземпляра объекта класса.
[0012] Дополнительные признаки и преимущества изобретения будут изложены в нижеследующем описании, и будут частично понятны из описания или могут быть изучены при осуществлении изобретения на практике. Преимущества изобретения могут быть реализованы и получены посредством структуры, подробно изложенной в прилагаемом описании и формуле изобретения, а также приложенных чертежах.
[0013] Следует отметить, что как вышеизложенное общее описание, так и последующее подробное описание являются примерными и пояснительными, и предназначены для дополнительного пояснения заявленного изобретения.
КРАТКОЕ ОПИСАНИЕ ПРИЛОЖЕННЫХ ЧЕРТЕЖЕЙ
[0014] Сопровождающие чертежи, которые включены в данное описание и составляют его часть, приведены для иллюстрации и обеспечения дополнительного понимания способа и системы по изобретению, и вместе с описанием служат для пояснения принципов изобретения. На чертежах:
[0015] Фиг. 1 иллюстрирует основные компоненты платформы разработки.
[0016] Фиг. 2 иллюстрирует модель динамического взаимодействия.
[0017] Фиг. 3 иллюстрирует экранный снимок динамического представления данных.
[0018] Фиг. 4 иллюстрирует экранный снимок представления данных в момент создания (главный вид).
[0019] Фиг. 5 иллюстрирует экранный снимок представления данных в момент создания (вид сетки).
[0020] Фиг. 6 иллюстрирует экранный снимок отображения данных в момент создания с отключенным представлением (вид Standard Visual Studio.NET).
[0021] Фиг. 7 иллюстрирует экранный снимок формы для создания нового документа.
[0022] Фиг. 8 иллюстрирует экранный снимок формы для обновления документа.
[0023] Фиг. 9 иллюстрирует экранный снимок формы для документа в состоянии удержания.
[0024] Фиг. 10 иллюстрирует экранный снимок формы для документа с
неопубликованным статусом. [0025] Фиг. 11 иллюстрирует экранный снимок примера формы для документа с
недействительными значениями. [0026] Фиг. 12 иллюстрирует экранный снимок конструктора табличного кэша. [0027] Фиг. 13 иллюстрирует экранный снимок конструктора графа. [0028] Фиг. 14 иллюстрирует экранный снимок конструктора веб-формы. [0029] Фиг. 15-21 иллюстрируют дополнительные экранные снимки процесса создания
формы.
ПОДРОБНОЕ ОПИСАНИЕ ВАРИАНТОВ ОСУЩЕСТВЛЕНИЯ
ИЗОБРЕТЕНИЯ
[0030] Далее будет сделана подробная ссылка на варианты осуществления изобретения,
примеры которых проиллюстрированы на сопровождающих чертежах. [0031] Настоящее изобретение относится к способу, системе и программному продукту
для ЭВМ для управления динамическим содержимым веб-сайта. [0032] Кроме того, настоящее изобретение относится к системе и способу динамического создания содержимого веб-страницы в виде заполняемой формы, независимого от веб-браузера, компактного, удобного в использовании и легко адаптируемого к определенному виду предпринимательской деятельности или компании, основанного на ограниченном количестве компонентов/элементарных процедур, представляющих собой объект и являющихся сущностями того, с чем работает компания.
[0033] Как правило, такой объект отражает деятельность компании и обычно существует в главной бухгалтерской книге, а также так называемых "счетах", как, например, счета дебиторов, счета расходов, счета актива, счета пассива, и различные подкатегории вышеуказанного, и так далее. Некоторые из компонентов/элементарных процедур могут иметь отношение к полю формы, а также обладать некоторой логикой, которая соответствует "природе" такого поля. Например, если поле требует от пользователя ввести ИНН, то такое поле будет ограничено 10 числовыми символами, с возможным дополнением в виде тире (что составит уже 11 символов). Другие правила для объектов/компонентов соответствуют правилам реального мира, другими словами, поле для налога на добавленную стоимость (НДС) не должно быть больше чем 100% или некой определенной суммы значения элемента.
[0034] Другие компоненты могут относиться к правилам продажи, инвентаризации, человеческим ресурсам/персоналу, скидкам и так далее. Таким образом, объект или компонент ответственен за включение некоторой бизнес логики, связанной с лежащей в основе "сущностью" (или объектом, или транзакцией), однако, при упрощении элементарных процедур, насколько это возможно, и при предоставлении пользователю набора опций с целью соотношения одного компонента с другим, достигается цель максимальной подробности и повторного применения компонентов.
[0035] Событийный механизм соединяет компоненты в модели объекта, и разрешает компонентам взаимодействовать с таким механизмом, а также друг с другом. В ответ на ввод пользователем данных обработчик событий активируется. Это может происходить во время ввода (пользователю может выдаваться уведомление), например, когда пользователь не завершил ввод данных своего
ИНН, но где вводимые данные точно не являются частью разрешенного набора числовых символов. Более того, как только пользователь завершает ввод данных, обработчик событий информирует механизм о таком факте, и, таким образом, происходит обновление базы данных, а также и соответствующих компонентов. [0036] В серверной части создается форма и отображается пользователю способом, который, что является значимым, независим от веб-браузера. Форма сама по себе обладает событиями, как, например, элементами управления, относящиеся к внешнему виду такой формы, и, возможно, некоторым полям. Такими элементами контроля, например, могут быть "закрыто", "перемещено", и так далее.
[0037] Компоненты/элементарные процедуры, относящиеся к счетам главной бухгалтерской книги, являются, главным образом, активируемыми по транзакции. Это также может включать в себя такие сущности, как, цены, валюта, проданное количество единиц, единицы инвентаризации, счета дебиторов, счета кредиторов, и так далее. Форматирование поля может быть указано на этапе создания таким образом, что нет никакой необходимости в написании кода клиентской части -вся логика может существовать в серверной части и, используя программное обеспечение промежуточного уровня и протоколы взаимодействия, подключать действия клиентской ЭВМ к базе данных.
[0038] Предлагаемый способ применяет обработку элементов базы данных за счет использования активных дескрипторов. Активные дескрипторы содержат в себе обобщенные описания элементов базы данных, свойства которых могут со временем изменяться. Для описания объектов базы данных используют динамические дескрипторы. Таким образом, модули управления являются универсальными и могут быть использованы для обработки нескольких классов объектов.
[0039] Каждый объект класса обладает наборами присвоенных атрибутов, содержащих дополнительные дескрипторы объекта класса. Предлагаемый способ позволяет использовать частично нагруженное микро ядро СУБД, которое не содержит информацию об атрибутах класса. Вместо этого, атрибуты класса определяются активными дескрипторами каждого частного экземпляра объекта класса.
[0040] Обычно ядро СУБД создает экземпляр класса путем установки атрибутов для данного класса и формирования события из стандартного для данного класса
набора событий. Таким образом, для всех экземпляров одного и того же класса используют тот же самый набор событий (например, 16). Следовательно, ядро СУБД используют только для создания экземпляров класса и генерации событий. Способ обработки данных определен атрибутами определенного экземпляра класса и событиями, которые используются этим классом.
[0041] В этом случае запрос данных и обработку данных выполняют с применением универсального формата. В некоторых случаях экземпляры одного и того же класса могут требовать, например, при чтении данных, чтобы данные были представлены в различных форматах, включая предварительную обработку данных (как, например, шифрование, отбрасывание лишних данных, проверку аутентичности данных и соответствие данных маске). Однако тип обработки определен атрибутами.
[0042] Для поддержки соответствующей обработки экземпляра класса используют базу данных атрибутов. В этом случае атрибуты класса обычно не являются статическими параметрами, описывающими свойства класса, а активируют события ядра.
[0043] Например, для представления данных в форме, пригодной для передачи в открытых сетях, может потребоваться специальная обработка регистрации данных. Такая обработка регистрации данных рассматривается ядром как атрибут. Таким атрибутом может быть шифрование, переформатирование, отбрасывание лишних байтов записи и т.д. Для активации событий ядра, активные атрибуты обладают специальными обработчиками процессов.
[0044] Следует заметить, что данный способ обработки данных позволяет обеспечить представление данных в формате XML без какого-либо графического отображения данных. Таким образом, обеспечивается экономия значительного количества времени, которое обычно тратится на графику и обработку. Также можно использовать любой объект без создания интерфейса.
[0045] Когда обработка данных определяется активными обработчиками, с точки зрения ядра СУБД, обработка данных не производится, так как формат вывода данных, определяемый событием, всегда одинаков. Таким образом, ядро активирует событие и определяет поле запроса.
[0046] Атрибуты могут дополнительно включать в себя элементы управления, используемые в операционной среде WINDOWS. Тип событий также может
обладать веб-интерфейсом, который формирует сценарии и подготавливает данные в требуемом формате. В этом случае, события на сервере и их аналоги на клиентской части могут работать совместно. Таким образом, обработка данных в клиент-серверной системе не использует элементы управления, что значительно сокращает время, используемое для представления данных.
[0047] При обработке записей в клиентской части, логика исполнена на уровне события, что разгружает ядро СУБД. Клиентская часть не требует никакого представления данных в серверной части, и все необходимые функции осуществляют локально, с использованием элементов управления клиентской ЭВМ.
[0048] Бизнес логика описана в таких же атрибутах, как и обработчики. Для создания интерфейса используют отдельные события. Когда запрашивают атрибуты поля, вместо этого вызывают обработчики. Обработчики могут сформировать состояние, как, например, ошибка, размер и длина записи. Затем все это возвращается в формат HTML, где автоматически задается тип поля (ключ, длина, обработка). Для взаимодействия с базой данных используют дескрипторы каждого поля.
[0049] Поля могут быть различными, и вместо значения неправильной операции пользователь может получить состояние записи, в котором ошибка показана как состояние. Если запись требует преобразования в формат поля таблицы, с таблицей ассоциируется специальный класс. Такой класс описывает поведение (например, длина, формат, только верхний регистр, и т.д.) данного поля.
[0050] Правильное представление данных осуществляют с помощью активных дескрипторов. Статическая информация о длине поля используется процессором, который конвертирует данные в соответствующий формат. В этом случае ядру СУБД нет никакой необходимости знать о процессоре, который обновляет поле сам по себе.
[0051] Ядро не связано ни с одним интерфейсом, и вызов таблиц всегда происходит одинаково. По запросу, перед обработкой любых объектов, ядро вызывает событие.
[0052] Получение данных из базы данных выполняют при помощи ключа, затем значения передают в интерфейс с возможным шифрованием. Например, ядро запрашивает номер кредитной карты и возвращает, после активации процессора, набор символов "X" и только часть номера.
[0053] Извлечение и формирование данных для базы данных осуществляют при помощи запросов событий. Вывод замещенного номера выполняют за счет разных событий и элементов управления. При инициализации типа класса происходит анализ атрибутов. Эти атрибуты используют для обработки класса и даже подписок.
[0054] Для некоторых классов существует необходимость в формировании нескольких наборов атрибутов, так как в некоторых случаях требуется сохранять информацию о транзакциях, связанных только с определенным экземпляром класса. При осуществлении обновления записи, создают копию атрибутов для строки и интерфейса. Это позволяет не сохранять дополнительные данные, относящиеся к состоянию объекта. В этом случае для объекта создают набор бизнес правил.
[0055] Предлагаемый способ позволяет инкапсулировать атрибуты, ассоциированные с определенным полем, при этом не требуется сложной бизнес логики. Для различных полей могут использоваться одни и те же процессоры.
[0056] Ядро генерирует события, а подписка осуществляются посредством элементов управления. События ядра являются серверными событиями. Событие не создается элементом управления, так как управление передает значения для обработки, но не осуществляет реальной обработки и обновления данных. Предварительно заданный набор атрибутов позволяет проводить проверку атрибутов на достоверность.
[0057] Когда требуется изменение в интерфейсе, нет необходимости в изменениях логики, так как атрибуты ассоциированы с этим полем очевидным образом.
[0058] Предлагаемые варианты осуществления изобретения обеспечивают среду быстрой разработки приложения, которая включает в себя следующее:
- Четкое разграничение ГПИ и бизнес логики,
- Обособленную модель языка программирования (не HTML),
- Набор компонентов для автоматизации создания приложения,
- Инфраструктуру системного программного обеспечения
- Набор утилит и мастеров для уменьшения объема кодирования в ручном режиме.
[0059] Они также обеспечивают инструменты для самостоятельной настройки и
интеграции с внешними системами:
- 10- Бизнес логику, доступную через общий интерфейс прикладного программирования API (SOAP/XMLRPC).
- Инструменты для модификации приложения на уровне ГПИ и бизнес логики в соответствии с собственными требованиями; а также
- Инструменты для разработки дополнительных модулей (Инфраструктура системного программного обеспечения)
[0060] Фиг. 1 иллюстрирует основные компоненты используемой платформы
разработки. Уровень 101 основания системы является набором низкоуровневых компонентов, обладающих функциональностью, требуемой для создания приложения. Основные идеи, предлагаемые уровнем 101 основания системы:
[0061] (1) Отстранение программиста приложений от сложных моментов, связанных с кодированием доступных в Интернет приложений, например, знанием и использованием стандартов HTML, CSS, HTTP и JavaScript. (2) Обеспечение среды разработки с единым языком, где все части ГПИ, бизнес логики и доступа к базе данных кодируют в рамках той же самой среды. (3) Обеспечение набора низкоуровневых компонентов для автоматизации создания элементов ГПИ, внедрения бизнес функциональности, доступа к базе данных и соблюдения безопасности данных. (4) Обеспечение программиста приложения простой, логической, простой в понимании и стандартной моделью в целях внедрения доступа к базе данных, бизнес логики и ГПИ. (5) Обеспечение набора высокоуровневых инструментов и средств для ускорения и автоматизации создания бизнес компонентов и элементов ГПИ, с одновременным соблюдением целостности приложения.
[0062] Уровень 101 основания системы включает в себя следующие компоненты:
[0063] Уровень 107 доступа к данным (DAL): Набор низкоуровневых компонентов, отвечающих за доступ к базе данных, элементарные процедуры манипулирования данными и управление сохраняемостью. Уровень авторизации и безопасности (ASL) 109: Набор низкоуровневых компонентов, отвечающих за авторизацию пользователя и проверку прав доступа на уровне бизнес логики доступа к данным. Элементы управления веб-просмотром 111: Набор элементов управления веб-просмотром для создания ГПИ. Модель 113 прикладного программирования (АРМ): Набор низкоуровневых компонентов и элементарных процедур, которые
- и -
связывают вместе элементы DAL, ASL, и управление веб-просмотром, а также обеспечивают программиста приложений моделью и API для внедрения бизнес логики и ГПИ. Конструкторы 115: Набор компонентов для автоматического создания компонентов классов доступа к данным и ГПИ (Веб-формы).
[0064] Уровень 103 основания приложения является набором высокоуровневых компонентов и структур базы данных, внедренных поверх уровня 101 основания системы с целью обеспечения программиста приложений готовыми к использованию компонентами и инфраструктурой для создания и расширения бизнес приложений. Используя набор 125 фреймов приложения, программист приложений может сфокусироваться на внедрении модулей бизнес логики, а затем подключить их к набору 125 фреймов приложения с целью предоставления конечному пользователю полнофункционального бизнес приложения.
[0065] Уровень 103 основания приложения обеспечивает разработчика приложений такими элементарными процедурами высокого уровня как:
[0066] Набор 125 фреймов приложения: Набор компонентов и структур базы данных, определяющий топологию приложения и перемещение по объектам. Управление 123 пользователями: Набор компонентов и структур базы данных для хранения информации пользователя и его личных настроек, таких как, вид экрана, порядок сортировки, избранное, региональные настройки, характерные для отдельного пользователя. Управление 121 безопасностью: Набор компонентов и структур базы данных для обеспечения безопасности на базе ролей и управления аутентификацией. Управление 117 версионностью: Набор компонентов и структур базы данных для обновления бизнес логики и компонентов базы данных приложения. Управление 119 индивидуальной настройкой: Набор компонентов и структур базы данных для создания, хранения и применения ГПИ, бизнес логики и метаданных базы данных, содержащих информацию о визуальных, функциональных изменениях и модификации базы данных, созданных пользователями приложения с целью изменения стандартной функциональности.
[0067] Уровень 105 приложения является набором компонентов для внедрения бизнес логики приложения. Эти компоненты внедрены программистом приложений поверх уровня 101 основания системы и уровня 103 основания приложения. Уровень 105 приложения может быть разделен на следующее:
[0068] Классы 127 доступа к данным (DAC): таблица или упаковщики веб-службы, которые отвечают за связь с базой данных или веб-службой. Классы 127 доступа к данным устанавливают поверх уровня 107 доступа к данным и уровней безопасности и авторизации.
[0069] Создание классов 127 доступа к данным происходит автоматически при помощи специального конструктора. Серверные объекты 129: класс, который создают поверх одного или более классов 127 доступа к данным с использованием модели 113 программирования приложения. Включает в себя два раздела: (i) Модель объекта, перечень включенных классов доступа к данным и их взаимосвязи, а также (и) Бизнес логика, раздел, где осуществляется программирование бизнес функциональности приложения.
[0070] Веб-формы 131: декларативное описание представления серверного объекта в ГПИ. Создание и модификация веб-форм 131 происходит автоматически при помощи специального конструктора.
[0071] Предоставить посредством веб-обозревателя ГПИ схожий с Windows, "windows подобный" набор элементов управления через модель объектов предметной области (DOM) веб-обозревателя и обеспечить эффективный способ связи между этими элементами управления и серверными объектами 129 посредством XMLHttpRequest. Это может называться моделью приложения AJAX (http://en.wikipedia.org/wiki/AJAX).
[0072] Модель программирования AJAX подразумевает использование Java Scripts, находящихся в клиентской части. Такой подход небезопасен, так как при использовании отладчика JS пользователь может получить управление кодом JS и осуществить манипулирование данными. Обладая таким знанием, приложение не может доверять каким-либо данным, отправленным клиентом. По меньшей мере, в серверной части необходимо обеспечить дупликацию всей бизнес логики и всех правил проверки данных. JS в клиентской части можно доверять только обработку проверки формата начальных данных и синхронизацию представления бизнес объекта в окне веб-обозревателя, при этом основной бизнес объект находится на сервере приложения. Вся бизнес логика и проверка данных заключена внутри серверных объектов, которые работают в серверной части, и которые не подвержены воздействию модели объектов предметной области веб-обозревателя. Это действительно только для приложений, где манипулирование
данными в пользовательской части не допустимо, как, например, в бизнес приложениях. Для более широкого круга приложений, как, например, карта Google, логика может быть перемещена в веб-обозреватель клиента.
[0073] Приложения, созданные таким образом, обеспечивают преимущества хорошей производительности относительно ненадежного и латентного интернет соединения. В ответ на эту проблематику были внедрены следующие технологии: Java Scripts перемещают в статические общие классы, которые загружают один раз при входе в систему, а затем кэшируют веб-обозревателем. Статическую HTML часть формы минимизируют так, чтобы ее размер был менее 60 кб, оставшуюся часть формы загружают при необходимости. После загрузки начальной формы, с целью минимизации сетевого трафика и улучшения времени отклика между сервером и клиентом пересылаются только измененные данные. Существует возможность достижения производительности лучшей, чем у схожих Windows приложений, доступ к которым обеспечивается посредством Citrix или удаленного рабочего стола MS, при использовании такого же соединения.
[0074] Доступ к любому приложению может быть обеспечен через веб-обозреватели, такие как Internet Explorer, Mozilla Firefox и Netscape Navigator. Также возможны и другие веб-обозреватели, как Konqueror, Safari и Opera. В целом, ГПИ, написанный так, как это описывается в настоящей заявке, поддерживает любой веб-обозреватель, который совместим с моделью объектов предметной области (DOM) Уровень 2.
[0075] Обычно серверные объекты 129 создают при каждом запросе и удаляют после выполнения каждого запроса. Состояние объекта восстанавливается и сохраняется в сеансе посредством механизма сериализации. Размер сеанса минимизирован так, чтобы хранить только измененные данные серверного объекта (вставленные, удаленные или измененные записи). Остальную часть состояния объекта извлекают из базы данных по запросу и выстраивают вокруг данных сеанса. Механизм пользовательской сериализации внедрен с целью обеспечения сериализации только значимых данных и сокращения объема служебной информации. Хэш-таблицы, ограничения, связи и индексы внутри серверного объекта создают строго по запросу, что позволяет избежать выполнения дорогостоящих операций по созданию каждого объекта.
[0076] Одним из критических аспектов предоставления приложения с моделью SaaS
является обеспечение хорошей плотности приложения. Обычно веб-приложения уже приносят выгоду в сравнении с Windows-приложениями, исполняемых посредством удаленного рабочего стола Microsoft или Citrix в силу низкого потребления ресурсов памяти и концентрации совместно используемых ресурсов. Применение платформы разработки приложений AJAX позволяет достичь даже большей плотности приложений в сравнении со стандартными веб-приложениями в силу двух факторов: Затратную операцию HTML представления осуществляют только один раз, при начальной загрузке страницы. Все последующие запросы к этой же самой странице не активируют HTML представление, что значительно снижает нагрузку на центральный процессор сервера приложений.
[0077] Обмен между клиентским приложением и серверной частью только измененными данными значительно сокращает сетевой трафик и время обработки в серверной части. Модель приложения AJAX не обеспечивает никаких указаний относительно внедрения бизнес логики. Традиционно большая часть инструментария AJAX ограничена набором javascripts, которые обрабатывают создание элементов ГПИ посредством DOM веб-обозревателя, и набором javascripts, которые обрабатывают операции с объектом XMLHttpRequest. Программист приложений несет ответственность за внедрение серверной части как набора специальных веб-служб и должен внедрить java script, который активирует эти веб-службы и осуществляет взаимодействие с элементами ГПИ на базе отклика. В этом случае бизнес логика распределена между клиентским java script и веб-службами.
[0078] Такой подход имеет следующие недостатки:
[0079] Программист приложений вынужден писать код приложения в двух местах: веб-службы в серверной части и java script в клиентской части. Это увеличивает количество ошибок и усложняет отладку и обслуживание кода. В целях предотвращения злоумышленного манипулирования данными, программист приложений должен обеспечить дублирование все критичных данных в серверной части. Во многих случаях это приводит к удвоению бизнес кода и различным ошибкам синхронизации. Воздействие на бизнес логику посредством набора специализированных API функций часто требует дублирования бизнес логики на множестве машин, что увеличивает время разработки с последующим
затратами на поддержание кода. [0080] Настоящим предлагается новый механизм, использующий ASP.NET 2.0, где XMLHttpRequest может быть выполнен в отношении начальной веб-формы, которую сгенерировала html страница. Такой механизм позволяет внедрить стандартный протокол связи обмена данными между клиентским веб-обозревателем и серверным объектом на сервере приложений. Внедрение механизма связи происходит следующим образом: изменение контрольного значения на стороне веб-обозревателя запускает через DOM веб-обозревателя исполнение статического сценария java. Такой сценарий собирает информацию относительно измененных контрольных данных и создает XML документ, содержащий изменения. Этот XML документ пересылают на сервер в форме XMLHttpRequest относительно начальной веб-формы. Сервер принимает XML документ, преобразует его для сбора данных и передает сбор данных серверному объекту, который выполняется на фоне запрашиваемой веб-формы. Заполнение элементов серверного объекта новыми значениями запускает исполнение бизнес логики. По завершении выполнения бизнес логики, изменения в состоянии серверного объекта собираются веб-формой 131. Вместо генерации отклика HTML, веб-форма 131 компилирует измененные данные в XML документ и отправляет его назад на клиентский веб-обозреватель в качестве ответа на XMLHttpRequest. Сценарий Java получает ответ сервера и обновляет элементы управления страницей, устанавливая новые значения, полученные из XML документа.
[0081] Такая технология решает следующие задачи:
[0082] Javascript, который устанавливает связь между обозревателем и сервером, является статическим. Он не содержит никакой бизнес логики. Его загружают только один раз, во время первоначальной загрузки приложения, и используют совместно всеми страницами приложения. После загрузки начальной формы, с целью минимизации сетевого трафика и улучшения времени отклика между сервером и клиентом, пересылают только измененные данные.
[0083] Связь осуществляют посредством XML документов небольшого размера, что исключает затратную операцию отображения страницы в серверной части. Программист приложений не внедряет в JavaScript никакой бизнес логики и не работает с HTML и DOM. Вся такая логика встроена на системный уровень в
рамках элементов управления веб. Всю бизнес логика программируют в одном месте, в рамках серверного объекта 129 . [0084] Фиг. 2 иллюстрирует модель динамического взаимодействия приложения. Динамические компоненты системы обеспечивают служебные функции для кода приложения во время его исполнения, включая:
- Уровень доступа к базе 210 данных,
- Проверку прав доступа и безопасность,
- Создание HTML,
- ГПИ представление в части веб-обозревателя (Java Scripts),
- Протоколы связи, а также
- Поддержку индивидуальной настройки.
[0085] Уровень 205 представления отвечает за создание ГПИ и обеспечение связи между веб-обозревателем и серверными объектами 129. Он включает в себя набор веб-форм 131. Когда пользователь запрашивает на сервере новую вебстраницу, веб-форма 131 отвечает за прием запроса и создание статической HTML части запрошенной страницы приложения, а также создание дополнительной служебной информации, требуемой для представления элементов управления AJAX. Когда пользователь получает запрошенную страницу и начинает просмотр данных или ввод данных, веб-форма 131 отвечает за получение от веб-обозревателя асинхронных HTTP запросов, восстановление состояния страницы приложения на сервере, передачу измененных контрольных значений на серверный объект в целях исполнения бизнес логики, сбор измененного состояния серверного объекта, создание ответа в форме XML документа и его отправку обратно на веб-обозреватель. Доступ к серверным объектам 129 также может быть обеспечен через общие веб-службы, которые являются частью уровня представления. В отличие от веб-форм 131, веб-службы создаются автоматически на основании информации метаданных серверных объектов 129.
[0086] Уровень 203 бизнес логики внедрен внутри серверных объектов 129. Серверные объекты 129 являются классами, отвечающими за исполнение бизнес логики в рамках пространства имен приложения. Каждый серверный объект 129 включает два раздела: (i) Модель 207 объекта, перечень 209 включенных классов 211 доступа к данным и их взаимосвязи, а также (ii) Бизнес логика 213, раздел, где
осуществляется программирование бизнес функциональности. Доступ к каждому серверному объекту 129 может быть осуществлен с уровня представления 205, а также с другого серверного объекта 129 в рамках пространства имен приложения. Когда серверный объект 129 получает запрос на выполнение, он извлекает данные, требуемые для исполнения запроса, из классов доступа к данным 211, основанных на модели объекта 207, активирует исполнение бизнес логики 213, возвращает результат исполнения бизнес логики 213 запрашивающей стороне и обновляет классы 211 доступа к данным измененными данными.
[0087] Уровень 210 доступа к данным внедряют как набор классов 211 доступа к данным. Классы 211 доступа к данным - это классы в рамках пространства имен приложения, отвечающие за связь с базой данных или веб-службой и обеспечивающие API управления данными постоянную поддержку серверному объекту 129. Классы 211 доступа к данным отвечают за проверку корректности данных, усиление целостности приложения и связь с базой данных через механизм атрибутов и обеспечивая API управления данными серверному объекту 129. API управления данными включает в себя такие элементарные процедуры, как выбор, вставка, удаление, сохранение, сортировка, поиск и доступ к другим данным, а также операции управления сохраняемостью.
[0088] Содержимое класса 211 доступа к данным включает в себя неизменяемую часть данных, которые извлекают из базы данных и сохраняют в базу данных при каждом запросе к содержимому класса 211 доступа к данным и сохраняемой части, которая содержит измененные данные. Все измененные данные сохраняют в сеансе посредством стандартного поставщика 215 сеанса, сконфигурированного для приложения .NET. Табличные кэши организованы таким образом, что из базы данных или сеанса извлекаются только те данные, которые запрошены для исполнения бизнес логики 213.
[0089] Набор элементов веб контроля используют для создания расширенного графического интерфейса пользователя внутри Интернет-обозревателя. Создание согласованного профессионального оформленного ГПИ является сложной задачей. Особое внимание, уделенное разработке ГПИ и всем элементам веб управления, поддерживает то же самое представление и внешний вид, как в режиме создания, так и в режиме исполнения. Это позволяет разработчику
использовать все средства, например, компонент Visual Web Designer программы Visual Studio. Разработчик приложений может использовать удобный механизм перетаскивания в целях создания разметки формы приложения, выполнить визуальное редактирование формы и настроить свойства управления и поведения посредством интуитивного графического интерфейса. Такой подход не требует от разработчика какого-либо знания HTML или Java Script и позволяет ему сфокусироваться на бизнес логике приложения, создавая при этом профессионально выглядящий ГПИ. [0090] Примеры, рассматриваемые далее, иллюстрируют динамическое представление относительно режима разработки, см. Фиг. 3, где проиллюстрирован экранный снимок динамического представления данных. Данные отображаются во время исполнения событий.
[0091] Фиг. 4 иллюстрирует пример экранного снимка представления данных периода разработки. Поля формы могут редактироваться или обновляться во время периода разработки.
[0092] Фиг. 6 иллюстрирует пример экранного снимка отображения данных периода создания с отключенным представлением (вид Standard Visual Studio.NET).
[0093] Представленный далее код (на языке С#) написан для обновления суммарных значений документа путем добавления новой строки документа и представляет собой пример бизнес логики, проиллюстрированной Фиг. 6: private void gltran_RowUpdated(SWCache sender, SWRowUpdatedEventArgs e) {
GLTran old = e.OldRow as GLTran; GLTran tran = e.Row as GLTran;
if (old != null & & (tran.CuryCrAmt != old.CuryCrAmt |I tran.CuryDrAmt != old.CuryDrAmt || tran.CrAmt != old.CrAmt || tran.DrAmt != old.DrAmt))
Batch batch = BatchModuleBatNbr[tran.Module,
tran.BatNbr];
if (batch != null)
batch.CuryCrTot += (tran.CuryCrAmt - old.CuryCrAmt);
batch.CuryDrTot += (tran.CuryDrAmt - old.CuryDrAmt);
batch.CrTot += (tran.CrAmt - old.CrAmt);
batch.DrTot += (tran.DrAmt - old.DrAmt);
BatchModuleBatNbr[tran.Module, tran.BatNbr] = batch;
[0094] Тот же самый результат можно получить с помощью атрибута DeltaSource:
[SWDefault(0.0)] [SWDBDouble()]
[DeltaSource(typeof(Batch), Batch.Short.CuryDrTot)] [SWUIField () ]
public virtual double? CuryDrAmt {
get { return _CuryDrAmt; } set { _CuryDrAmt = value; }
[0095] Результат исполнения данного кода проиллюстрировано на Фиг. 7 и 8, где приведен экранный снимок формы для создания нового документа и экранный снимок формы для обновления документа, соответственно.
[0096] Следующий пример кода иллюстрирует отключение элементов управления, если документ не подлежит изменениям в силу своего состояния: public void Batch_RowSelected(SWCache sender, SWRowSelectedEventArgs e) {
Batch batch = e.Row as Batch;
if (batch == null || batch.Status != "H")
SWUIFieldAttribute.SetEnabled(sender, batch, null, false); SWUIFieldAttribute.SetEnabled(sender, batch, Batch.Short.BatNbr, true);
Caches[typeof(Batch)].AllowDelete = false; Caches[typeof(Batch)].AllowUpdate = false; Caches[typeof(GLTran)].AllowDelete = false; Caches[typeof(GLTran)].AllowUpdate = false; Caches[typeof(GLTran)].Allowlnsert = false;
else {
SWUIFieldAttribute.SetEnabled(sender, batch, null,
true); SWUIFieldAttribute.SetEnabled(sender, batch, Batch.Short.Status, false);
SWUIFieldAttribute.SetEnabled(sender, batch, Batch.Short.CuryCrTot, false);
SWUIFieldAttribute.SetEnabled(sender, batch, Batch.Short.CuryDrTot, false);
SWUIFieldAttribute.SetEnabled(sender, batch, Batch.Short.Module, false);
Caches[typeof(Batch)].AllowDelete = true;
Caches[typeof(Batch)].AllowUpdate = true;
Caches[typeof(GLTran)].AllowDelete = true;
Caches[typeof(GLTran)].AllowUpdate = true;
Caches[typeof(GLTran)].Allowlnsert = true;
[0097] Результат исполнения данного кода проиллюстрировано на Фиг. 9 и 10, где представлены экранный снимок формы документа в состоянии удержания и экранный снимок формы документа в состоянии "не опубликован". [0098] Разработчику предоставлен стандартный механизм обработки множества ошибок в серверной части и возврата таких ошибок клиенту. Данная часть С# кода приводит пример обработки ошибки:
[SWUIField(DisplayName="Ledger ID")] [SWDBString(10)] [SWSelector(typeof(Ledger))]
[SWDefault(typeof(GLSetup), Ledger.Short.LedgerlD)]
-21 -
public virtual string LedgerlD {
get {
return _LedgerID;
set {
__LedgerID = value;
[SWDefault(null)] [SWUIField(DisplayName="Account ID")] [SWDBString(10)]
[SWSelector(typeof(vs AcctXref) , GLSetup.Full.Cpnyld) ] public virtual string Acct {
get {
return _Acct;
set {
_Acct = value;
[0099] Результат исполнения данного кода отображено на Фиг. 11, которая
иллюстрирует экранный снимок примера формы для документа с
недействительными значениями. [0100] Такой вариант осуществления обеспечивает программиста приложений набором
конструкторов для упрощения создания серверных объектов и веб-форм.
Создание приложения осуществляют с использованием этих конструкторов. [0101] Фиг. 12 отображает экранный снимок конструктора табличного кэша.
Конструктор табличного кэша автоматизирует создание и изменение табличного кэша. Он мог бы создавать табличный кэш на основе объекта базы данных, операторе выбора или существующего табличного кэша. Также поддерживаются виртуальные поля, которые не отображены в базе данных. [0101] Фиг. 13 отображает экранный снимок конструктора графа. Серверный объект основан на графе, который, в свою очередь, состоит из набора табличных кэшей. При создании графа программист приложений отвечает за определение табличных кэшей, которые должны быть включены в такой граф и определение их взаимосвязей и иерархии. Программист приложений также бы мог переопределить способы вставки, выбора, обновления и удаления по умолчанию для каждого табличного кэша внутри объекта графа и указать, требуется ли сохраняемость измененного экземпляра табличного кэша внутри графа между двумя циклами.
[0102] Бизнес логику внутри серверного объекта внедряют как набор функций, которые подписаны на события, активируемые объектом графа при изменении его элементов. Фиг. 14 иллюстрирует экранный снимок конструктора веб-формы. Веб-формы могут создаваться поверх серверного объекта.
[0103] Однако, добавление элементов веб управления в форму в ручном режиме, настройка свойств элементов управления и связывание элементов управления с серверным объектом, лежащим в основании, являются чрезмерно затратными по времени операциями. Синхронизация веб-формы с серверным объектом в случае изменения серверного объекта является даже более трудоемкой операцией. В целях автоматизации этого процесса был разработан конструктор веб-форм. Он считывает свойства серверного объекта и табличного кэша, и преобразует их в соответствующие элементы веб управления, задает свойства форматирования данных, надписи, ссылки и другие свойства управления по умолчанию, которые могли быть получены от серверного объекта и табличных кэшей. Программист также мог бы переопределить эти свойства по умолчанию и создать элементы управления в форме или синхронизировать элементы управления формы с текущей схемой серверного объекта.
[0104] Бизнес логику внутри серверного объекта внедряют как набор функций, которые подписаны на события, активируемые объектом графа при изменении его элементов. Старые и новые значения измененного элемента и ссылки на текущий
экземпляр графа передают функции подписки в качестве параметров. Когда программист приложений осуществляет двойное нажатие на элемент управления веб-формой, происходит выбор элемента графа, который будет модифицирован при изменении этого элемента выражением привязки. Также создают функцию, подписанную на такое событие изменения.
[0105] Ссылку на текущий экземпляр графа передают как один из аргументов. Таким образом, при написании кода функции, программист приложений мог бы получить доступ к графу посредством его модели объекта, используя принудительное установление типов.
[0106] Элементами, обладающими визуальным представлением (как статические элементы, так и динамические элементы, которые могут быть активированы при необходимости), являются указанные далее:
(1) полностью скрытые элементы,
(2) частично видимые элементы (отображение только визуальной метки). [0107] Например, таблицы с множеством элементов, которые не могут
отображаться все одновременно, попадают в эту категорию.
(3) Полностью видимые элементы, т.е. с видимым содержимым.
Алгоритм последовательности этапов при запросе элемента 2
класса является следующим:
(1) Страница загружена.
(2) Страница разобрана на элементы, каждый из которых обрабатывают на основании логики страницы и HTML форматирования кода.
(3) Элемент выбора преобразуют из элемента класса 2 в элемент класса 3, на основании получения содержимого, которое соответствует элементу класса 2.
a. При выборе или при некоторых других действиях (например, остановка перемещения курсора), создается событие для элемента класса 2, которое затем отправляется в форме запроса на сервер;
b. В серверной части запрос анализируют и для запрошенной формы создают описание HTML. Следует заметить, что форму также создают путем ссылки на базу данных, где
содержатся запрашиваемые записи и, в некоторых особых случаях, за счет преобразования записей при помощи бизнес логики. Кроме того, выбор запрашиваемых записей из базы данных также требует преобразования и обработки запроса с использованием бизнес логики;
c. Получение HTML описания запрошенной формы в веб-обозревателе, в клиентской части.
d. Обработка кода запрошенной формы, подписка на события в полученной форме, для одного или нескольких статических сценариев java в целях обработки событий;
e. Отображение полученной формы на экране.
[0108] Если определенный элемент формы изменяет свое значение, или элемент на ее веб-странице изменяет значение, что может привести к изменению записи базы данных, или если определенный элемент обладает связью, обеспеченной бизнес логикой, с другим элементом веб-страницы, то значение такого элемента можно проверить на удаленном сервере. В этом случае, введенное, или выбранное из контекстного меню, значение передают на сервер, где в отношении значения элемента применяют бизнес логику, основанную на бизнес логике пользователя.
[0109] После обработки на сервере значения элемента и обнаружения ошибки, веб-обозреватель пользователя может получить данные для исправления текущей веб-страницы. В результате некоторые элементы на странице могут изменить свои свойства, например, может измениться цвет фона, где было введено приемлемое значение.
[ОНО] Фиг. 15 иллюстрирует снимок экрана, где отображена закладка "Общая информация" вместе с ее содержимым, в то время как пользователь открывает поле "место доставки", которое изначально было представлено закладкой. Курсор установлен на закладку "место доставки" и при нажатии на нее создаются события. Одно из событий открывает изначально пустое поле (см. Фиг. 16), в то время как другое событие формирует запрос к содержимому поля, который отправляется на сервер.
[0111] Для того чтобы получить содержимое поля "место доставки", производят обмен данными с сервером. Пока сервер обрабатывает запрос и формирует HTML описание запрошенной формы на экране, вместе с закладкой, для поля места
доставки отображается незаполненное пространство. Следует заметить, что место доставки - это элемент класса 2.
[0112] Фиг. 17 отображает снимок экрана того, что случается после получения клиентом описания HTML и обработки полученного содержимого с использованием веб-обозревателя и сценариев java. На экране отображено содержимое поля "место доставки", иными словами, веб-обозреватель отображает элементы класса 3, например, строки "строка адрес 1", "строка адрес 2", "строка адрес 3" и т.д., которые все являются элементами класса 3.
[0113] Фиг. 18 и Фиг. 19 иллюстрируют другой вариант осуществления изобретения. Фиг. 18 отображает экранные снимки счетов главной книги. Для того чтобы ввести данные в поле строки с названием "СУБ Сч.кОплате", существует возможность использования таблицы допустимых значений. Таблица сформирована сервером, на основании содержимого полей бизнес объекта, которые уже был заполнен. Свойства объекта определены записями базы данных и бизнес логикой. Для того чтобы выбрать таблицу, пользователь нажимает на метку "увеличительное стекло". При нажатии создается событие, которое отправляет запрос серверу на записи таблицы. Следует заметить, что перед получением данных для таблицы от сервера, экран пользователя может и не измениться. В одном определенном случае второе событие может создать сообщение (которое не показано на фигурах) в целях информирования пользователя о том, что запрос был отправлен, и что он обрабатывается. Сервер, используя данные, доступные в базе данных, и в бизнес логике, создает данные для заполнения таблицы, соответствующий код HTML, и отправляет это на веб-обозреватель пользователя.
[0114] Как проиллюстрировано на Фиг. 19, за счет использования веб-обозревателя в клиентской части происходит обновление формы, где код включает в себя события. В этом случае, после обработки визуального представления запроса, относящегося к строке "СубСч.кОплате", отображается содержимое таблицы. Элементы закладки "Счета главной книги" и представляемая таблица принадлежат к элементам класса 3. Таблица также может включать в себя элементы класса 2. В таком случае, это были бы номера страниц таблицы, что необходимо для быстрого поиска в таблице, так как не все содержимое таблицы может быть представлено при нажатии на увеличительное стекло.
[0115] Фиг. 20 отображает другого снимок экрана, где в данном конкретном случае, введенные или выбранные (пользователем) данные могут не соответствовать требованиям бизнес логики, формата, или быть наследственно ошибочными. В описанном ранее примере поля таблицы создают на основании данных, размещенных на сервере, что означает, что записи, измененные пользователем и еще не переданные на сервер, могут не приниматься во внимание при создании полей для выбора пользователем. Например, на закладке "Общая информация" заполнены основные поля, экранный снимок демонстрирует элементы класса 2, как, например, другие закладки "Информации об оплате", "Другое место", "Контакты" и "Счета главной книги". При запросе пользователя эти элементы могут быть преобразованы в элементы класса 3.
[0116] Фиг. 21 отображает пример экранного снимка с уведомлением об ошибке для пользователя. Когда пользователь пытается сохранить новые данные в рамках закладки "Общая информация", и создать новый бизнес объект, например, бухгалтерскую проводку, это оказывает влияние на другие элементы, в частности, элементы на закладке "Информация о платежах". Фиг. 7 иллюстрирует, как в текущем окне (см. также Фиг. 20) отображено другое окно, которое уведомляет пользователя об ошибке, и определяет поле, в котором произошла ошибка. А также, в дополнение к уведомлению пользователя с помощью окна, были изменены свойства строки соответствующей закладки. Это оказывает влияние на закладку, которая обладает элементами, конфликтующими с только что введенными данными. Изменение свойств закладки также ведет к появлению символа, в данном случае, восклицательный знак внутри окружности красного цвета, который также информирует пользователя об ошибке.
[0117] Таким образом, с описанием различных вариантов осуществления системы и способа специалистам в данной области техники понятны определенные достигнутые преимущества описанного способа и системы. В частности, специалистам в данной области техники ясно, что использованы одинаковые атрибуты с несколькими обработчиками. А также, специалистам в данной области техники ясно, что технология активных записей использует атрибуты вместе с названным способом, но не требует полного взаимодействия со способом.
[0118] Также ясно, что различные модификации, адаптации и альтернативные варианты
осуществления настоящего изобретения могут быть выполнены в пределах объема и сущности настоящего изобретения. Настоящее изобретение определяется следующей далее формулой изобретения.
Формула изобретения:
1. Способ управления динамическим содержимым веб-сайта, при этом способ включает:
создание статического содержимого, назначенное для динамического содержимого веб-сайта, причем статическое содержимое веб-сайта включает неизменяемые сценарии в клиентской части;
создание активного содержимого для обработки динамического содержимого, причем активное содержимое включает первый набор элементов, скрытых от пользователя и второй набор элементов, которые в веб-обозревателе выполнены только в виде визуальных меток;
передачу статического содержимого пользователю при запросе;
выбор, в ответ на пользовательскую команду, ссылок на активное содержимое в рамках статического содержимого;
запрос на удаленном сервере описания активного содержимого;
передачу активного содержимого пользователю;
отображение на экране активного содержимого, как части статического содержимого;
редактирование динамического содержимого с использованием активного содержимого, причем динамическое содержимое включает визуальное представление данных, запрошенных пользователем;
представление пользователю первой формы документа, созданной на основе HTML представления данных удаленного сервера и неизменяемых сценариев, причем первая форма документа включает первый и второй набор элементов, выполненных с возможностью создания события;
создание, в процессе редактирования активного содержимого, запроса на удаленный сервер в отношении данных удаленного сервера, требуемых для текущей визуализации первой формы документа;
создание на удаленном сервере второго представления соответствующих данных второй формы документа на основании редактирования;
передача второго представления соответствующих данных для отображения в веб-обозревателе; и
сохранение соответствующего содержимого веб-сайта на удаленном сервере и
обеспечение его общей доступности на удаленном сервере.
2. Способ по п. 1, дополнительно содержащий кэширование статического и активного содержимого в виде согласованной страницы.
3. Способ по п. 1, в котором HTML представление создают для видимой части формы документа, сформированной веб-обозревателем.
4. Способ по п. 1, в котором данные и элементы принадлежат модели объекта DOM2.
5. Способ по п. 1, дополнительно содержащий:
присваивание неизменяемых сценариев обработке динамических данных;
создание на удаленном сервере, при запросе пользователем веб-обозревателя на представление элемента, HTML представления, относящегося к видимой части данных, соответствующих запросу пользователя;
передачу HTML представления в веб-обозреватель;
структурный анализ HTML представления, с использованием веб-обозревателя;
подписку неизменяемых сценариев на события, созданные HTML представлением.
6. Способ по п. 1, дополнительно содержащий:
обновление элемента новым значением с использованием веб-обозревателя; передачу нового значения на сервер;
используя логику сервера, определение условия, нуждается ли новое значение в изменении;
если новое значение требует изменения, создание и использование в веб-обозревателе обновленного HTML представления с обновленным элементом из второго набора элементов;
причем обновленный элемент из второго набора элементов указывает на то, что элемент требует изменения; и
изменение, в веб-обозревателе, представления визуальной метки элемента из второго набора элементов на обновленный элемент из второго набора элементов.
7. Способ по п. 6, в котором новое значение требует изменения в случае обнаружения ошибки логики.
8. Способ по п. 1, в котором обновление данных удаленного сервера осуществляют как атомарную транзакцию.
7.
-309. Способ по п. 9, в котором атомарную транзакцию совместно используют множество пользователей.
10. Способ по п. 1, в котором содержимое веб-сайта сохраняют в виде данных удаленного сервера.
11. Способ по п. 1, в котором содержимое веб-сайта сохраняют в виде HTML представления.
12. Способ по п. 1, в котором сохранение осуществляется различными пользователями в виде транзакции.
13. Способ по п. 1, в котором редактирование включает в себя операции перетаскивания.
14. Способ по п. 1, в котором редактирование включает в себя редактирование визуальной формы.
15. Способ по п. 1, в котором редактирование включает в себя настройку свойств управления.
16. Способ по п. 1, в котором редактирование включает в себя настройку действия управления.
17. Способ представления динамических данных в сети, в котором
компьютерная сеть обеспечивает подключение удаленного сервера к клиентской ЭВМ,
при этом на клиентской ЭВМ имеется веб-обозреватель, способный к созданию и
представлению динамических форм на основании данных, относящихся к модели
объекта, причем HTML представление содержит данные для модели объекта, причем
форма содержит данные для представления объекта и неизменяемых сценариев, при
этом данный способ включает:
чтение и использование, на клиентской ЭВМ, HTML представления;
регистрацию проанализированных объектов в модели объекта и подписку набора неизменяемых сценариев на события модели объекта;
представление пользователю формы документа, созданной на основе HTML представления данных и неизменяемых сценариев, при этом форма документа включает в себя элементы класса 1 и 2 , сконфигурированных с целью осуществления создания события;
при этом элементы класса 1 скрыты от пользователя, а элементы класса 2 выполнены в веб-браузере в виде визуальных меток;
при вводе пользователем данных, создание запроса на сервер в отношении
элемента 2 класса;
создание и сохранение на сервере второго представления соответствующих данных дополнительной формы;
передачу второго представления соответствующих данных в веб-обозреватель;
анализ, в веб-обозревателе, второго представления соответствующих данных и подписка неизменяемых сценариев на события второго представления соответствующих данных; и
представление пользователю, внутри формы, переведенных элементов класса 2 на основании второго представления соответствующих данных.
18. Способ по п. 17, в котором HTML представление создается для представления видимой части формы документа, сформированной веб-обозревателем.
19. Способ по п. 17, в котором модель объекта - это модель объекта DOM2.
20. Способ по п. 17, дополнительно содержащий:
присваивание неизменяемых сценариев обработке динамических данных;
при запросе пользователем веб-обозревателя на представление объекта, создание HTML представления, относящегося к видимой части данных, соответствующих запросу пользователя;
передачу HTML представления в веб-обозреватель;
структурный анализ HTML представления, с использованием веб-обозревателя; подписку неизменяемых сценариев на события, созданные HTML представлением.
21. Способ по п. 20, дополнительно содержащий:
обновление объекта новым значением с использованием веб-обозревателя; передачу нового значения на сервер;
определение, используя логику сервера, условия, нуждается ли новое значение в изменении;
если новое значение требует изменения, создание и передача в веб-обозреватель обновленного HTML представления с обновленным элементом 2 класса;
причем обновленный элемент 2 класса указывает на то, что объект требует изменения; и
изменение представления, в веб-обозревателе, визуальной метки элемента класса 2 на обновленный элемент класса 2.
22. Способ по п. 20, в котором новое значение требует изменения в случае
22.
определения ошибки логики.
23. Постоянное запоминающее устройство, которое может быть использовано на ЭВМ, содержащее программную логику для исполнения процессором, причем программная логика содержит в себе код программы для ЭВМ для реализации этапов по п. 1.
24. Система представления динамических данных в сети, при этом компьютерная сеть обеспечивает подключение удаленного сервера к клиентскому компьютеру, в котором содержится веб-обозреватель, способный к созданию динамических форм и представления на основании данных, относящихся к модели объекта, и включая HTML описание формы с использованием данных для представления объекта и неизменяемых сценариев, причем данная система содержит:
на клиентской ЭВМ, средства для чтения и анализа HTML описания; и
на клиентской ЭВМ, средства регистрации проанализированных объектов в
модели объекта и подписку набора неизменяемых сценариев на события модели
объекта;
средства представления пользователю формы документа, созданной на основе HTML описания и неизменяемых сценариев, при этом форма документа включает в себя множество элементов, сконфигурированных с целью осуществления создания события;
причем, по меньшей мере, несколько элементов скрыты от пользователя, и, по меньшей мере, несколько элементов обладают только представлением в виде визуальных меток в веб-обозревателе, и, по меньшей мере, несколько элементов являются визуальным представлением данных объекта, запрошенных пользователем;
при вводе пользователем данных, средства создания запроса на сервер в отношении элемента с представлением в виде визуальной метки;
на сервере, средства создания второго представления соответствующих данных дополнительной формы;
средства обеспечения второго представления соответствующих данных для отображения в веб-обозревателе;
в веб-обозревателе, средства анализа второго представления соответствующих данных и подписка неизменяемых сценариев на события второго представления соответствующих данных; и
внутри формы, средства представления пользователю элемента с
представлением визуальной метки, переведенного в визуальное представление данных объекта, созданных на основе второго представления соответствующих данных.
25. Система по п. 24, в которой HTML описание создают для представления видимой части формы, сформированной веб-обозревателем.
26. Система по п. 24, дополнительно содержащая:
присвоенные неизменяемые сценарии в веб-обозревателе для обработки динамических данных;
при запросе пользователем веб-обозревателя на представление объекта, средства для создания HTML описания, относящегося к видимой части данных, соответствующих запросу пользователя;
передачу HTML описания формы в веб-обозреватель;
структурный анализ HTML описания, с использованием веб-обозревателя;
подписку неизменяемых сценариев на события, созданные HTML описанием.
27. Система по п. 26, дополнительно содержащая:
обновление объекта новым значением с использованием веб-обозревателя; передачу нового значения на сервер;
используя логику сервера, определение условия, нуждается ли новое значение в изменении;
если новое значение требует изменения, создание и передачу в веб-обозреватель обновленного HTML описания с обновленным элементом, выполненным в виде визуальной метки;
причем обновленный элемент с представлением визуальной метки указывает на то, что объект требует изменения; и
в веб-обозревателе, изменение представления визуальной метки элемента с представлением визуальной метки на обновленный элемент с представлением визуальной метки.
Серверные объекты
Модель программирования приложения
Классы доступа к данным
Уровень безопасности и авторизации
Управление пользователями
Управление безопасностью
Уровень доступа к данным
Управление индивидуальной настройкой
Управление версионностью
Уровень основания системы
Уровень основания приложения
ФИГ.1
Веб-форма
Формы Window
Упаковщик общей веб-формы
роваидер источи данных
ика^
Уровень представления
Серверный объект (Уровень бизнес логики)
/Бизнес логика (активация событием)
> | Ссылка РАС |
-Объект вставленный -Объект выбранный -Объект обновленный -Объект удаленный -Строка вставленная -Строка выбранная -Строка обновленная -Строка удаленная -Файл обновлен
Уровень доступа к данным
Классы доступа к данным
Провайдер базы данных
Классы доступа к данным (постоянный объект базы данных)
Классы доступа к данным (временный объект базы данных)
Провай
дер сеанса
Провайдер веб-службы
Классы доступа к данным (постоянный объект веб-службы)
Классы доступа к данным (временный объект веб-службы)
ФИГ.2
нх| к*- M I(c)
Журнал Транзакций (ID данного экрана: 00.01.01)
(r)
Модуль: Номер: Журнал: Тип: Период:
Разовый
05-2006
Статус: | Не завершено | v"| Обработка: | Никаких действ^иу |
J ID Книги:
] ?
Авт. ссылка № Авто Сторно
Текущий цикл: Количество циклов: Нач. партия №: Контроль: Итого по дебиту: Итого по кредиту:
0,00
0,001
0,001
х И
(r)
0,00 |
0,00 |
0,00 |
Счет:
ОЕЬубсчет:
1ата:
(Ц}ебит:
ал юта: ЕЬтатья №
|Щ Вторник, Июнь]
1> 1 о"оо]
В-I
ег.номер:
редит:
Щстатус сверки: оплате
0,00
Расчет
Отмена
Журнал Транзакций (ID данного экрана: 00.01.01)
(r)
Ш Модуль: |"] |
Цстатус:
Ц?балансирован <| v
J Ш"екущий цикл:
(Зномер: liJ
^|ц|бработка: ЦДЦникаких действ|^
"1 Шсоличество циклов:
Шкурнал: |*J
| ЙЬ Книги: |"1
1 &ач партия №:
Шгип: I ([ЗЕ^гулирование
Авт. ссылка №
j (контроль:
0,00 |
Иериод: i 1^1
1 г
Авто Сторно
01того по дебиту:
0,00 |
Истого по кредиту:
0,00 |
модуль: [ ] Е^омер: йурнал: Йип: Шериод:
егулировани
рЬбработка: | [Никаких действ1|йу | Ек
Книги:
Авт. ссылка №
IjJ | Авто Сторно
] Щнач. партия №: ГЛСОНТРОЛЬ: ГД|того по дебиту! ЕЬтого по кредиту!
0,00 |
0,001
0,00 |
^чет:
Цата:
Щ\е6\лт. ал юта:
1*| Вторник, Июнь"]
Ц| "goo]
в-I
Ч^убсчет:
редит:
0,00
Расчет! v
Нтатья №: i W 0|
оплате
Да v
ФИГ. 6
Журнал Транзакций (ID данного экрана: 00.01.01)
(r)
Модуль: Номер: Журнал: Тип: Период:
Разовый
05-2006
Статус: | Не завершено | v"|
^Обработка: | Никаких действие] у ]
] ID Книги: | Действующая |
Авт. ссылка № Авто Сторно
Текущий цикл: Количество циклов: Нач. партия №: Контроль: Итого по дебиту: Итого по кредиту:
12,00 |
0 00
Модуль: Номер: Журнал: Тип: Период:
| Разовый"
| 05-2006
Статус: | Не завершено | v |
ID Книги:
J Обработка: | Никаких действий] у**|
Действующая {
Авт. ссылка № Авто Сторно
Текущий цикл: Количество циклов: Нач. партия №: Контроль: Итого по дебиту: Итого по кредиту:
12,00
0,00
12,00
Модуль: Номер: Журнал: Тип: Период:
000220
Разовый
05-2006
Статус: | Сбалансированс | "У
"Действующая
]Обработка: | Никаких действий у"| ID Книги:
Авт. ссылка № Авто Сторно
Текущий цикл: Количество циклов: Нач. партия №: Контроль: Итого по дебиту: Итого по кредиту:
234234
123,00
123,00
123,001
Счет
Суб
Дата
Сумма по кредиту:
Сумма по дебиту:
Валюта
Описание
Статус сверки
К оплате
1234
0000
5/29/2006
120,00
0,00
BAS
Тест
1234
0000
5/29/2006
0,00
120,00
BAS
datatesr
Задолженность
Нет
1234
0000
5/29/2006
3,00
0,00
BAS
Задолженность
Нет
1234
0000
5/29/2006
0,00
0,00
BAS
testinesdf
Расчет
ФИГ. 9
Модуль: Номер: Журнал: Тип:
Период:
000223
J Обработка:
| ГК ~| Статус: | Не проведено | У~|
ID Книги:
Никаких действий у |
Разовый
Действующая
0Ь 2006
Авт. ссылка № Авто Сторно
Текущий цикл: Количество циклов: Нач. партия №: Контроль: Итого по дебиту: Итого по кредиту:
231321
3 13
300.151
300,15
300,15 |
Гт=П ^
Счет
Суб
Дата
Сумма по кредиту:
Сумма по дебиту:
Валюта
Описание
Статус сверки
К оплате
1234
0000
5/29/2006
1213,15
0,00
BAS
данные
Задолженность
1234
0000
5/29/2006
0,00
123,15
BAS
есть данные
Задолженность
1234
0000
5/29/2006
32,00
0,00
BAS
Тест
Задолженность
1234
0000
5/29/2006
0,00
12,00
BAS
53w5
Задолженность
1234
0000
5/29/2006
0,00
20,00
BAS
234324
Задолженность
1234
0000
5/29/2006
22,00
0,00
BAS
234324
Задолженность
1234
0000
5/29/2006
0,00
22,00
BAS
данные теста
Задолженность
1234
0000
5/29/2006
123,00
0,00
BAS
Именно так
Задолженность
1234
0000
5/29/2006
0,00
123,00
BAS
Еще один
Задолженность
Журнал Транзакций (ID данного экрана: 00.01.01)
(r)
Модуль: Номер: Журнал: Тип: Период:
Разовый
05-2006
Статус:
Не завершено
^Обработка: | Выпуск немедленДну**|
ID Книги:
| Действующая
Авт. ссылка № Авто Сторно
Текущий цикл: Количество циклов: Нач. партия №: Контроль: Итого по дебиту: Итого по кредиту:
13,00
12,001
12,00 |
Счет
Суб
Дата
Сумма по кредиту:
Сумма по дебиту:
Валюта
Описание
Статус сверки
К оплате
Per. №
1234
0000 6/6/2006
12,00
0,00 BAS Тест Задолженность Да
4534
0000 6/6/2006
0,00
12,00 BAS Тест Задолженность Да
ФИГ. 11
Свойства Имя таблицы:
КГТран
[Присоединить атрибут flH^J
Имя класса: Область имен:
КГТран
| Пример ПО
13 Стр.№
(3 Модуль
13 Сч
Р> Датаприл.
Баланс &Тип
И ГОБаз.Вал.
13 Курс.Вал.
[3 ТипВал.
? Дб.Сум.
Прог.Кр.
I-J ЮСотрудника
13 13
Вн.Рег.№
Налог.Пер.
ЛогЕдПольз.
ШПрим.
Перв.Сч.
Перв№
Перв.Суб.
ПКФлаг
ПкСтатус
НаЗап..
НаПров.
|7| Проведено
|2J PioiecdO
Рег.№
" Опц.СторноЗап.
Активный
Атрибут
Конструктор
Строка Б^чГ
SWDBString
По умолчан* V
SWDefault
Поле ПИ | V
SWUI Field
Связи Род. Вид:
|Партия
Активный
Доч.Ключ
Род. Ключ:
Модуль | V
Модуль | V |
Парт.№ | ^
Парт.№ | V |
[ Создать ] [ Отмена ]
Редактор иерархии:
Сотрудник СотрудникРУ ГОНастр.ГК Главная книга Модуль Парт. Мод.Парт.РУ Мод.Парт.ПаНом.Парт. ГКТран
ГКТран.Мод.Парт. ГКТран.Мод.Парт. &Атр№ в зав.ОбщХрегГОКомпан. в зав.СубХрег.ГОКомпан.
шш нх
П Мод.Парт
? ГКТран.
в зав
С tWper.IDKoMnaH. в зав.СубХрегГОКомпан. Главная книга -ШНастр.ГК
Данные Баз.Тип
ВидИмя ЮНастр.ГК ТекстКоманды ТолькоЧтение Ложь Параметры (Сбор) Поиск (Сбор) ТипВыз.Пол. Настр.Гк ИмяВида ГОНастр.ГК
Базовый тип
[ ОК ] [ Отмена )
Редактор схемы полей
ИДИМЫй|^| ^^реместитьвверх^ Переместить вниз ВыбрЭТЬ ВСв ОЧИСТИТЬ В^брЭННОе Отображение
Поле данных |
Тип данных
| Тип управления
Надпись
Модуль
Строка
Текст. Ред
Парт.№
Парт.№
Строка
Выбор
Ав. Сторно
Авт.Сторн.
Цел 16
Числ.Ред
Авт.СторноКоп.
Авт.Сторн.Ко Цел 16
Числ.Ред
Тип баланса
Тип баланса
Строка
Текст.Ред
Тип Партии
Вал.Кр.Итого Строка
Комб.Сп.
Вал.Д.Итого
Вал.Расч.Итог Двойн.
Числ.Ред
Вал.Д.Итого
Двойн.
Числ.Ред
Цикл
121
Цикл
Двойн.
Числ.Ред
Тип журнала
ТипЖурн.
Цел 16
Текст.Ред
ID книги
ГОГлав.Кн.
Строка
Выбор
Цикл №
Цикл№
Вн.вид
Надпись Парт.№ П СписокПол Мае.Строк [1] Парт.№ [2] Статус
Действие
Имя вида
Имя вида объекта, связанное с полем.
^ Столбц. эл. упр. -.
Счетчик столб.I3 I Счетчик эл.упрро"!
f Расп. эл. упр.
1100 |
Расст. меиеду метками: | 100 | Ширина эл. упр.:
Верт. смещ.: I28 Гориз.смещ.: |8
| Создать связующее выражение
[ ОК ) [ Отмена )
Отмена
зВставить Ю^охранитьХ Удалить |^]ервый Пред. Далее ^jlc-следний
формация о счете
ID Счета. Имя Счета:
TESTVENDOR
Test Vendor
Статус:
Активный
Общая информация
Информация об оплате
Место доста
Другое место
Контакты
Счета ГК
Информация об адресе
Адрес: Город: Страна: Штат-Почтовый индекс:
Address Line
США
Нью-Йорк
Соединенные Штаты
Америки | Р| Нью-Йорк
rzz:
По умолча^ри | по умолчанию TST тест | ВКЛ | р\ Ontario
ВКЛ
23456-789
ФИГ. 15
Поставщик
ПроектХ > Счета кредиторов
_ ID экрана: АР.20.20.20
На^ин уровень в^^" обновить ^ выход (^)справка
Поставщик
ПроектХ > Счета кредиторов
На^ин уровень в|^^ обновить ^ выход
Справка
Информация об адресе
|^/| Как и основное
Адрес: Город: Страна: Штат:
Почтовый индекс:
Address Line
США
Нью-Йорк
| р| Соединенные
Штаты Америки | Р| Нью-Йорк
Информация о месте ID места:
Описание:
Налоговая зона №:
ИНН №:
ID Per. по умолчанию: 000001
Основное место:
Поставщик
ПроектХ > Счета кредиторов
_ IU
На^ин уровень в|^^ Обновить ^
[б) Отмена Щ\вставить[|||охранитьХ Удалить Ц^рвый^ Пред. ^ Далее ^|о
следнии
Q Инфор
мация о счете
ID Счета: Имя Счета:
|TEST900001 |Р|
Test Vendor 2345
Статус: [
Активный
Общая
информация
информация об
ПППЯТЙ
Место доставки
Другое место
Контакты
Счета ГК
Счета и Субсчета
Счет кредиторов:
Субсчет кредиторов:
Счет расходов: Субсчет расходов:
Счет дисконтирования: Субсчет
дисконтирования:
Поставщик
_ ID экрана: АР.20.20.20
На^ин уровень в^^* обновить ^ выход (^)справка
Субсчет
Описание
Счета и Субсчета
Счет кредиторов:
Субсчет кредиторов:
Счет расходов: Субсчет расходов:
Счет дисконтирования: Субсчет
дисконтирования: 0000-FC-VR00-44 0000-MA-ZR00-14 0000-DE-VR30-36 0000-FC-VR00-00 0000-KN-VR00-44 0000-RS-VR00-44 0000-FC-VR00-44 0000-KD-VR00-44
Субсчет 5 Субсчет 2 Субсчет 16 Субсчет 8 Субсчет 35 Субсчет 112 Субсчет 23 Субсчет 50
Информация об адресе
Адрес: Город: Страна: Штат:
Почтовый индекс:
Контактная информация
Приветствие
Телефон:
Address Line
США
Нью-Йорк
| р| Соединенные
Штаты Америки I Р| Нью-Йорк
Test Vendor
+1(203)234-2342
Параметры Счета Род. запись:
Класс поставщика:
Условия:
Налоговая зона
ИНН №: Код валюты:
| | Оплата на Род.Запись ГИГ
y..^r,,,- j,Pl ПО
ВКЛ
123456-789
|вкл |Р|
|TST |Р| тест I Р| Ontario
{1 Разрешить отмену валюты
g Отмена Е^^Эставиты30ХРанит^ Удалить Цервый^^ Пред. ДалееПоследний
Г"*) Информация о счете
TESTVENDOR
Статус: [
Активный
Имя Счета:
Test Vendor
иощая информация
информация об
ПППЯТР.
Место доставки
Другое место
Контакты
Счета ГК
Информация об адресе
Адрес: Город: Страна: Штат:
Почтовый индекс:
Параметры Счета Род. запись:
Класс
поставщика
| | Оплата на Род.Запись
TST |Р| тест I PI Ontario
lyiinmrJiffl Поумопч^ни
Штаты Америки
ВКЛ
Сообщение страницы http://192.168.1.110
Контактная информация
Приветствие
Телефон:
Test Ver
+1(203)234-2342
ВКЛ
23456-789
ну валюты
А. КЛАССИФИКАЦИЯ ПРЕДМЕТА ИЗОБРЕТЕНИЯ: Согласно международной патентной классификации (МПК)
G06F9/44 (2006.01)
Б. ОБЛАСТЬ ПОИСКА:
Минимум просмотренной документации (система классификации и индексы МПК) G06F 9/00-9/44, 15/00-15/16, 17/00-17/30, 3/00-3/048
Другая проверенная документация в той мере, в какой она включена в область поиска:
В. ДОКУМЕНТЫ, СЧИТАЮЩИЕСЯ РЕЛЕВАНТНЫМИ
Категория*
Ссылки на документы с указанием, где это возможно, релевантных частей
Относится к пункту №
А А А
US 7979431 В2 (TERADATA US, INC.) 12.07.2011
US 2011/0113341 Al (MICROSOFT CORPORATION) 12.05.2011
US 2005/0102284 Al (CHANDRAMOULI SR1NIVASAN et al.) 12.05.2005
1-27 1-27 1-27
последующие документы указаны в продолжении графы В
данные о патентах-аналогах указаны в приложении
* Особые категории ссылочных документов:
"Л" документ, определяющий общий уровень техники
"Е" более ранний документ, но опубликованный на дату подачи евразийской заявки или после нее
"О" документ, относящийся к устному раскрытию, экспонированию и т.д.
"Р" документ, опубликованный до даты подачи евразийской
заявки, но после даты испрашиваемого приоритета "D" документ, приведенный в евразийской заявке
"Т" более поздний документ, опубликованный после даты приоритета и приведенный для понимания изобретения
"X" документ, имеющий наиболее близкое отношение к предмету
поиска, порочащий новизну или изобретательский уровень,
взятый в отдельности "Y" документ, имеющий наиболее близкое OTHOI
поиска, порочащий изобретательский уровень в сочетании с
другими документами той же категории
" &" документ, являющийся патентом-аналогом
"L" документ, приведенный в других целях
Дата действительного завершения патентного поиска:
28 июня 2013 (28.06.2013)
Наименование и адрес Международного поискового органа: Федеральный институт промышленной собственности
РФ, 123995,Москва, Г-59, ГСП-5, Бережковская наб., 30-1.
Факс: 243-3337, телетайп: 114818 ПОДАЧА
Телефон №(495) 531-6481
Л.М. Цобан
-1 -
-1 -
(19)
-1 -
-1 -
(19)
-1 -
-1 -
(19)
-2-
-12-
-12-
- 13 -
- 13 -
- 14-
- 14-
-16-
-16-
- 17-
- 17-
-20-
-23 -
-23 -
-24-
-24-
-31 -
-32-
ФИГ. 4
ФИГ. 4
ФИГ. 4
ФИГ. 4
ФИГ. 4
ФИГ. 4
ФИГ. 4
ФИГ. 4
ФИГ. 4
ФИГ. 4
ФИГ. 5
ФИГ. 5
(r)
Журнал Транзакций (ID данного экрана: 00.01.01)
(r)
Журнал Транзакций (ID данного экрана: 00.01.01)
(r)
Журнал Транзакций (ID данного экрана: 00.01.01)
(r)
Журнал Транзакций (ID данного экрана: 00.01.01)
ФИГ. 10
ФИГ. 10
ВНЕ
В Генератор класса
ВНЕ
В Генератор класса
ФИГ. 12
ФИГ. 12
ВНЕ
В Генератор класса
ВНЕ
В Генератор класса
ФИГ. 12
ФИГ. 12
ВНЕ
В Генератор класса
ВНЕ
В Генератор класса
ФИГ. 12
ФИГ. 12
ВНЕ
В Генератор класса
ВНЕ
В Генератор класса
ФИГ. 12
ФИГ. 12
ФИГ. 13
ФИГ. 13
ФИГ. 13
ФИГ. 13
ФИГ. 13
ФИГ. 13
ФИГ. 14
ФИГ. 14
ФИГ. 14
ФИГ. 14
ФИГ. 14
ФИГ. 14
ФИГ. 14
ФИГ. 14
ID экрана: АР.20.20.20
ID экрана: АР.20.20.20
ФИГ. 17
ФИГ. 17
ID экрана: АР.20.20.20
ID экрана: АР.20.20.20
ФИГ. 17
ФИГ. 17
ПроектХ > Счета кредиторов
ФИГ. 18
ФИГ. 19
ПроектХ > Счета кредиторов
ФИГ. 18
ФИГ. 19
ПроектХ > Счета кредиторов
ФИГ. 18
ФИГ. 19
ПроектХ > Счета кредиторов
ФИГ. 18
ФИГ. 19
ПроектХ > Счета кредиторов
ФИГ. 18
ФИГ. 19
ПроектХ > Счета кредиторов
ФИГ. 18
ФИГ. 19
ПроектХ > Счета кредиторов
ФИГ. 18
ФИГ. 19
ПроектХ > Счета кредиторов
ФИГ. 18
ФИГ. 19
ПроектХ > Счета кредиторов
ФИГ. 18
ФИГ. 19
ПроектХ > Счета кредиторов
ФИГ. 20
ФИГ. 19
ПроектХ > Счета кредиторов
ФИГ. 20
ФИГ. 19
ФИГ. 21
ФИГ. 21
ФИГ. 21
ФИГ. 21
ФИГ. 21
ФИГ. 21
ФИГ. 21
ФИГ. 21
ФИГ. 21
ФИГ. 21
ФИГ. 21
ФИГ. 21