实体交互的自动用户界面生成的制作方法

专利名称：实体交互的自动用户界面生成的制作方法
技术领域：
本发明涉及实体交互的自动用户界面生成。
背景技术：
通常，软件应用，以及尤其是行业(LOB)应用表示各种自然的数据对象(也称为实 体)。例如，在行业(LOB)应用中，客户、订单、产品、以及发票是需要被创建并操作的实体的 示例。由于应用能用于多个不同的部署，对各个独立的应用以及应用要在其上运行的各个 类型的设备设计并创建用户界面。由此，开发者必须为那些实体类型中的每一个创建特定 的图形用户界面。这是消耗时间的并且是相当重复的任务。然而，如果不是必须创建实体 特定的用户界面，应用可被更快地创建。概述下面提供了简化的概述，以便提供对此处所描述的一些新颖实施例的基本理解。 本概述不是详尽的概述，并且它不旨在标识关键/重要元素或描绘本发明的范围。其唯一 的目的是以简化形式呈现一些概念，作为稍后呈现的更详细描述的序言。揭示的架构通过提供能自动地创建应用的用户界面(UI)的片断的引擎，允许开 发者更快地创建应用。引擎能将实体或任何实体类型的实例作为输入，并创建一允许应用 的用户查看并修改实体的UI作为输出。架构也促进了元数据和源实体的关联来引导引擎 决定；决定诸如引擎选择哪些UI控件来表示实体属性，向实体提供了多少“区域(real estate)，，(UI空间)，以及如何放置UI控件。此外，应用允许用户与已知的实体类型进行交互，但也允许与在应用设计时所未 知的类型进行交互。换句话说，应用(例如，行业)能够处理动态生成的随机实体。为了为实现上述及相关目的，本文结合下面的描述和附图来描述某些说明性方 面。这些方面指示了可以实践本文所公开的原理的各种方式，所有方面及其等效方面旨在 落入所要求保护的主题的范围内。结合附图阅读下面的详细描述，其他优点和新颖特征将 变得显而易见。附图简述

