Patent Application
20110314370
Managing and updating pages for viewing on computing devices can be difficult. Page sources include logic that controls how the page operates and code that controls how the page appears to viewers. Integration of page logic and code can make modification of the page difficult, breaking page function and leading to incongruous visual appearance with other pages. As a result, page developers may need to sort through extensive code when making a change to the appearance, delaying roll-out of page appearance upgrades and delaying the introduction of new page features.
A page controller module is provided for generating a pageview on a computing device according to a page definition that identifies a plurality of blocks corresponding to the pageview. In response to the page definition, and for each of the plurality of blocks, the page controller module initializes a block controller module for the block, which issues data requests to receive values for parameters associated with the block. Further, view modules are provided for rendering the viewable portion of the page using the values received in response to data requests from the block controller module. In some embodiments, block controllers may register data requests with the page controller so that the page controller may manage fulfillment of the data requests. The page controller may manage fulfillment by scheduling registered data requests and/or by reducing redundancies in registered data requests.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to implementations that solve any or all disadvantages noted in any part of this disclosure.
Some approaches to generating page 102 include model-view-controller frameworks, which separate the graphical user interface from the business logic for exchanging information between a data model and the graphical user interface. However, because these approaches include manually crafted code for each page and because the code and markup may co-mingle on the page, such approaches may make it difficult to modify page appearance without breaking the page logic. For example, a user wishing to change the look of a page without changing the page logic may labor to search for and modify the relevant markup text.
Thus, a tiered approach for generating a page for viewing on a client computing device is provided. On a first tier, a lightweight page controller module configured to generate a pageview is provided. In response to receiving a request to display a page, the page controller identifies a page definition for the page. The page definition identifies a plurality of blocks for the page, each of which corresponds to a viewable portion of the page when the page is displayed. Thus, the user may change the content of the page, such as block location, without altering the underlying logic by editing the page definition.
In response to the page definition, and for each of the plurality of blocks, the page controller module initializes, on a second tier, a block controller module for each block. Each block controller module is assigned to manage, and contains all of the business logic for controlling, the rendering of a specific rendered block 104. Each block controller module issues data requests to receive values for parameters associated with the block. Example values include any suitable data type, such as strings, structured data, numbers, etc. Thus, in one scenario, a block controller may request a value for a song title and receive a value comprising the title of the song requested, metadata associated with the song title requested, and any other suitable information.
Each block controller module operates independent of, and indifferent to, any other block controller modules initialized by the page controller module. Further, view modules are provided for rendering the viewable portion of the page using the values received in response to data requests from the block controller module. Thus, editing the page definition manifests a changed content and layout of page 102, while the two tiers of controllers provide an approach to modularly controlling rendering of page 102.
For example,
Client computing device 250 includes mass storage 256, display 208, and memory 252 for storing instructions executable on processor 254. Example client computing devices 250 include, but are not limited to, a wireless computing device, a gaming console, and a mobile phone. As shown in
Pageview generating system 200 includes, at server computing device 202, a page controller module 212 for identifying and loading the page definition, and for initializing a plurality of block controller modules 214 according to the page definition. Block controller modules 214 register data requests with page controller module 212 according to block parameters 213 sent from page controller module 212 to block controller modules 214. Page controller module 212 then manages fulfillment of the data requests. Page controller module 212 requests, from data model 230, the data requests registered by block controller modules 214. In some embodiments, page controller module 212 may generate a schedule directing when data requests are made and what data will be requested. This may reduce redundancies in data requests and may avoid network traffic jams at data model 230. Each block controller module 214 passes the requested data received from data model 230 (via page controller module 212) to a complementary view module 216 for rendering on page 102.
View modules 216 generate markup code based on the requested data received from corresponding block controller modules 214. View modules 216 are instantiated by corresponding block controller modules 214. For example, a block controller module 214 may issue a render command including instructions to create and initialize view module 216 and instructions to create rendered block 104. Thus, in some embodiments, block controller modules 214 may instruct corresponding view modules 216 to render without being aware of the eventual appearance of rendered block 104, so that all markup code inserted onto page 102 is inserted by view modules 216.
Alternatively or additionally, in some embodiments, view modules 216 may comprise templates including a markup language, such as extensible markup language (XML) or hypertext markup language (HTML). Such templates may include placeholders to be substituted with specific data values passed from the corresponding block controller module 214. While the various modules described above are shown at server computing device 202, it will be appreciated that, in some embodiments, page controller module 212, block controller modules 214, and view modules 216 may be present on any suitable computing device. Additionally or alternatively, it will be appreciated that, in some embodiments, such modules may be distributed across two or more computing devices, such as in a server farm or server cloud environment.
As depicted in
As depicted in the embodiment of
Page definition element 306 comprises a plurality of block elements 316. Block elements 316 describe each of the rendered blocks 104 that will be displayed on page 102. In some embodiments, page definition 300 may define the structure of the rendered blocks by reference to row and column location. This may provide flexibility for developers when creating layout schemes for pages. In the example shown in
In some embodiments, optional style tags 312 may be included for one or more row elements 310 and/or column elements 314. Additionally, in some embodiments, attributes for each row and column location may be copied into tags inserted in page 102. Thus, for example, inline CSS style tag IDs and tag names may persist on page 102.
Block elements 316 comprise the specific block parameters 213 passed from page controller module 212 to the corresponding block controller module 214. Each block element 316 includes a block ID 318 for identifying and differentiating instances of a given block on a page. Further, each block element 316 includes a block controller module ID 320 for identifying each rendered block 104 and the block controller module 214 associated therewith.
In some embodiments, block element 316 may include one or more filtering parameters 319 specifying particular data to be obtained from data model 230. For example, a first instance of a tour schedule block may include a location filtering parameter configured to present tour dates for the USA (e.g., <BLOCK ID=“_TOURSCHEDULE” CONTROLLER=“TOURSCHEDULE” LOCATION=“USA”/>) and a second instance of the tour schedule block may include a location filtering parameter configured to present tour dates for Europe (e.g., <BLOCK ID=“_TOURSCHEDULEEU” CONTROLLER=“TOURSCHEDULE” LOCATION=“EUROPE”/>). While the example described herein relates to location filtering, it will be appreciated that any suitable filtering parameter 319 may be included in block element 316.
For example, as depicted in
Similarly,
Continuing with the example of
At 402, method 400 comprises receiving a display request to display a page from a user at the page controller, such as a page controller of a server computing device. In the example shown in
At 406, method 400 comprises, in response to the display request, at the page controller module, identifying a page definition associated with the page, where the page definition identifies a plurality of blocks for the page, each of which corresponds to a viewable portion of the page when the page is displayed. For example, the page controller may identify the page definition based on parameters included in the display request. In one scenario, a page definition for an artist page may be identified based on an artist ID included in the display request. In some embodiments, the page definition may be coded in a markup language format, such as an XML or an HTML format.
Additionally or alternatively, in some embodiments, the page definition may include a layout of the plurality of blocks on the page for defining a size and a location of one or more blocks on the page. Further, in some embodiments, the layout may define row and column locations of one or more of the plurality of blocks on the page. Further still, in some embodiments, the page definition may include a tuner tag identifying a rendering target for the page.
At 408, method 400 comprises, in response to the page definition, and for each of the plurality of blocks, initializing a block controller module for the block. Each block controller module is configured to modularly control rendering of a viewable portion of the requested page. Thus, each block controller module manages the behavior and the appearance of each rendered block on the page. In some embodiments, method 400 may include, at 410, at the page controller module, causing the execution of each block controller module in response to the page controller module identifying the page definition.
At 412, the page controller module sends block parameters for each of the block elements included in the page definition to the block controller module identified in the block element. Thus, the page controller module may pass block parameters included in the page definition to the relevant block controller modules. Example block parameters include, but are not limited to, block IDs, block controller module IDs, artist IDs, and filtering parameters. In one scenario, the page controller module may include, in a block parameter sent to a block controller module, an artist ID included in a display request received by the page controller module.
At 414, method 400 includes, at the block controller modules, registering data requests for the data model with the page controller module prior to the block controller modules obtaining the requested data from the data model. At 416, method 400 includes, at the page controller module, managing data request fulfillment.
In some embodiments, managing data request fulfillment may include, at 418, scheduling data requests at the page controller module such that the data requests are sent from the page controller module to a data model according to predetermined scheduling criteria. Thus, in some embodiments, predetermined scheduling criteria may specify that data requests are sent in parallel, in a particular sequence, or by combining non-overlapping data requests. This may accelerate page rendering by reducing data request serialization and/or by reducing network traffic to and from the data model.
Additionally or alternatively, in some embodiments, managing data request fulfillment may include, at 420, reducing redundancies in the data requests to be sent to the data model. This may accelerate page loading by reducing network traffic and/or by allowing the data model to fulfill the data requests in a more efficient manner. For example, reducing redundancies may include, at 422, for a plurality of block controller modules that have registered overlapping data requests, issuing a single, combined data request to the data model, receiving requested data from the data model in response to the single, combined data request, and sending select portions from the requested data to the block controller modules such that a particular block controller module receives select data according to the data request registered by the particular block controller module. Thus, in one scenario, a first block controller module may register a request for a list of songs that are playable and a second block controller module may register a request for a list of songs and play counts for those songs. The page controller module may send a single, combined data request for the list of songs, a list of playable songs, and play counts for the songs, to the data model. Upon receiving the requested data, the page controller may select a portion of the requested data, specifically the list of playable songs, for transmission to the first block controller module. The page controller may also select the list of songs and the play counts for those songs from the requested data for transmission to the second block controller module. While the above scenario addresses requests that are overlapping in scope, it will be appreciated that a similar approach may be used in scenarios having completely overlapping, or duplicative, requests.
At 424, method 400 includes issuing data requests, from the page controller module, to the data model, to receive values for parameters associated with the block. In some embodiments, the data requests may be issued by a data layer managed by the page controller module. At 426, method 400 includes sending values for the requested data from the data model to the page controller module.
At 428, method 400 includes sending a render command from the page controller module to the block controller module. In some embodiments, the render command may include a portion of the requested data. Alternatively or additionally, in some embodiments, a portion of the requested data may be sent from the page controller module to the block controller module before the render command is issued.
At 430, method 400 includes sending rendering instructions from the block controller modules to the view modules. The rendering instructions include instructions to create the view modules and/or to render the block. At 432, method 400 includes, at the view modules, rendering the viewable portion of the page using the values received in response to the requests registered from the block controller module. Thus, in some embodiments, rendering the viewable portion of the page may be performed by passing, from the block controller module to a view module, the values received in response to the data requests issued from the block controller module. In some embodiments, the view module may render the viewable portion of the page using a markup template. Method 400 further includes, at 434, sending the page for display. In some embodiments, sending the page at 434 may include sending markup for the page for display. At 436, method 400 includes displaying the page. In the example shown in
It will be appreciated that the computing devices and servers described herein may be suitable computing devices configured to execute the programs described herein. For example, the computing devices may be mainframe computers, personal computers, laptop computers, portable data assistants (PDAs), computer-enabled wireless telephones, networked computing devices, or other suitable computing devices, and may be connected to each other via computer networks, such as the Internet. These computing devices typically include a processor and associated volatile and non-volatile memory, as well as a mass storage device such as a hard drive. These computing devices are configured to execute programs stored in non-volatile memory using portions of volatile memory and the processor, to achieve the functionality described herein. The computing devices may be configured with user input devices such as keyboards, mice, and touch screens, for example, and further may be equipped with displays.
Further, as used herein, the terms “program” and “module” refer to software or firmware components that may be executed by, or utilized by, one or more computing devices described herein, and is meant to encompass individual or groups of executable files, data files, libraries, drivers, scripts, database records, etc. It will be appreciated that computer-readable storage media may be provided having program instructions stored thereon, which upon execution by a computing device, cause the computing device to execute the methods described above and cause operation of the systems described above. Computer-readable storage media may include a memory device such as random-access memory (RAM), read-only memory (ROM), a hard disk, a compact disc (CD), digital video disc (DVD), etc. Some or all of the programs and modules described herein may be software modules or hardware components, such as memory devices.
It may be appreciated that a “service” as used herein, may be an application program executable across multiple user sessions and available to other operating system components and applications. A service may run on a server responsive to a request from a client.
It is to be understood that the configurations and/or approaches described herein are exemplary in nature, and that these specific embodiments or examples are not to be considered in a limiting sense, because numerous variations are possible. The specific routines or methods described herein may represent one or more of any number of processing strategies. As such, various acts illustrated may be performed in the sequence illustrated, in other sequences, in parallel, or in some cases omitted. Likewise, the order of the above-described processes may be changed.
The subject matter of the present disclosure includes all novel and nonobvious combinations and subcombinations of the various processes, systems and configurations, and other features, functions, acts, and/or properties disclosed herein, as well as any and all equivalents thereof.
