SYSTEM AND METHOD FOR EXTENDING AD HOC INFORMATION AROUND STRUCTURED DATA
Systems and methods for extending ad hoc information around structured data. The method for one embodiment comprises several steps. One step is creating a web interface for structured data. One step is combining the structured data through the web interface with unstructured data, wherein one or more users can collaborate to combine the structured data through the web interface with the unstructured data without administrative approval. One step is producing groups of pages extending ad hoc information around the structured data, wherein versions of the groups of pages are tracked.
Latest BEA SYSTEMS, INC. Patents:
This application claims priority to U.S. Provisional Application No. 60/914,623 entitled “ENTERPRISE WEB APPLICATION CONSTRUCTOR SYSTEM AND METHOD,” filed Apr. 27, 2007 [Atty. Docket No. BEAS-02048US0], by Matias Cudich et al., which is herein incorporated by reference in its entirety.
COPYRIGHT NOTICEA portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
FIELD OF THE INVENTIONEmbodiments of the present invention relate to a seamless, collaborative environment for creating applications, consuming information, and contributing content.
BACKGROUNDToday's workers spend the majority of their time consumed by ad hoc activities. These activities depend on rapid-fire content creation, information access, and collaboration with colleagues. In their day-to-day activities, most knowledge workers currently rely on a set of enterprise software productivity tools—email, instant messaging, content management, portals, document management, and desktop office tools (e.g., Microsoft Office®). Knowledge workers manually create context by transferring documents or conveying conclusions or recommendations from one tool or environment to another.
In one example, multiple participants want to collaborate on creating a prioritized list of prospects for lead generation:
1. Participants must first obtain an extract of prospects from a core enterprise system used to track the prospects, such as a Siebel or Salesforce.com® CRM application.
2. Once the data is obtained, one of the participants sorts it in a spreadsheet document and emails the document to all other participants.
3. Participants edit the list and email each of their new versions to the entire group.
4. Several participants also add new columns to the spreadsheet to reflect additional prospect information.
5. Multiple new versions are generated and distributed through email.
6. Someone is designated as the master editor who cuts and pastes the various iterations into a consolidated document, which is then emailed to the group for final approval.
For knowledge workers to collaborate in the process described above requires ad hoc activities.
There are several drawbacks to the approach to ad hoc activities described above. Time to resolution is lengthened due to back and forth email exchanges, delays in email replies, and manual editorial aggregation. There is a lower quality of output because participants do not have access to current aggregate content when making their contributions. Productivity is reduced since participants must use multiple tools (email, spreadsheets, CRM systems, etc.) to add context and content to the list. There is also no traceability between versions of the list, and if information is lost, records of the information are also lost.
A system for extending ad-hoc information around structured data can solve these issues. A web-based application constructor can help line-of-business users create web pages—wikis, blogs, data-driven collaborative web applications, and more. One exemplary embodiment of a web-based application constructor is BEA AquaLogic® Pages from BEA Systems, Inc.
The web-based application constructor can serve the diverse needs of both IT departments and line-of-business users.
For IT management, the web-based application constructor provides the management and governance control that core enterprise systems require. But the real impact is in IT management's ability to empower a greater army of creators and participants, allowing business users to solve their challenges directly on the web.
For line-of-business users, the web-based application constructor is a revolution: creating for the web becomes as easy as creating a Word document or sending an email. Users feed data from core enterprise systems directly into their applications, and can wire that data on the page to other components, such as a Google Map™ or an RSS feed. Every page can be edited by a user while the system tracks changes, versioning, and access.
At its core, the web-based application constructor is a system for creating and editing web pages quickly. One embodiment includes data spaces for assembling data into pages and live spaces for assembling pages into applications.
Data spaces allow participants to create powerful Web interfaces on top of structured data sets, like a simple list of records or an extract of new opportunities from a CRM system. Participants can surface data-to-data spaces through a variety of mechanisms, including Really Simple Syndication (RSS), Web services, or by creating a data set from scratch. A data space can be created simply by publishing an Excel® spreadsheet to the Web.
When creating new data sets, data spaces allow the user to select different data type fields (simple text, long text, drop-down) and configure them. Users can thus quickly create data sets, such as a list of items or contacts, and reuse that data within other pages, live spaces, and applications created within the system.
Data spaces provide several templates for integrating and presenting data, including for RSS, blogging, and Webservices invocation. Data spaces automatically create pages for each list of records in a data set, and individual pages for each record in a list. As an example, creating a data space from an RSS feed yields a single page displaying a list of items in the feed. Additionally, the system creates a page representing each individual item in the feed. These pages can be enhanced through the system's page-creation and page-editing capabilities.
Once a data space is created, users can access the data within it through a set of different URLs, each unique to the data space and the type of view on the data that the URL provides. Data spaces let users add structured and unstructured content to each of the views they express, and become important sources of reusable data that live spaces assemble into Web applications. Data spaces are a simple but powerful concept. By representing structured data records on the Web as a series of independent pages, users can quickly annotate these records with unstructured text, or add additional structured data related to a single record.
Live spaces can be dynamic groups of pages, created and woven together by end-user participants. Live spaces combine data from data spaces with documents and other unstructured information that is either created for a given page or added from within the system. Like other pages in the system, live spaces can be built collaboratively by multiple users, and the system can track and control versions over time. Live spaces offer granular access-control capabilities, so managers of a live space can determine who can edit parts of the live space and what they have the ability to do.
Live spaces can provide a canvas on the Web that allows users to efficiently share information and accomplish activities collaboratively. In the same way virtually any interested participant can create a Wikipedia article for a given topic, live spaces allow business users to create simple pages for any topic, mix in data space records, documents, annotations, or comments, and add links onto those pages. As it does for all pages in the system, BEA AquaLogic® Pages creates simple, unique URLs for each live space and its pages, providing an easy way for system users to navigate directly to useful pages and applications.
In one embodiment, the web-based application constructor features a rich page framework that overlays a number of capabilities on pages created, including the ability to attach images, documents, and control versioning and page history.
In one embodiment, every page in the web-based application constructor system is a live, editable page. The system features wiki-style page editing where at the push of a button an individual user can make changes and add new text, hyperlinks, images, documents, and widgets. Users can enter a simple edit mode on the page, which makes the page instantly editable for either writing, where the user can write rich text directly onto the page, or designing, where through a simple toolbar a user can drag and drop widgets onto the page for application-building.
Page editing can be a collaborative process that involves multiple participants making changes to pages over several iterative sessions. The system tracks each page's history and creates a new version of the page with each change made to it. This allows page owners to revert to earlier versions of an accepted page, or undo previously made changes. Applications built using the web-based application constructor can thus be dynamic and flexible, and builders of these applications can add temporary functionality to a page—like a map to display location data, or a short list of tasks—and remove that functionality when it is no longer useful.
The web-based application constructor provides several useful common templates and layouts for creating pages. Users can specify a layout when creating an individual page, selecting from a number of layout templates, including a two-column layout, a header-body-footer layout, and more. Layouts allow participants to quickly arrange widgets within structures common to specific applications or pages. The system also provides a free-form layout, which allows users to modify the form and structure of pages on the fly to meet changing requirements of the applications they are building. The system also provides basic templates for applications like a blog or simple wiki that is created using data spaces or live spaces, as described above. IT management or developers can extend the system by creating additional templates for building specific applications or, in the case of a data space, for connecting to specific data sources such as a Customer Relationship Management (CRM) or enterprise resource planning (ERP) system.
In one embodiment, the Dashboard is the system's home page and a starting point for most user activities, including live space and data space creation, as well as exploring the system for useful objects. The Dashboard is also a simple workspace, displaying a list of recent activities and changes in the system, a list of an individual's outstanding drafts, and a complete list of every live space and data space in the system, sorted by the date they were last modified. The Dashboard also includes simple links to initiate common activities, like creating a live space or a data space.
In one embodiment, the Action pane is a dynamic activity sidebar that overlays each page, providing access to common functions for page builders. These functions include the ability to create new pages, edit the existing page, edit the settings for live spaces or data spaces, attach documents to a page or interact with documents already attached to it, and view recent changes on the page and its version history. The Action pane also displays lists of the objects included in a live space or data space, and provides the ability to search quickly for those objects from within the sidebar.
Active pages is an innovative way to automatically liberate any item as a separate page on which any participant can freely add other data or engage in unstructured collaboration. The system uses this capability to represent any object—lists of records, individual records, documents, and images—as individual pages to which unstructured content, or other widget components, can be added collaboratively by users. Every page in the system, including pages created for objects, benefits from this capability. Each object-page is based on the page framework within the web-based application constructor, which governs normal page actions, such as document attachment and page versioning.
Active pages can be a way to link ad-hoc activity, such as wiki-ing, to the systems of record, in such a way that this free-form collaboration will always be tied to the underlying business object.
Following is an example of active pages:
-
- A data space displays a specific list of customer records from a CRM system.
- Through active pages, represents each customer record automatically as a separate page the user can drill into.
- A sales account team can thus add related documents, images, RSS feeds, or other records to this specific customer record page.
In one embodiment, documents can be attached to any page in the system, and as it does for other objects, the web-based application constructor also represents the document as a page, conferring all the benefits of the page framework to it as described above. In addition, the system will track versions of documents, providing a simple way for users to share documents they create and modify along with other users.
Users add functionality to pages they create using a series of page components, or widgets. Widgets can be bound to data created within the web-based application constructor, imported from enterprise systems, or provided by third party services and surfaced through integration capabilities in the web-based application constructor. Page components can also contain static content or content keyed to preferences assigned to another component.
The web-based application constructor comes with a number of page-component types that users can select to create new instances of a page component. Page-component types include: Data Table, Image, Record List, Text, and more. Page components are added to the page through simple drag-and-drop. Each component features an intuitive wizard that allows the user to name the new component instance, configure it, and set its security. Each instance of a page component features a unique URL, and can thus be consumed outside the web-based application constructor environment—by an enterprise portal, for example.
The Data Table is a page component that lets users display and interact with structured data. Users can bind Data Tables to any type of data space, and depending on that type, can get a read-only or editable view of data. Users can also create a new data space from within the Data Table configuration wizard.
The Data Table component features three primary modes: 1) Simple, where the data is simply displayed; 2) Master/Detail, whereby selecting an individual record displays that record's detail below, and where new records can be added directly within the page; and 3) Spreadsheet, where users can insert and edit records as they can within Microsoft Excel®. The Data Table interface automatically generates a row for every record and a column for every field in the data space. It also features common controls for interacting with data, including field-sorting, filtering, and pagination.
The Record List page component is similar to the Data Table component, but used for displaying data from data spaces that has significant numbers of fields or records. Record List components are commonly used to display lists of records from within a data space that drive other interactions across the page. Record Lists feature the same built-in sorting, fielding, and pagination capabilities as Data Tables. The Record List component includes a special user-configuration feature that lets it exchange data with other components on the same page. Each Record List instance can either broadcast information—a single rowclick, or all rows—or “listen” for information from other components. This capability, in conjunction with other page components that possess it, allows end-users to build data-driven mashups, combining data from multiple systems interactively on a single page.
The Image component lets users embed images directly into pages and alongside other components, such as rich text, data tables, and so on. Users can also, in the context of a rich-text editing session, embed an image in the middle of text, creating elegant, Web-style HTML without programming. Images can be added by either specifying a URL, by uploading directly to the system, or by selecting previously specified images within the system. Uploaded images have the versioning and object-control features of most other page objects. The image editor allows the user to specify each image's width and height attributes, displays a preview of images, and lets the user add descriptive text that shows when other users hover over it with the mouse.
The web-based application constructor provides a sample Map component that graphically maps data fed to it from other components. The sample Map component, once added to the page, can be configured to listen for data from the entire page, or from data sent to it by specific components. The map component, when provided the value of a field named “Address,” will map the value visually.
Several page components include a special user-configurable feature that enables the component to exchange data with other components on the same page. Each component instance can either broadcast information—either a single row-click, or all rows—or “listen” for information from other components by specifying data fields of interest. This capability is available with Record List, Map, and several other page components, and lets end-users build data-driven mashups that can dynamically and interactively combine data from multiple systems on a single page.
Users in the system can save pages as drafts, and retrieve drafts from the Dashboard described above. As a user is working, the web-based application constructor automatically saves a draft in the background every 10 seconds to protect a user from losing work before it is published. Users can thus work on the Web in a way that is similar to their method of working on desktop applications. To publish changes made to the system, a user simply selects the “Share” button, and can also add a description about those changes. The web-based application constructor keeps track of the changes made to individual pages, data spaces, and live spaces. As the page goes through successive versions, users can view a previous version, delete it, or revert back to a previous version of the page. The same applies to documents attached to pages, and users can download old versions of documents in addition to seeing their history.
The web-based application constructor provides a core set of security capabilities that secure and protect the data and functionality created and managed within it. The ability to govern who can do what in the system ensures that people see only what they're entitled to see. Each object in the system is governed by an access-control list (ACL) that determines the actions users and groups can take regarding it, including reading, creating, editing, and more. By default, “child” objects inherit the security of their “parent,” making it easy to set security once on a particular live space and continue working. For each object, the web-based application constructor recognizes a set of configurable roles, in which activities and privileges can be set: Guest, Reviewer, Creator, Publisher, Editor, and Administrator. Individual users and user groups are added to these roles to confer permissions on specific system users. The web-based application constructor leverages user and group information from within a portal system, or by using the user and group security capabilities found in another system. This allows the web-based application constructor to define users and groups by integrating with virtually any third-party user repository, including LDAP, Active Directory, or custom databases.
The web-based application constructor brings a rich set of capabilities to a wide variety of business needs, ranging from customer-support issue tracking to sales planning to employee blog publishing. This is a simple example of how the web-based application constructor can be used to improve a customer support team's ability to respond to a critical situation in a few simple steps.
1. A single support engineer creates a new “Support Issues” data space, which displays a list of support incidents for a single customer. The list is pulled directly from a Clarify support system, using the Web-service invocation method provided by the web-based application constructor.
2. An account manager, who is largely responsible for customer satisfaction for this individual account, creates a new “Issue Tracking” live space for assembling all the information related to this specific customer and issue. This information will be assembled by an extended team of participants related either to the account or to resolving the issue.
3. The account representative writes directly onto a page of the live space, listing action items and owners for each action the support team needs to address.
4. A customer service representative enters the live space and drags-and-drops a “Support Team” DataTable widget onto the page. The customer service representative maps this component to the existing “Employee Contacts” data space, which pulls a list of records from an internal LDAP system.
In one embodiment, the web-based application constructor includes a set of Adaptive Tags to add links to live spaces and data spaces to the portal navigation, allowing users to navigate to components from within a portal page. These tags are data tags; they return URL attributes as data, and can be used in conjunction with a display tag. The tags retrieve live spaces and data spaces by making requests to web services on the server. In one embodiment, the results are cached for 5 minutes or until the user logs out. The tags return the live spaces and data spaces that the current user has access to.
The Navigation Tags Header Portlet includes live spaces and data spaces tags. The sample header portlet includes an example of how to use tags with HTML combobox menus, required to support Safari browsers. One exemplary embodiment adds data tags to the navigation in a custom header portlet. Live spaces, data spaces and other Pages components can be added to a portal page using portlets.
One embodiment includes an embedded Apache Derby database. One embodiment uses the web-based application constructor without a portal.
One embodiment provides a Maps Component—enables users to add maps to a page. Maps can receive input (in the form of an address) from data spaces or other components on the same page.
One embodiment provides an IPC page of a Record List Component—enables users to configure the component to broadcast row clicks (to a map for example) or listen for content from other components.
One embodiment provides a Markup Component—enables users to paste html content, like a YouTube video or Google Gadget™, directly into a page.
One embodiment provides a REST data space—enables administrators to create data space templates that receive data from a REST API.
One embodiment provides a Yahoo!® Search data space Template—sample implementation of a REST data space using the Yahoo!® REST search API.
One embodiment provides a Google™ Search data space Template—sample implementation of a web service data space using the Google™ SOAP search API.
A live space is a logical collection of individual pages. For example, you might have a Marketing live space that includes the following pages: Collateral, Events, and Writing and Design Resources.
Each live space includes security so one can control which users can view or edit the pages and any other objects associated with the live space. Users who are allowed to edit the pages can add or edit content enabling rapid knowledge transfer. Because each page is versioned, and the user can easily revert to a previous version, users can be a bit more relaxed with who is allowed to edit content.
Security can be set by assigning roles to portal users and groups. These roles apply to every object associated with the live space (pages, documents, and components).
Users can design a page simply by dragging different types of page components (for example an image or a table) onto the page and add text by typing in a rich text editor.
Access to each page is controlled by the associated live space security. Users who are allowed to edit the pages can add or edit content enabling rapid knowledge transfer. Because each page is versioned, and because it is so easy to edit anything, users are compelled to contribute, participate, and when necessary, correct others' contributions.
When a user views a page, actions can be performed that do not alter the actual contents of a given page. For example, one can add comments, attach documents, create new pages, and work with content in record lists and tables. Each time a user publishes a page or an object in page view a new version is created (versions are listed under Recent Changes). This allows a user to easily see what changes were made and revert to a previous version if necessary.
A data space defines a set of data, made up of records. A user can create a custom data space that stores data in the Pages repository, or points to an external system from which data is surfaced.
Each data space is based on a template that defines the configurable properties of the data space (for example, whether the data space relies on the native Pages repository or an external repository). A user can display data from an external data source in pages via SOAP. For example, a user might want to display customer support issues or sales information from a customer relationship management (CRM) system, display inventory information from an enterprise resource planning (ERP) system, or connect to a free web service on the internet. Each data space includes security to control which users can view or edit the records in the data space. Users who are allowed to edit the records can add or edit content enabling rapid knowledge transfer.
Security is set by assigning roles to portal users and groups. These roles apply to every object associated with the data space (records, documents, and components added to the data space or records in page view).
Data spaces enable a user to define data fields to fit the user's needs. For example, a user might want to create a data space to track job postings, marketing campaigns, or facilities requests. Data collected in a data space is stored in the Pages repository and is therefore editable. Blog data spaces, like custom data spaces, store data in the Pages repository and are therefore editable.
Data spaces enable a user to display content from an external RSS feed. For example, a user might want to display recent news articles discussing a product or company. Data spaces enable a user to surface data residing in external systems via SOAP-based web services. For example, a user might want to display sales information from a CRM system, or display inventory information from an ERP system, or connect to a free web service on the internet. In one embodiment, after a data space is created and its records have been fetched at least once (by a user viewing the data space), the records become part of the search collection and users can add components, text, and document attachments to the records. The cached records are updated when a record is viewed by a user.
A record is a group of related fields that store data about a subject or activity (for example, a record can be one row in a table or one entry in a blog). A collection of records is stored in a data space (which stores data in the native repository or points to an external repository of data). A user can search for records using the search box at the top of any table or record list. As you type, the list is dynamically filtered to display only those records that include your search text in one of the record fields. A user can add components, comments, or documents to a record by opening the record in page view and editing the record just like any other page. Records can be deleted in different ways depending on the interface that displays the records.
Embodiments of the present invention enable users to manage information stored in both native databases and external systems. In concert with the rich set of page components, data sources can let users create on-the-fly applications that surface critical business information such as sales leads from a Siebel CRM system, or manage lightweight data sets, such as a product feature list.
One embodiment of the present invention is a web-based application constructor for constructing a web display. The web-based application constructor can obtain data from heterogeneous data sources to produce the web display. A web display can contain page components and display the data from at least some of the heterogeneous data sources.
A versioning system can keep track of changes to page components to allow users to make changes without administrative approval. The versioning system can keep track of changes to page layout, searches, and text to allow users to make changes without administrative approval. A change control system can allow users to dynamically undo changes to page components while using the web-based application constructor.
The versioning system can store old versions of the web display and thus allow the users to roll back changes. For example, the system can store a history of old versions and when a user makes an error, the page can be rolled back to a previous version.
The page components can be elements constructed from data in the heterogeneous data sources. For example, the page components can expose data from ERP, Database or other sources.
The heterogeneous data source can include a relational database management system, a customer relationship management system, enterprise resource planning system and/or any other types of data sources.
The heterogeneous data sources can have Web Services schemas that allow the application constructor to produce a display of the data. The page components can contain interactive elements. In one embodiment, all page editing is versioned.
Whether a page component is displayed to a user can be controlled by roles and security. For example, some pages can have page components that are only viewable by users in a certain group or with a certain security level. Display and/or updates to page components can be controlled by using the URLs for the page components. The web-based application constructor can provide roles to users that can be used to limit access to applications.
The page layout can also be versioned. Versions of the page can be stored at a remote server. AJAX at a user browser can send version update information to the remote server. Page templates can be used to create the display. The page components can include rich text.
The page components can have their own URL so that they can be shared among applications. For example, a user can copy a page component into their own page since the system can use the page component's URL to copy it into a new display page. In this way, updates can be sent to multiple pages.
The page components can include a view of data in a list, a view of data in a record, a view of an ad-hoc application or other views. The display can be constructed from available applications, where available applications can be dragged and dropped into page components.
In one embodiment, at least one of the heterogeneous data sources is a searchable resource. When the display provides for a search field into the searchable resource, the result of a search can be shown in a page component of the display. The page components can be dragged and dropped to a new display. In one embodiment, the changes to the page component are not propagated back to the application data source propagated back to the application.
The web-based application constructor can provide roles to users that can be used to limit access to applications. The application constructor can convert at least one object from a heterogeneous data source into a page component. The system can allow for the construction of user interfaces to access different types of data.
Change control system can allow users to dynamically undo changes to page components while using the web-based application constructor.
All page editing can be versioned. The change control system can allow for a redo of changes. The versions can be time stamped and changes can be rolled back up. For example in one embodiment, users can rollback changes to a state as of a previous period of time. Changes can be dynamically made to page components, page layout, searches, and text while using the web-based application constructor.
In one embodiment, the web-based application constructor can allow users to annotate page components with comments visible in the web display.
In one embodiment, the page components can be identified by URLs and the annotations can be associated with the URL. In one embodiment, the annotations can receive user inputs from multiple pages and produce a common display. A web-based text editor can be used for the annotations.
One embodiment of the present invention includes an application constructor to convert at least one object from a heterogeneous data source into a page component.
In one embodiment, the system allows for the construction of user interfaces to access different types of data. Web service WSDL can be analyzed to determine user interface fields. An XML editor framework can analyze XML schema at the WSDL.
The page components are accessible by URLs. URLs can be used by a security system. Roles can be used to determine what page components are displayable to a user.
The URLs can be automatically created. All elements on a page can have their own URL.
An XML editor framework can be adapted to use web services schemas to automatically create user interfaces for inputting data in fields determined from the web service schemas. Page components can contain data that has been converted into a list format. Clicking on elements of the list can access additional details of the list. The list can be annotated.
The page display can have a nested layout. The nested layout can include rows and columns in a cell defined by rows and columns. Different rows can have different numbers of columns. The page components can be dragged and dropped so as to change the layout. New columns and/or rows can be created by the dragging and dropping.
Page editing can include:
-
- Classic wiki-style page creation and editing;
- Performed by typical end users as part of using the system;
- Pages can be designed to evolve over time, by being edited by multiple users over multiple edit sessions (which can be concurrent); and
- Example pages: product launch workspace, article on customer wiki pages, etc.
State and mode management can be done in multiple ways. In one embodiment, regardless of the shell applied to the given page/live space, users can specify a mode and a state for the page they are viewing or editing.
While in Read mode, users can create new pages. To create a new page, users can specify a page title, a URL for the page (this can be automatically generated by the form, but users can override the URL if they so desire), and a description for the page. Moreover, users can specify a layout for the page, and the Live Space in which the page will live. By default, pages can be placed in the current Live Space; users do have the opportunity, however, to place the page in another Live Space—either one that exists, or a new one they create on the fly.
Dojo can be used for all JavaScript operations on the client, primarily gathering DOM objects, updating styles on those objects, updating page modes and edit states, parts of drag-and-drop, rich-text editing, console logging, and so on.
Every document attached to a page has its own page/URL. When a user navigates to the document (via the Info panel, Organizer, etc.), the following operations can be performed: upload a new version of the document, delete a version of the document, delete all versions of the document, revert to a version of the document, and decorate the document. Decorating a given document-page is identical to decorating a record-page or recordlist-page. Like these other objects, only one page exists for any given document.
If a user wants to create a new version of a specific document, users can navigate to the document (document as page), and click Upload New Version. This allows users to upload a new version of the given document that perhaps has a different file name. Once this happens, the operative file name of the document changes to the file name of the latest uploaded document. This is important when it comes to figuring out whether or not to increment a given document, or create a new attachment when a user tries to do a simple file version task. The system need not be designed to look at old versions of a given document when figuring out whether or not to increment a document's version history.
Users can revert to any version of a given document. This can be a version uploaded before or after the version labeled as “current.” For example, a user can upload five versions of a document, and then decide to revert to version 3. At this point, all 5 versions still exist, but version 3 is the “current” version. Then, a user can choose to revert to an even earlier version, or back to the latest version. If a user reverts to a previous version, then uploads a new version, the version list is incremented by 1 (meaning the new version would be version 6 and versions 4 and 5 would remain). When figuring out whether or not to increment a document, Constructor looks at the “current” version, not the latest version.
Objects as Pages can be used to represent structured data, such as records, lists of records, documents, and so on, as pages to which unstructured content can be added. For example, Constructor allows displaying a record such as a Customer Bug as a page; users can then view this customer bug as a page, mark up the page with additional content (using page components and rich text); and comment on the page using Annotations. Because Objects as Pages are based on the Constructor page framework, normal page actions, such as document attachment and page versioning, can also be supported. In one example, there are three standard views for objects as pages:
-
- Object as Page (Records and Documents);
- Entry as Page (Records); and
- Object List as Page (Records).
Certain types of objects can be viewed as pages. This can include records and documents attached to pages. This view depends on the given page to have embedded in it a page component that knows how to display the given object. For example, the standard Record Object as Page can use the Record Detail component; on the other hand, the standard Document Object as Page can use the Document Detail component. These components handle operations such as updating the object, and deleting the object to which they are bound. All of these pages support an operation currently called “Decoration.” Decoration is identical to page-editing, except that it is done in the context of an Object as Page. The distinction here is that there are certain modifications to the area into which users can add content.
Pages are designed to allow users to add net new objects to a collection. In one example, adding net new records to data sets can be supported. When users navigate to a given Entry as Page, the first thing they should see is a blank form (this is actually an empty Record Detail component). Else, they are navigating to an existing record, in which case they would actually be looking at an Object as Page. Entries as Pages support “decoration” in the same way that Objects as Pages support “decoration.”
These pages are designed to allow users to view multiple records in a given data set via this page construct. The default component used to display these records is the Data Table. Much like Objects as Pages and Entries as Pages, these pages can be “decorated” by users.
Each Object, such as Page, Entry as Page and Object List as Page can have its own unique URL. This can allow users to navigate to these views from outside of Constructor (which lets them do things like e-mail around links, etc.). When the name of the given underlying object changes, so can the URL, except in the case of documents, whose URLs are bound to IDs rather than user-specified names. URLs to records are also ID bound, but they do include the name of their owning record set, which could be updated by users.
Constructor need not create or store Objects as Pages until those pages are decorated and subsequently published by users. Also, these pages can be persisted when Annotations are added to a page (even if the page hasn't been decorated).
Every Object as Page can have one or more base components it uses to display the given object to which the page is bound. In the case of regular Objects as Pages, the default view can contain a Record Detail Component; in the case of document Objects as Pages, the default view can contain a Document Detail component, and so on. There are cases, however, where other components may be used (in the case of Applications, for example). These base components may differ slightly in functionality from their regular versions: for example, the normal Record Detail component that can be added to any page supports paging between records using an AJAX operation (the page doesn't refresh). In the case of the Object as Page version, paging between records actually navigates the user among each of the URLs for each of the records in the given record set. Some components in the system may only be available via Objects as Pages (such as the blog and document detail components).
Objects as Pages can be versioned just like any other page. In one embodiment, only decoration-level operations are tracked, and not changes to the underlying object.
Users can attach documents to Objects as Pages in the same way they can to regular pages. These documents need not be associated with the underlying data in any way. In one example, if a user attaches a document to a Record Object as Page, Constructor doesn't automatically add a File Attachment field to the underlying record.
Users can annotate Objects as Pages in the same way they annotate regular pages.
When decorating an Object as Page, there may be restrictions as to where users can add content. By default, Objects as Pages will have a primary page component at the top of the page, and then a blank content area beneath that. In one embodiment, users are only able to add and manage components within this content region. In one example, users cannot add new components to the left, to the right or above the Object as Page primary component.
Live Spaces can provide a natural way to group pages, and to provide for those pages a common access control list, which makes it easy for Live Space managers to decide who should be able to see and do what in a Live Space, and the pages contained therein.
Users can specify a page for a Live Space, which acts as the default page when anyone tries to navigate to the Live Space directly. For example, if a user types in a URL like http:// . . . /Is/foo, they are immediately navigated to the home page for the “foo” Live Space.
Users can view general properties for a given Live Space by launching the wizard for that Live Space. In one embodiment, this tab in the wizard only shows up after a Live Space has been created. This tab can include system information such as: date created, date modified, created by, and so on. None of these properties need be editable. Live Spaces can be represented in the system by a live space object, which can contain properties for all the configurable settings noted above. The live space object can be persisted in the repository as a node (and on the filesystem as an XML file). In the repository persistence implementation, the pages for a given live space can be represented as child nodes under the parent live space node. While in one embodiment, certain nodes under the live space (pages, documents) are versionable, the live space node need not be. Within the Constructor service tier, live space objects can be cached, thereby reducing the need to make a remote repository request every time a live space is requested. In terms of exposing the live space object through the UI (exposing properties like the live space name as text on the page, or editing live space properties via the editor), there are several mechanisms through which this can be surfaced. One is through Facelets and a live space “backing bean,” which allows properties on the live space to be rendered in the UI via certain expressions (EL) in the template's tags. The Live Space editor can update settings on the live space object by way of the DWR live spaceService, which can expose methods to the client tier (such as JavaScript) to create and update live space objects. Navigating to a Live Space by means of a URL can be handled by a “resource resolver” class, which will parse a URL, and from it, extract the Live Space name (what is typed into the URL field in the editor). From the Live Space name, one can look up the Live Space, get its home page, and render it.
Page Components can be UI elements which can be added to pages by users. Page components can be bound to back-end data provided by Constructor or a third-party data source, or can simply contain static content, or content keyed off of the preferences assigned to a given component. Out of the box, Constructor can ship with a number of page component types, a list from which users can pick to create new page component instances. These can include: Data Table, Image, Record List, Text, and so on.
Every component in Constructor can have a URL that can be used to access that component directly. In one embodiment, users can get access to these URLs by either (a) clicking on the component name in the component title bar (for components that have title bars), (b) by viewing the properties panel for a given component (for components that have wizards/editors), (c) by searching/finding the component in the Explorer panel and then navigating to the component or (d) by searching/finding the component in the Organizer and then navigating to it.
In one embodiment, when viewing a page component via a URL, there is a specific page component shell that wraps the given component. This can take two forms: (a) user-friendly and (b) portal-ready. In the case of (a), the shell simply displays the page component title and description within the shell; in the case of (b) the shell is completely blank and only displays the contents of the component (not even the title bar). The purpose of (b) is to allow displaying a single page component as a portlet in the portal, where one wants to let the portal govern things like toolbars, and so on.
Page components can be shared across pages.
Page components need not be versioned on their own, or saved on their own. Page components can be versioned and saved as part of a page save operation. A Data Table component can expose records in data spaces.
The Record List component is designed to allow viewing sizable data spaces in a compact, filterable UI. Once a data space is specified, the following features can be available:
Users can add comments, and engage in message-board style discussions, in the context of every page in the Constructor system. This can provide a simple way for users to provide structured feedback to the page. In addition, it enables things like commenting on blog posts in the context of blog data spaces.
The same applies to documents, except that instead of navigating to old versions of documents, users can download old versions of documents. Page editing can be equivalent to document uploads. When editing a page, users can have the option of either saving the given changes as a draft, or publishing their changes. When users save their changes as a draft, they effectively are not versioning the page, but instead are keeping their changes around for later review. Once a user is ready to submit their changes to the system, they can click Publish, at which point a new version of a page is created, and that version can be set as the “active” version. Any time a user navigates to a given page, they can effectively navigate to the “active” version. In one embodiment, the case of documents, there are two ways to add a new version: (a) users can upload to a page a document, and if that document has the same name as a document already attached to the given page, then that document is added as a new version of the existing attached document, or (b) users can upload to a specific document a new version, and even if the names are different, the new file is treated as a new version of that existing document.
Users can revert to any version of a page that exists in the system. After reverting to an old version of a page, say from version 10 to version 6, versions later than the now “active” version need not be deleted (versions 7-10 are not deleted). Reverting can be performed to an older version, or a newer version, given the relative position of the “active” version. Users can revert to a later version from a previous version. When users revert to an old version, and then publish that version (after perhaps making some changes), the new version is tacked on to the very end of the version history, and is marked “latest.” The same exact behavior applies to documents (except uploading replaces publishing).
Users can delete any given version of a page, or all versions of a page (which effectively happens when a page is deleted). When a given version is deleted, holes are left in the version history. This is to make clear to users that a given version, which may have had a specific purpose or meaning, is now gone. There need be no other way to see that a given version has been deleted.
Users can navigate and view the contents of a given version (via the Explorer panel). When viewing that version, they can click a button to revert to that version, or delete that version. There is no UI for immediately making changes to that version—i.e., that non-active version is read-only. In the case of documents, users can download any non-active version.
Customers can deploy Constructor in various ways, either by itself or together with a Portal server or another type of server. To be able to deploy Constructor behind a portal server, several features are offered, tackling things like navigation-level integration, portlet-level integration and gateway-level integration.
A navigation tag can be deployed into portal navigation components. In most cases, this tag will be deployed inside the out-of-the-box portal header, or a modified version of the out-of-the-box portal header. The portal has two types of navigation: pluggable navigation and tag-based navigation (Adaptive Tags). Via portal Experience Definitions, customers can create rules to determine which type of navigation to display on a given portal page. In the case of tag-based navigation, portlets can be used to render out the portal navigation scheme. In this case, the portal header can be a portlet (aka, a Web application that produces HTML), and is built out of HTML and XML tags. In the out-of-the-box portal header, there are some default tags: one to list out My Pages, one to list out Communities, and so on. These tags are primarily ‘pt:ptdata’ tags, which are then wrapped by ‘pt:plugnav’ tags for actually rendering out the data as HTML/CSS/JS. Constructor can ship an additional live spaces data tag that can be inserted into this portal header portlet to list out live spaces next to My Pages and Communities. This tag, when rendered out on the page via a UI tag, lists out all the live spaces to which a user has access. When a user clicks on one of these live space links, they can then be navigated to a gatewayed Constructor page (the home page for the given live space run through the portal gateway).
When viewing a Constructor page via the portal, it can be a requirement that the Constructor page be gatewayed. When attempting to view a Constructor page via the portal, the user's browser makes an HTTP request to the portal with a URL that the user wants to see. The portal then parses this URL and figures out that the user wants to see a specific portlet, the portal then makes an HTTP request for that Constructor page (which was specified via the URL), gets back the HTML/CSS/JS etc. from Constructor, “transforms” that markup (makes all of the URLs gatewayed URLs), and then finally returns that HTML to the user's browser. Gatewaying a page also allows the portal to scan the page and replace any Adaptive Tags with their corresponding HTML/CSS/JS (this is used to support the live spaces menu and injecting the portal header into the Constructor shell). User identity propagation can also be done via the gateway. When the portal makes a request to Constructor it can send along user information, which Constructor can then use to figure out whether or not a user should have access to a given resource.
By default, when viewing Constructor through the portal, and when the appropriate Experience Definition is set up, the portal header can automatically appear at the top of the Constructor page. This can be supported by a custom Constructor Adaptive Tag, which is embedded into the default Constructor shell. When the portal transforms the Constructor page, it can see this Adaptive Tag and insert the portal header HTML. As described above, this HTML can include a menu which lists out Live Spaces. Customers have the flexibility to modify their shell, and place this header insertion tag wherever they want.
Constructor can include a portlet template that can be deployed to the portal to allow users to create new portlets based off existing Constructor page components. When creating a new portlet, users choose the Constructor Page Component Wizard, wherein they can choose an existing Constructor page component to which they have access. Once they choose this page component and hit Finish, this choice is stored as an Administrative Preference for the new portlet instance, and whenever that portlet instance is displayed on a portal page, it can dynamically surface the given Constructor page component. There are security implications here: (a) a user cannot select a page component to which they do not have access, and (b) a user cannot view the contents of a Constructor portlet which contains a page component to which they do not have access. In the latter case, a friendly error message can be displayed. At any time, given appropriate portal access, users can go back and point at a different Constructor page component. There are no restrictions in place to prevent a user from deleting a Constructor page component being surfaced in the portal. Here, a friendly error message will again be displayed telling the user that the content no longer exists. In general, page components should “work” and look just like the page components do inside of Constructor.
Data spaces can allow Constructor users to create a full-blown UI for managing data. There can be a few data space templates that ship with Constructor, e.g., RSS, blogging, and so on. In addition, users can create a data space from scratch. Once a data space is created, users can access the data in the data space via a set of different URLs, each unique to the data space and the type of view on the data that URL provides.
Use Cases: users can create data spaces for tracking things like feature lists, to-dos, customer phone calls, project tasks, and so on. In addition, data spaces will prove valuable for blogging, and for keeping track of information published by other Web sites (via RSS). Data spaces can be important in that they let users add structured and unstructured content to each of the views they express. So, for example, for each feature listed in a feature list, one could attach rich text, documents, images, and even further, additional data spaces around a single feature.
To create a new data space, users can navigate to the Dashboard, and click the Create a data space link. This can pop up a wizard. The first step users must take is to specify a template for their Data Space. Out of the box, there are several templates: blog, custom, and RSS. In addition, customers can add new data space templates to this list, which key off data provided by external Web services. In total, there are three “types” or “sources” of data: Local (blogging, custom, etc.), RSS (only RSS), and External (all the Web service based data space templates). This partitioning is mainly an artifact of the server-side implementation of these data spaces, but also serves to help users decide the type of data space they want to create. In one embodiment, only Local data spaces are read/write; all others are read-only. Once a user picks a data space template, they are then navigated to a separate wizard, specific to that type of data space. The next few features outline those. Common to all data spaces, however, is the fact that each has a Title, a URL, and a Description. This can make it easy to find (and navigate to) the data space in the system once it has been created. Once one of those data spaces is created, the user can then navigate to either (a) the component where the data space will be surfaced, or (b) the List view for the data space. This navigation decision is based on where the data space was created from.
Once a user decides they want to create a custom data space, either to display this data space in its native UI, or via a page component, they can be taken to the Custom data space Configuration Wizard. In this wizard, users can specify a set of fields for the data space. Each of these fields has a set of properties: Field Title, Field Type, Display Order, Is the Title Field?, Is Required?, and in the case of a DropDown field, the options that show up in the DropDown menu. Users can specify any title for each of these fields; and users can specify the field type: Text, MultiLineText (shows up as an HTML textarea), RichText (shows up as a rich text field), DropDown (shows up as an HTML select menu with options), and DynamicDropDown (shows up as an HTML select menu with options). Users can go back at any time and modify each of these settings.
For a given securable container, such as (a) system, (b) live space or (c) data space, a given user can have one of many roles. The set of roles in Constructor can include: Guest, Reviewer, Creator, Publisher, Editor, and Administrator. A user having a given role can mean that user has a certain collection of privileges, which let them perform a certain set of actions within that given container. Moreover, having a certain role for a given container can also mean that a user can see certain data within the given container. For each of the containers described above, Constructor can ship a fixed set of roles a user can have. The roles for each container differ slightly, and are described below. It is worth noting that groups can also have roles, and that by being a member of a group that has a role, a user assumes that role.
Roles can be collections of privileges. Privileges can be hidden from end users. The roll-up of these privileges, however, can be exposed to users via roles. Therefore, when a user has a given role, they then can have a collection of privileges. Privileges help govern what a user can see and do in the system.
Constructor can let users define ACLs (access control lists) for live spaces and data spaces. ACLs help the system decide what a user can see or do for a given container (LS or DS). ACLs take on a very simple form: they are a list of principal/role pairs, where a principal is either a user or a group, and a role is one of the roles described above. Users can choose users and groups with the user and group selector, which can be populated with users and groups from the ALI database. The ACL UI can allow full CRUD operations on the control list.
Security evaluation can be done when a user tries to access a given resource or perform a given action. When this happens, several things can occur: (a) the user is in a role that has the ability to see the given resource, or perform the given action on the given resource; (b) the user is in a role that can see the resource, but cannot perform the given action on the resource; or (c) they cannot even see the resource to begin with. Because security is applied at the container level, security evaluation can be done against the ACL of either the object in question (if the object in question happens to be a container itself, like a live space), or a parent container of the object in question. If a user does not have the ability to perform an action, an exception propagates to the UI. This takes the form of an error page, which lists out why they cannot do what they are trying to do.
Constructor need not store information about users and groups, and can instead rely on a portal product to do so. Any time a user tries to do something in Constructor, their user identity can be retrieved from either the portal or other session, and mapped against the corresponding ACL (which would include a role that is mapped to a portal user or group they are in). Group membership evaluation can be done at runtime (but may be cached).
Whenever a container object is created, a default set of principals can be added to the ACL for that object. This default set can include: (a) the portal Administrators group, and (b) the principal who is creating the object. This default list can be extended/modified by customers via an unsupported feature known as security templates.
Whenever a user performs an auditable action (modify, create, etc.), that action can be stored with the given object. Through the UI, this action can then be displayed; e.g., Michael created this page. This can always display the appropriate name associated with the given user object in the portal. If the name changes on the portal object, the name in Constructor should update wherever that user performed an action.
The Action Pane can provide a base set of functionality that allows users to interact with content surrounding a given page (or record page). This can include: other pages (or record pages), documents, records, data spaces, and so on. Usually, a user will use the Action Pane when they want to navigate to another object in the system.
Embodiments of the present invention can include computer-based methods and systems which may be implemented using conventional general purpose or a specialized digital computer(s) or microprocessor(s), programmed according to the teachings of the present disclosure. Appropriate software coding can readily be prepared by programmers based on the teachings of the present disclosure.
Embodiments of the present invention can include a computer readable medium, such as computer readable storage medium. The computer readable storage medium can have stored instructions which can be used to program a computer to perform any of the features present herein. The storage medium can include, but is not limited to, any type of disk including floppy disks, optical discs, DVD, CD-ROMs, micro drive, and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, flash memory or any media or device suitable for storing instructions and/or data. The present invention can include software for controlling both the hardware of a computer, such as general purpose/specialized computer(s) or microprocessor(s), and for enabling them to interact with a human user or other mechanism utilizing the results of the present invention. Such software may include, but is not limited to, device drivers, operating systems, execution environments/containers, and user applications.
Embodiments of the present invention can include providing code for implementing processes of the present invention. The providing can include providing code to a user in any manner. For example, the providing can include transmitting digital signals containing the code to a user; providing the code on a physical media to a user; or any other method of making the code available.
Embodiments of the present invention can include a computer-implemented method for transmitting the code which can be executed at a computer to perform any of the processes of embodiments of the present invention. The transmitting can include transfer through any portion of a network, such as the Internet; through wires, the atmosphere or space; or any other type of transmission. The transmitting can include initiating a transmission of code; or causing the code to pass into any region or country from another region or country. A transmission to a user can include any transmission received by the user in any region or country, regardless of the location from which the transmission is sent.
Embodiments of the present invention can include a signal containing code which can be executed at a computer to perform any of the processes of embodiments of the present invention. The signal can be transmitted through a network, such as the Internet; through wires, the atmosphere or space; or any other type of transmission. The entire signal need not be in transit at the same time. The signal can extend in time over the period of its transfer. The signal is not to be considered as a snapshot of what is currently in transit.
The foregoing description of preferred embodiments of the present invention has been provided for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations will be apparent to one of ordinary skill in the relevant arts. For example, steps preformed in the embodiments of the invention disclosed can be performed in alternate orders, certain steps can be omitted, and additional steps can be added. The embodiments were chosen and described in order to best explain the principles of the invention and its practical application, thereby enabling others skilled in the art to understand the invention for various embodiments and with various modifications that are suited to the particular used contemplated. It is intended that the scope of the invention be defined by the claims and their equivalents.
Claims
1. A method for extending ad hoc information around structured data, comprising:
- creating a web interface for structured data;
- combining the structured data through the web interface with unstructured data, wherein one or more users can collaborate to combine the structured data through the web interface with the unstructured data without administrative approval; and
- producing groups of pages extending ad hoc information around the structured data, wherein versions of the groups of pages are tracked.
2. The method of claim 1, wherein producing groups of pages includes assembling one or more page components on a page.
3. The method of claim 2, wherein the one or more page components is a view of an ad-hoc application.
4. The method of claim 2, wherein each page component has its own URL.
5. The method of claim 1, wherein an active page represents an object as an individual page to which unstructured content can be added collaboratively by one or more users.
6. The method of claim 2, wherein whether a page component is displayed to a user is controlled by security.
7. The method of claim 1, wherein one or more users can revert the groups of pages to earlier versions.
8. The method of claim 1, wherein the combination of structured data through the web interface with unstructured data results in a data space.
9. The method of claim 1, wherein the groups of pages are in a live space.
10. The method of claim 1, further comprising creating a wiki for structured data.
11. A computer readable storage medium storing instructions for extending ad hoc information around structured data, the instructions comprising:
- creating a web interface for structured data;
- combining the structured data through the web interface with unstructured data, wherein one or more users can collaborate to combine the structured data through the web interface with the unstructured data without administrative approval; and
- producing groups of pages extending ad hoc information around the structured data, wherein versions of the groups of pages are tracked.
12. The computer readable storage medium of claim 11, wherein producing groups of pages includes assembling one or more page components on a page.
13. The computer readable storage medium of claim 12, wherein the one or more page components is a view of an ad-hoc application.
14. The computer readable storage medium of claim 12, wherein each page component has its own URL.
15. The computer readable storage medium of claim 11, wherein an active page represents an object as an individual page to which unstructured content can be added collaboratively by one or more users.
16. The computer readable storage medium of claim 12, wherein whether a page component is displayed to a user is controlled by security.
17. The computer readable storage medium of claim 11, wherein one or more users can revert the groups of pages to earlier versions.
18. The computer readable storage medium of claim 11, wherein the combination of structured data through the web interface with unstructured data results in a data space.
19. The computer readable storage medium of claim 11, wherein the groups of pages are in a live space.
20. The computer readable storage medium of claim 11, further comprising creating a wiki for structured data.
Type: Application
Filed: Apr 24, 2008
Publication Date: May 28, 2009
Applicant: BEA SYSTEMS, INC. (San Jose, CA)
Inventors: Matias Cudich (San Francisco, CA), Stephan Dennis Morais (San Francisco, CA)
Application Number: 12/109,133
International Classification: G06F 17/00 (20060101); G06F 3/048 (20060101);