图1示出了根据所公开的架构的计算机实现的界面生成系统。图2示出了由引擎组件展示的实体信息。图3示出了能用于创建UI的属性元数据的实例。图4示出了使用多个引擎生成不同UI的系统。图5示出了通过使用元数据和实体的关联能在运行时被创建的示例性用户界面。图6示出了在自动生成的UI内实体属性的水平流布局。图7示出了在自动生成的UI内实体属性的垂直流布局。图8示出了在自动生成的UI内实体属性的水平流布局。图9示出了在自动生成的UI内实体属性的垂直流布局。图10示出了生成界面的计算机实现的方法。
图11示出了将布局策略应用到已生成的用户界面的方法。图12示出了当实体类型数据被设置时，由引擎进行处理的方法。图13示出可用于根据所公开的架构将元数据与实体关联并自动地生成UI的计算 系统的框图。详细描述诸如行业(LOB)的应用经常操作实体(具有属性的对象，诸如客户对象)。相应 地，通常在可视化实体和编辑实体中涉及应用。通常，实体存储在数据库内，以在列表中的 紧凑表示显示，或单独地以扩展的表示显示。在大多数情况下，开发者需要从头创建用户界 面(UI)来以详细视图表示具体的实体。所揭示的架构通过将元数据附加到实体促进了应用UI的自动创建，该元数据能 够引导UI生成器(引擎)以产生更加有针对性的结果。引擎使用逻辑或算法在给定实体、 实体元数据和设备特征的情况下产生有意义的UI，诸如包括用于在UI内表示实体的被分 配区域的硬件参数以及软件参数。现在将参考附图，全部附图中相同的附图标记用于表示相同的元件。在下面的描 述中，为了进行说明，阐述了很多具体细节以便提供对本发明的全面理解。然而，显而易见， 可以没有这些具体细节的情况下实施各新颖实施例。在其它情况下，以框图形式示出了公 知的结构和设备以便于描述它们。本发明将涵盖落入所要求保护的主题的精神和范围内的 所有修改、等效方案和替换方案。图1示出了根据所公开的架构的计算机实现的界面生成系统100。系统100包 括元数据组件102，用于创建元数据106和实体属性108的关联104(表示为Metadata1/ EntityProperty1 (元数据 1/ 实体属性 1)，，MetadataN/EntityPropertyN(元数据 J 实体属 性。)，以及用于基于元数据106自动地创建用户界面112并在用户界面112中呈现实体属 性108的引擎组件110。引擎组件110还能考虑在其中呈现用户界面112的设备116的设备特征114。设 备特征114可以包括设备116的硬件能力和/或软件能力，诸如查看在设备116上可用于 查看用户界面112的区域。引擎110促进与实体属性108的用户交互，交互包括，例如，可 视化、编辑和/或验证。元数据组件102和引擎组件110可以是LOB应用的一部分。在这样的实施中，元 数据组件102和引擎组件110促进已动态生成的随机实体的处理，随机实体可以是商业实体。如将要在以下更加详细描述的，可以使用重要性元数据和组元数据、并基于用户 界面112的设备查看者的可用区域，在用户界面112中呈现实体108。元数据组件102包括 重要性元数据。重要性元数据定义与实体属性关联的重要性等级(例如，较不重要)。例 如，较不重要的实体属性将与指示较低等级重要性的重要性元数据关联。引擎组件110基 于重要性元数据从用户界面112中的视图隐藏较不重要的实体属性。然而，已隐藏的较不 重要的实体属性能通过可选择的链接变得可查看。当用户选择该链接时，已隐藏的较不重 要的实体属性能被查看。根据使用，例如，重要性元数据和组元数据的布局、并基于设备查看者的可用区 域，在用户界面112中呈现实体属性108的部分或全部。元数据106涉及，仅举数例，可见性、大小、呈现提示、分组、重要性、以及使用。图2示出了由引擎组件110展示的实体信息。引擎组件110能展示实体类型200 以及实体实例202，用于生成用户界面并用实体实例填充用户界面。换言之，引擎组件110 展示用于用户界面的生成的实体类型200，和/或用于生成用户界面并用实体实例202填充 用户界面的实体实例202。以下是用于展示实体信息的实例代码。public Type EntityViewer. EntityTypepublic object EntityViewer. Entity设置EntityType允许UI的生成。设置Entity不仅仅允许UI的生成，也用所提 供的实体填充UI。引擎组件110确定与各种实体属性关联的潜在的属性，并基于那元数据和内建映 射(例如，映射到文本属性编辑器的串属性)在运行时构建UI。图3示出了能被用于创建UI的属性元数据106的元数据示例300。示例300包括 但不限于，例如，可见性、显示名称、通常大小(例如，长度、宽度、高度、以及其变型)、呈现 提示、组、重要性、以及使用。示例300能被代码表示为如下UIDescriptionVisible (UI描述可见性) (boolvisible)，UlDescriptionDisplayName (UI 描述显不名禾尔)(string displayName)， UlDescriptionTypicalSize (UI 描述通常大小)(uint length，uint variation), UlDescriptionTypicalSize(UI 描述通 常大小)(uint width, uint height， uintwidthVariation, uint heightVariation)，UIDescriptionRenderHint (UI 描述呈现提 7j\ ) (string assemblyQualifiedTypeName), UIDescriptionRenderHintv(UI 描述呈现提 7j\ ) (Type type), UlDescriptionGroup (UI 描述组)(string groupName)，UIDescriptionI mportanceAttribute (UI 描述重要性属性)(uint importance)，andUIDescriptionUsageA ttribute (UI 描述使用属性)(UIDescriptionPropertyUsagepropertyUsage)。公开的架构的其它方面包括以下适合于在UI内表示的可读公共属性；基于 UlDescriptionGroup 属性进行分组的实体属性；基于UlDescriptionImportance (基于 多个可能的排序算法)对不属于一个组(一单实体属性)以及属性的多个组的属性进行 排序；组内的属性也基于UIDescriptionlmportance进行排序；基于属性类型、可写性、 UIDescriptionRenderHint 属性挑选 UI 控件；基于 UlDescriptionTypicalSize 属性对 UI 控件的大小缩放；UI控件基于UIDescriptionUsage属性重新解释接收到的数据(例如，串 能被重新解释为图像URI (统一资源标识符))；基于布局策略以及可用的区域大小放置UI 控件。引擎组件(也称为实体查看者控件)可以展示被称为重要性阈值的属性。该阈值 可以被称为虚拟调节器(virtual knob)，当调节时显示实体的较多或较少的字段。例如，假 设名字被给定重要性17。如果实体控件的阈值值是例如50，那么具有重要性大于50的属 性将在UI内呈现。具有低于50的重要性的属性将被忽视并且不再UI内表示。图4示出了使用多个引擎402来生成不同UI404的系统400。如上所述，元数据组 件102基于元数据106和实体属性108创建元数据/实体属性的关联104。在此，引擎组 件110包括多个引擎402 (表示为引擎，引擎J用于基于设备特征创建UI (表示为UI1,， UIt)，设备特征诸如在其上将呈现实体(例如，商业对象)的设备的可查看区域。例如，如果正在使用的应用在台式计算机上运行，那么相比于如果该应用在移动设备上运行的情况， 生成不同类型的UI。由此，不同类型控件和不同类型交互模型的使用，以及元数据对于实体 的附加使得用户在运行时创建以不同类型的设备能力和设备供应商为目标的应用。图5示出了通过使用元数据和实体的关联能在运行时被创建的示例性用户界面 500。UI500显示了实体属性的布局以及分组。姓名分组502将名字和姓氏进行组合。类似 地，地址分组504将房屋号(#)实体、街道实体、城市实体、邮政编码实体以及州实体进行组 合。照片实体506也被呈现。当处理元数据时，UI500基于元数据在运行时被创建，该元数 据指示姓名分组502、地址分组504、照片实体506、以及其它实体属性(例如，生日、年龄、个 人介绍等)将基于显示的布局策略(例如，自顶向下的顺序和/或从左往右的顺序)被呈 现。UI500，可以例如，根据设备上的可用区域来改变布局和大小，其中应用(例如，商 业)正在为该设备生成视图。例如，由于在视图内有更多的区域，大的文本框能被选择并在 台式机器上呈现，相反，较小的文本框将被选择以在给定小了许多的查看区域的PDA或手 机上呈现。然而，诸如姓氏的某些信息能被固定在最小和/或最大尺寸。例如，姓氏的通常 大小是10个字符，并且关联的实体能被限制为10个字符。元数据能作为给定应用的默认的一组常用实体来提供，然后能使用由用户创建的 一组自定义的元数据来补充。例如，金融应用能具有关于姓名和地址的一组相同的基本元 数据，但是也具有与具有相同的默认组以及涉及产品、物流等的其它元数据的商业应用不 同的关于账户、利息等的其它元数据。关于组信息，一个人具有名字和姓氏。当生成一个人的UI500时，本能地将姓氏和 名字邻近地放置(例如，并排)。这意味着名字和姓氏能共享相同的组502。由此，元数据 与指示与名字和姓氏关联的组Name(姓名)的这两个属性相关联。此人具有由称为地址 (Address)的组504定义的地址，该地址可以包括街道号、街道名称、邮政编码、城市名称、
国家等。重要性元数据能够是值范围(例如，一在2-100范围内的值)。特定组的重要性元 数据以及在该组上的放置的属性(例如，该组放置在用户的空间内，将组放在底下、隐藏该 组等)能指示该组的查看位置，或该组到底是否要被呈现。当为一个人创建UI500时，本能 地，名字和姓氏将是突出的；由此，名字和姓氏属性的重要性元数据将是高的。另一方面，眼 睛颜色可以是一个人的无意义的特征；因此，相对于名字而言，重要性元数据是低的。相应地，当生成UI500时，实体属性能被自上向下放置，其中被分配重要性元数据 的高重要性属性在上而被分配重要性元数据的较低属性在降序范围内。可以对较不重要的属性创建链接使得用户实际上必须选择链接来引起对话框的 呈现，例如，显示较不重要属性的对话框。当实体要在与例如PDA或手机关联的区域上呈现 时，这是非常有用的。因此，如果UI是针对较大的手机界面设计的，但是然后在较小的手机 界面上使用，链接能自动地在运行时实现以适应较小的UI。然后，用户可以选择链接来访问 隐藏的属性。例如，考虑引擎所接收指示查看区域的设备特征是宽200像素、高300像素。引擎 随后创建用于该设备的合适的UI。然而，当在PDA上使用时，引擎可以接收指示查看区域的 设备特征是宽50像素、高60像素，并接着创建合适的UI。相应地，将具有诸如与UI的向导类型关联的链接的UI呈现给PDA用户，其中导航是从一页面到另一页面，以可视化此人的 不同特征。相反，台式机用户可被给予足够查看此人的所有特征的单个表格。在更稳健的实施例中，除了查看区域，可以考虑其它设备特征，诸如CPU、存储器、 软件(例如，操作系统)、输入设备(例如，键盘、麦克风、鼠标等)、语音输入能力等。此外， 或可替换地，可以基于用户偏好(例如，用户偏好在上部放置图像，接下来是姓名信息，并 且没有地址信息)和/或数据类型(例如，金融、商业)创建UI。在另一示例中，用户能与UI交互，以按响应于用户交互来生成元数据的方式更改 UI。接着可以将该元数据附加或合并到现有的来自实体的元数据中，并且引擎不仅仅将由 实体提供的元数据作为输入，也将由终端用户生成的元数据作为输入。基于生成的UI，属性可与访问等级关联。例如，用户的体重信息能被作为只读属 性。可替换地，所提供的诸如街道号属性的地址可以是可写的。引擎组件能选择并初始化UI内实体方向的各种布局以填充区域。接下来是四个 示例，但是可以理解的是也能使用其它布局。图6示出了水平流布局600。在该流布局中， 实体呈现是从上至下以及从左到右。图7示出了垂直流布局700。图8示出水平布局800。 图9示出垂直布局900。根据正在被创建的表格表示的目的，可以添加特定的实体元数据从而以一种用于 正在被创建的视图的特定的方式引导UI的创建。使用电子邮件实体作为示例，电子邮件具 有发送方、接收方、电子邮件发送的日期和时间、电子邮件在某个日期和时间被接收、以及 正文。电子邮件的正文通常可以是一个或多个段落形式的一大段信息(例如，文本、图像、 链接等)。由开发者给予电子邮件正文的通常大小是，例如，10，000字符。当以更紧凑的方 式呈现电子邮件时，对正文分配10，000字符是不理想的。可以创建一个以更紧凑表示的方 式来表示电子邮件的表格。例如，对于特定的视图，可以减少分配给电子邮件的区域，使得 对于电子邮件的特定视图，所分配的区域现在是200字符。对于特定视图，用户能覆盖附加 到特定字段的默认元数据。以下是能被使用的示例性简单类分层。顶级EntityViewer (实体查看者)类可以 为如下pubLIc class EntityViewer Control, IEntityEditor引擎组件能实现public interface IEntityEditor，使得实体能以标准方式被编 辑。单个属性编辑器能实现public interfaceIEntityPropertyEditor以标准化在UI片 断和顶级实体查看者之间的协议。TextPropertyEditor(文本属性编辑器)是该界面的特 定实现public class TextPropertyEditor Control, IEntityPropertyEditorEntityViewer (实体查看者)能够使用各个属性的说明的预定标记public class EntityPropertyLabel Control界面详细描述的一个示例可包括以下public interface IEntityEditor {
bool AllowEdit {
get ； set ；
object Entity {
get; set;
Type EntityType {
get ; set;event EventHandler CancelEdit；
eventEventHandler<MemberVaIueChangedEventArgs>
VaIueChanged;
eventEventHandler<MemberVaIueChangedEventArgs>
ValueChangeCanceled; }
public interface IEntityPropertyEditor {
bool AllowEdit {
get ； set;
}
〇bj ect Value {
get; set ;
}
Size PreferredSize(uint
uint
heightVariation);
width, uint height, widthVariation,
uint
eventEventHandler<MemberVaIueChangedEventArgs>
ValueChanged;
eventEventHandler<MemberVaIueChangedEventArgs>
ValueChangeCanceled;
}如在上述代码中使用的，EntityViewer是引擎组件，并且其负责创建和填充UI。EntityViewer不初始化、提交、或取消关联的实体的编辑。是例如协作数据导航器控件 的责任来执行这三个任务。EntityViewer将由单个属性控件引起的属性更改通知通过 IEntityEditor' s ValueChanged 以及 ValueChangedCanceled 事件转发。此外，当用户试 图取消实体编辑时，EntityViewer引起其CancelEdit (取消编辑)事件。实体属性编辑器负责表示单个属性，并且处理编辑经验(如果有的话)。属性编辑 器实现IEntityPropertyEditor,使得=EntityViewer能告知属性应该是只读的或可读写 的；EntityViewer以及属性编辑器具有交换属性值的标准方式；属性编辑器具有通知值更 改(以及取消)的标准方式；并且，EntityViewer能指出用于查看属性所需的合理的区域。以下是公开的架构的过程的功能流程的示例。当EntityViewer的EntityType (实 体类型)属性被设置时(例如，在Entity(实体)属性被设置时直接地或内部地设置)， 控件能执行以下类型属性被枚举并且关联的自定义属性被访问；基于那些属性，引擎 创建一组EntityftOperty (实体属性)对象和EntityftOpertyGroup (实体属性组) 对象，并填充对象；引擎对具有建议的可视性的每个属性发起RequestVisibility (请 求可视性)事件，并允许开发者覆盖默认行为(注意的是，可视性取决于属性的重要 性是否低于或高于重要性阈值)；然后，基于属性类型、潜在的呈现提示、以及Requ estPropertyRenderControlType (请求属性呈现控件类型)事件选择属性控件(注 意的是，虽然属性不需要与IEntityPropertyEditor实现关联，但是实体查看者也能 处理几个存储控件:TextBlock (文本块)，TextBox (文本框)，DateTimePicker (日 期时间提取器)，and PictureBox(图片框))；如果没有提供呈现提示，当属性使用 UlDescriptionPropertyUsage. ImageSourcefP/ 或当属性类型是 System. DateTime 时使用 DateTimePicker时，实体查看者选取PictureBox ；确定各个属性控件和关联的标记的偏好 大小；从那里，组的偏好大小被计算；并且，最后，创建呈现组的控件(GroupBox(组框)控 件)。当引擎要呈现自己时，引擎首先根据属性重要性和 GroupImportanceDefinition (组重要性定义)属性对组进行排序。然后，各种组、标记和属 性控件根据当前的布局策略被放置。当设置Entity属性时，如果类型被更改以及属性控件 通过IEntityPropertyEditor. Value成员被填充，则UI被重新生成。以下是表示用于执行所公开的体系结构的各新颖方面的示例性方法的一系列流 程图。尽管出于解释简明的目的，此处例如以流图或流程图形式示出的一个或多个方法被 示出并描述为一系列动作，但是可以理解和明白，各方法不受动作的次序的限制，因为根据 本发明，某些动作可以按与此处所示并描述的不同的次序和/或与其他动作同时发生。例 如，本领域技术人员将会明白并理解，方法可被替换地表示为一系列相互关联的状态或事 件，诸如以状态图的形式。此外，并非在一方法中示出的所有动作都是新颖实现所必需的。图10示出了生成界面的计算机实现的方法。在1000，元数据与实体关联。在1002， 基于元数据和设备的可查看区域，为该设备自动创建用于实体的表示的用户界面。图11示出了将布局策略应用到已生成的用户界面的方法。在1100，引擎组件检测 实体类型属性被设置。在1102，引擎组件访问并处理实体元数据。在1104，初始化呈现。在 1106，基于重要性属性和组重要性定义属性，对组进行排序。在1108，访问布局策略信息。 在1110，根据策略呈现组并标记属性控件。
图12示出了当实体类型数据被设置时，由引擎进行处理的方法。在1200，设置引 擎检测实体类型属性。在1202，枚举类型属性并且访问关联的元数据。在1204，创建实体 属性对象并创建实体属性组对象，并且填充各个对象。在1206，展示并建议可视性数据，并 且允许默认覆盖。在1208，基于类型、呈现提示以及呈现控件类型事件选择属性控件。在 1210，计算各个属性以及关联的标记的大小。在1212，计算组大小。在1214，创建表示组的 控件。尽管参考如屏幕截图的各个附图示出并描述了向用户显示信息的一些方式，但相 关领域的技术人员可以认识到，可采用各种其它替换方案。术语“屏幕”、“屏幕截图”、“网 页”、“文档”和“页面”在本文中一般可互换使用。页面或屏幕作为显示描述、作为图形用户 界面或通过描绘屏幕(例如，无论是个人计算机、PDA、移动电话还是其它合适的设备)上的 信息的其它方法被存储和/或传输，其中要显示在页面上的布局和信息或内容被存储在存 储器、数据库或另一存储设施中。如在本申请中所使用的，术语“组件”和“系统”旨在表示计算机相关的实体，其可 以是硬件、硬件和软件的组合、软件、或者执行中的软件。例如，组件可以是但不限于，在处 理器上运行的进程、处理器、硬盘驱动器、多个(光和/或磁存储介质的)存储驱动器、对 象、可执行代码、执行的线程、程序、和/或计算机。作为说明，在服务器上运行的应用程序 和服务器两者都可以是组件。一个或多个组件可以驻留在进程和/或执行的线程内，且组 件可以位于一台计算机上和/或分布在两台或更多的计算机之间。词语“示例性”此处可 用于表示用作示例、实例或说明。在此被描述为“示例性”的任何方面或设计并不一定要被 解释为相比其他方面或设计更优选或有利。现在参考图13，图13示出可用于根据所公开的架构将元数据与实体关联并自动 地生成UI的计算系统1300的框图。为了提供用于其各方面的附加上下文，图13及以下讨 论旨在提供对其中可实现该各方面的合适的计算系统1300的简要概括描述。尽管以上描 述是在可在一个或多个计算机上运行的计算机可执行指令的一般上下文中进行的，但是本 领域的技术人员将认识到，新颖实施例也可结合其他程序模块和/或作为硬件和软件的组 合来实现。—般而言，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、组 件、数据结构等等。此外，本领域的技术人员可以理解，本发明的方法可用其他计算机系统 配置来实施，包括单处理器或多处理器计算机系统、小型计算机、大型计算机、以及个人计 算机、手持式计算设备、基于微处理器的或可编程消费电子产品等，其每一个都可操作上耦 合到一个或多个相关联的设备。所示各方面也可以在其中某些任务由通过通信网络链接的远程处理设备来执行 的分布式计算环境中实施。在分布式计算环境中，程序模块可以位于本地和远程存储器存 储设备中。计算机通常包括各种计算机可读介质。计算机可读介质可以是可由计算机访问的 任何可用介质，且包括易失性和非易失性介质、可移动和不可移动介质。作为示例而非限 制，计算机可读介质可以包括计算机存储介质和通信介质。计算机存储介质包括以存储如 计算机可读指令、数据结构、程序模块或其他数据等信息的任何方法或技术来实现的易失 性和非易失性、可移动和不可移动介质。计算机存储介质包括但不限于RAM、R0M、EEPR0M、闪存或者其他存储器技术、CD-ROM、数字视频盘(DVD)或其他光盘存储、磁带盒、磁带、磁盘存 储或其他磁存储设备、或可以用于存储所需信息并且可以由计算机访问的任何其他介质。再次参考图13，用于实现各方面的示例性计算系统1300包括具有处理单元1304、 系统存储器1306和系统总线1308的计算机1302。系统总线1308向包括但不限于系统存 储器1306的各系统组件提供到处理单元1304的接口。处理单元1304可以是市场上可购 买到的各种处理器中的任意一种。双微处理器和其他多处理器体系结构也可用作处理单元 1304。系统总线1308可以是若干种总线结构中的任一种，这些总线结构还可互连到存 储器总线(带有或没有存储器控制器)、外围总线、以及使用各类市场上可购买到的总线体 系结构中的任一种的局部总线。系统存储器1306可包括非易失性存储器(NOV-VOL) 1310 和/或易失性存储器1312(例如，随机存取存储器(RAM))。基本输入/输出系统(BIOS)可 被存储在非易失性存储器1310(例如，R0M、EPR0M、EEPR0M等)中，其中BIOS是帮助诸如在 启动期间在计算机1302内的元件之间传输信息的基本例程。易失性存储器1312还可包括 诸如静态RAM等高速RAM来用于高速缓存数据。计算机1302还包括内置硬盘驱动器(HDD) 1314(例如，EIDE、SATA)，该内置HDD 1314还可被配置成在合适的机壳中外部使用；磁软盘驱动器(FDD) 1316(例如，从可移动磁 盘1318中读取或向其写入)；以及光盘驱动器1320(例如，从⑶-ROM盘1322中读取，或从 诸如DVD等其他高容量光学介质中读取或向其写入)。HDD 1314,FDD 1316、以及光盘驱动 器1320可分别由HDD接口 1324、FDD接口 13 和光盘驱动器接口 13 连接到系统总线 1308。用于外置驱动器实现的HDD接口 13M可包括通用串行总线(USB)和IEEE 1394接 口技术中的至少一种或两者。驱动器及相关联的计算机可读介质提供了对数据、数据结构、计算机可执行指令 等的非易失性存储。对于计算机1302，驱动器和介质容纳适当的数字格式的任何数据的存 储。尽管以上对计算机可读介质的描述涉及HDD、可移动磁盘(例如FDD)以及诸如CD或 DVD等可移动光学介质，但是本领域的技术人员应当理解，示例性操作环境中也可使用可由 计算机读取的任何其他类型的介质，诸如zip驱动器、磁带盒、闪存卡、盒式磁带等等，并且 任何这样的介质可包含用于执行所公开的体系结构的新颖方法的计算机可执行指令。多个程序模块可被存储在驱动器和易失性存储器1312中，包括操作系统1330、一 个或多个应用程序1332、其他程序模块1334和程序数据1336。一个或多个应用程序1332、 其他程序模块1334、以及程序数据1336能包括例如，元数据组件102、关联104、元数据 106、实体属性108、实体组件110、UI112、设备特征114、实体类型200、实体实例202、元数 据示例300、引擎402、UI404、UI500、水平以及垂直流(600和700)，水平以及垂直布局(800 和900)，附图10-12的方法。设备116能够是计算机1302、手机、PDA、或其他表示信息的设 备。操作系统、应用程序、模块和/或数据的全部或部分也可被高速缓存在易失性存 储器1312中。应该明白，所公开的体系结构可以用市场上可购得的各种操作系统或操作系 统的组合来实现。用户可以通过一个或多个有线/无线输入设备，例如键盘1338和诸如鼠标1340 等定点设备将命令和信息输入到计算机1302中。其他输入设备(未示出)可包括话筒、IR遥控器、操纵杆、游戏手柄、指示笔、触摸屏等等。这些和其他输入设备通常通过耦合到系 统总线1304的输入设备接口 1342连接到处理单元1308，但也可通过诸如并行端口、IEEE 1394串行端口、游戏端口、USB端口、顶接口等其他接口连接。监视器1344或其他类型的显示设备也经由诸如视频适配器1346等接口连接到系 统总线1308。除了监视器1344之外，计算机通常包括诸如扬声器、打印机等其他外围输出 设备(未示出)。计算机1302可使用经由有线和/或无线通信至诸如远程计算机1348等的一个或 多个远程计算机的逻辑连接在网络化环境中操作。远程计算机1348可以是工作站、服务器 计算机、路由器、个人计算机、便携式计算机、基于微处理器的娱乐设备、对等设备或其他常 见的网络节点，并且通常包括相对于计算机1302描述的许多或所有元件，尽管为简明起见 仅示出了存储器/存储设备1350。所描绘的逻辑连接包括到局域网(LAN) 1352和/或例如 广域网(WAN) 13M等更大的网络的有线/无线连接。这一 LAN和WAN连网环境常见于办公 室和公司，并且方便了诸如内联网等企业范围计算机网络，所有这些都可连接到例如因特 网等全球通信网络。当在LAN连网环境中使用时，计算机1302通过有线和/或无线通信网络接口或适 配器1352连接到LAN 1356。适配器1356可以方便到LAN 1352的有线和/或无线通信，并 且还可包括其上设置的用于使用适配器1356的无线功能进行通信的无线接入点。当在WAN连网环境中使用时，计算机1302可包括调制解调器1358，或连接到WAN 1354上的通信服务器，或具有用于诸如通过因特网等通过WAN13M建立通信的其他装置。 或为内置或为外置以及有线和/或无线设备的调制解调器1358经由输入设备接口 1342连 接到系统总线1308。在联网环境中，相对于计算机1302所描绘的程序模块或其部分可以存 储在远程存储器/存储设备1350中。应该理解，所示网络连接是示例性的，并且可以使用 在计算机之间建立通信链路的其他手段。计算机1302可操作来使用IEEE 802标准家族来与有线和无线设备或实体进行通 信，这些实体例如是在操作上安置成与例如打印机、扫描仪、台式和/或便携式计算机、个 人数字助理(PDA)、通信卫星、任何一件与无线可检测标签相关联的设备或位置(例如，电 话亭、报亭、休息室)以及电话进行无线通信(例如，IEEE 802. 11空中调制技术)的无线设 备。这至少包括Wi-Fi (即无线保真)、WiMax和蓝牙 无线技术。由此，通信可以如对于常 规网络那样是预定义结构，或者仅仅是至少两个设备之间的自组织(ad hoc)通信。Wi-Fi 网络使用称为IEEE 802. llx(a、b、g等等)的无线电技术来提供安全、可靠、快速的无线连 接。Wi-Fi网络可用于将计算机彼此连接、连接到因特网以及连接到有线网络(使用IEEE 802. 3相关介质和功能)。上面描述的包括所公开的体系结构的各示例。当然，描述每一个可以想到的组件 和/或方法的组合是不可能的，但本领域内的普通技术人员应该认识到，许多其他组合和 排列都是可能的。因此，该新颖体系结构旨在涵盖所有这些落入所附权利要求书的精神和 范围内的更改、修改和变化。此外，就在说明书或权利要求书中使用术语“包括”而言，这一 术语旨在以与术语“包含”在被用作权利要求书中的过渡词时所解释的相似的方式为包含 性的。
权利要求
1.一种计算机实现的界面生成系统(100)，包括用于创建元数据和实体关联的元数据组件(102)；用于基于所述元数据自动创建用户界面并在用户界面内呈现实体的引擎组件(110)。
2.如权利要求1所述的系统，其特征在于，所述引擎组件进一步考虑所述用户界面要 在其中呈现所述用户界面的设备的设备特征。
3.如权利要求2所述的系统，其特征在于，所述设备特征包括所述设备上能够用于查 看所述用户界面的区域。
4.如权利要求1所述的系统，其特征在于，所述引擎组件展示用于生成所述用户界面 的实体类型和实体实例，并使用实体实例来填充所述用户界面。
5.如权利要求1所述的系统，其特征在于，所述引擎组件促进与实体的用户交互，包括 可视化、编辑以及验证。
6.如权利要求1所述的系统，其特征在于，所述元数据组件和所述引擎组件是行业应 用的一部分，所述元数据组件和所述引擎组件促进动态生成的随机商业实体的处理。
7.如权利要求1所述的系统，其特征在于，使用重要性元数据和组元数据，并基于所述 用户界面的设备查看者的可用区域，在所述用户界面中呈现所述实体。
8.如权利要求1所述的系统，其特征在于，所述元数据组件将定义较不重要性的重要 性元数据与较不重要的实体属性关联，并且所述引擎组件基于重要性元数据从用户界面的 视图中隐藏较不重要的实体属性，并使得已隐藏的较不重要的实体属性通过可选择的链接 可见。
9.如权利要求1所述的系统，其特征在于，所述引擎组件展示用于所述用户界面的生 成的实体类型、或用于生成所述用户界面的实体实例，并使用实体实例来填充所述用户界
10.一种用于生成界面的计算机实现的方法，包括将元数据与实体关联(1000)；以及基于所述元数据和设备的可查看区域，为所述设备自动创建用于实体的表示的用户界 面(1002)。
11.如权利要求10所述的方法，其特征在于，进一步包括基于所述元数据对实体属性 进行分组。
12.如权利要求10所述的方法，其特征在于，进一步包括基于所述设备的所述可查看 区域选择实体的布局。
13.如权利要求10所述的方法，其特征在于，进一步包括基于重要性元数据对所述实 体按垂直地或水平地中的至少之一进行排序。
14.如权利要求10所述的方法，其特征在于，进一步包括基于使用元数据重新解释传 送到实体的数据。
15.如权利要求10所述的方法，其特征在于，进一步包括相对于重要性阈值来忽视具 有属性元数据的实体。
全文摘要
本发明公开了实体交互的自动用户界面生成。架构通过提供自动地创建应用用户界面(UI)的片断的引擎，允许开发者更快地创建应用。引擎能将实体或任何实体类型的实例作为输入，创建一允许应用用户查看并修改实体的UI作为输出。架构也促进了元数据和源实体的关联来引导引擎决定；诸如以下决定，引擎选择哪些UI控件来表示实体属性，向实体提供了多少“区域”(UI空间)，以及如何放置实体属性。此外，应用允许用户与已知的实体类型进行交互，但也允许与在应用设计时所未知的类型进行交互。换句话说，应用(例如，行业)能够处理动态生成的随机实体。
文档编号G06F3/048GK102105862SQ200980130468
公开日2011年6月22日 申请日期2009年7月16日 优先权日2008年7月28日
发明者R·L·F·布里德 申请人:微软公司