Content Package Generation for Web Content

Content package generation techniques are described. In one or more implementations, one or more inputs are received via an authoring tool of a computing device to compose a web content project in accordance with a dynamic stylesheet language. The web content project is processed into a content package automatically and without user intervention by the computing device. The processing includes verifying syntax of the web content project, performing one or more unit tests on web content project, and taking portions of the web content project into corresponding locations in a hierarchical structure of nodes of the content package.

BACKGROUND

There is an ever increasing amount of web content made available via the Internet for consumption by a browser, a web-enabled application, and so on. Developers may employ a variety of different techniques to compose and deploy this web content for consumption by users.

However, conventional techniques that are available to developers did not adequately address a transition between composing the web content and deployment of the content. Accordingly, these conventional techniques could be frustrating and time consuming to developers, which often resulted in the developers forgoing use of the techniques.

SUMMARY

Content package generation techniques are described. In one or more implementations, one or more inputs are received via an authoring tool of a computing device to compose a web content project in accordance with a dynamic stylesheet language. The web content project is processed into a content package automatically and without user intervention by the computing device. The processing includes verifying syntax of the web content project, performing one or more unit tests on web content project, and taking portions of the web content project into corresponding locations in a hierarchical structure of nodes of the content package.

DETAILED DESCRIPTION

Overview

Conventional techniques that are utilized to generate content packages are often limited in support of transitions between developing the web content and generating a package that includes the web content. Accordingly, conventional techniques may rely on a variety of different manual processes to test and prepare the content for addition to an appropriate file structure and format, which could be frustrating to developers of web content that wish to leverage the content packages.

Content package generation techniques for web content are described. In one or more implementations, an automated system is described that may operate without user intervention to generate a content package. For example, a user may interact with an authoring tool to compose a web content project, such as in accordance with a LESS dynamic stylesheet language. The system may then be utilized to process the web content project into a content package, which may be configured for consumption via a content repository application programming interface (API).

For example, a user may provide one or more user inputs to initiate processing of the web content project (e.g., a command, gesture, use of a cursor control device, and so on) into a content package that is configured for consumption via a content repository API for Java® (JCR). This processing may include converting the web content project from a LESS configuration to a cascading style sheets (CSS) configuration, verification of syntax, processing of images if included, performing unit test cases, extracting inline documentation, taking portions of the web content project into corresponding locations in a hierarchical structure of the content package, installation on an executing content management system, and so on. In this way, the system may be utilized to package the web content as tested and verified automatically and without user intervention, thereby increasing a likelihood that these actions will be undertaken by a developer of the web content. Further discussion of these techniques may be found in relation to the following sections.

In the following discussion, an example environment is first described that may employ the techniques described herein. An implementation example and example procedures are then described which may be performed in the example environment as well as other environments. Consequently, performance of the example procedures is not limited to the example environment and the example environment is not limited to performance of the example procedures.

Example Environment

FIG. 1is an illustration of an environment100in an example implementation that is operable to employ techniques described herein. The illustrated environment100includes a computing device102, a service provider104, and another computing device106that are communicative coupled via a network108. The computing devices102,106, as well as the computing devices that implement the service provider104, may be configured in a variety of ways.

A computing device, for instance, may be configured as a desktop computer, a laptop computer, a mobile device (e.g., assuming a handheld configuration such as a tablet or mobile phone), and so forth. Thus, computing devices may range from full resource devices with substantial memory and processor resources (e.g., personal computers, game consoles) to a low-resource device with limited memory and/or processing resources (e.g., mobile devices). Additionally, although a single computing device may be described in the following, reference to a computing device may be representative of a plurality of different devices, such as multiple servers utilized by a business (e.g., the service provider104) to perform operations “over the cloud” as further described in relation toFIG. 6.

Although the network108is illustrated as the Internet, the network may assume a wide variety of configurations. For example, the network106may include a wide area network (WAN), a local area network (LAN), a wireless network, a public telephone network, an intranet, and so on. Further, although a single network108is shown, the network108may also be configured to include multiple networks.

The service provider104is illustrated as including a service manager module110. The service manager module110is representative of functionality of the service provider104to manage web content112as part of one or more network-based services. The web content112may be configured in a variety of ways, such as one or more webpages of a website, configured for access as part of a network-based application, and so on.

In the illustrated environment, the computing device102includes a web content development module114that is representative of functionality to compose the web content112, e.g., for use by a developer. Computing device106, on the other hand, is illustrated as including a web content consumption module116that is representative of functionality to consume the web content112, e.g., as a browser, as part of a network-based application, and so on. Although illustrated separately, it should be readily apparent that the represented functionality may be combined on a single computing device (e.g., computing device102may be used to both develop and consume the content), may be further distributed (e.g., as part of a network service), and so on.

The web content developer module114is illustrated as including an authoring tool118that is executable to provide a user interface via which a developer may compose the web content112. As such, the authoring tool118may be configured in a variety of different ways. For example, the authoring tool118may be configured to support a style sheet language to describe presentation of a web content project in a markup language, such as XML and so on.

A content packaging module122is also illustrated, which is representative of functionality that may be employed to package a web content project as a content package124, e.g., the web content project received from the authoring tool118or elsewhere. The content packaging module122, for instance, may configure the web content project in accordance with a hierarchical (e.g., tree-like) structure having a plurality of nodes with associated properties. Thus, a parent/child relationship of the nodes may also define a relationship of content associated with the nodes. In this way, the structure of the content package124may specify how content of the content package124is to be accessed.

As previously described, the computing device106includes a web content consumption module116that is representative of functionality to consume web content112, which may include the content package124that was communicated for distribution via the network108by the service provider104. The web content consumption module116includes a content management system126(CMS) having a content repository API128. The content repository API128may be configured to follow a specification for access to the content package124, such as in accordance with a content repository API for Java® (JCR) or other dynamic runtime language. The content management system126may thus be used to maintain and manage content associated with the content package124as well as content received via other techniques (e.g., as single files) via the content repository API128, which may include versioning metadata and so on.

Thus, the content management system126may operate as a type of object database to store, search, and retrieve hierarchical content. As such, the content package124may also be configured by the content packaging module122in accordance with this database, such that a hierarchical structure of the content package124is configured in accordance with the hierarchical structure of the object database maintained by the content management system126.

As previously described, conventional techniques that were utilized to generate a content package124did not support a transition between development of the content and building of the content package124. This could cause developers to forgo use of testing and verification to make sure the web content “functions as intended.” However, the content packaging module122may perform operations associated with this transition automatically and without user intervention, such as through configuration as a configurable build system that aggregates several tools into a single configuration that provides a simple, configurable, and intuitive way to build a fully-tested content package124. An example of such a system is described as follows and shown in corresponding figures.

Example Implementation

The following discussion describes content package generation techniques that may be implemented utilizing corresponding systems and devices, as well as other systems and devices. Further, the systems and devices may also be utilized to perform other procedures and arrangements thereof. Aspects of the procedure ofFIG. 5may be implemented in hardware, firmware, or software, or a combination thereof. The procedure500is shown as a set of blocks that specify operations performed by one or more devices as illustrated by the corresponding systems200,300,400ofFIGS. 2-4and are not necessarily limited to the orders shown for performing the operations by the respective blocks. Accordingly, the following discussion is arranged as including a description of the system and procedures in parallel.

FIG. 2depicts a system200in an example implementation in which a web content project is developed and one or more techniques are performed to process the web content project into a content package. The system200is illustrated through the use of first, second, and third stages202,204,206in this example.

At the first stage202, one or more inputs are received via an authoring tool of a computing device to compose a web content project in accordance with a dynamic stylesheet language (block502). A developer, for instance, may interact with the authoring tool218to describe presentation semantics of a document, which may be expressed in a markup language such as XML. This may be performed in a variety of ways.

For example, the authoring tool218may be configured to support a dynamic stylesheet language, such as LESS, to generate a web content project208having web content210. Therefore, instead of writing directly to a cascading style sheets (CSS) language directly, the authoring tool218may support the use of a variety of different functionality made available via the dynamic stylesheet language. This functionality may include mixins (e.g., which permit embedding of properties of a class into another class), variables and variable assignment, nesting (e.g., logical nesting in which the code blocks themselves are not nested, but rather selectors are nested to specify inheritance), operators and functions, and so on. Other examples are also contemplated in which the authorizing tool218is configured to accept one or more inputs to compose CSS directly.

As illustrated, the web content210may include a variety of different types of data, which may include a variety of different types of static content. Examples of this content include LESS files212as described above, stylesheet declarations and objects214, dynamic runtime source code216, may include images218, fonts, inline documentation222, unit test cases224, and other226content. It should be readily apparent that portions of the data may be optionally included as part of the web content210of the web content project208.

Regardless of how the web content210originated, the web content project208may then be processed into a content package automatically and without user intervention by a computing device (block504). This may include use of a variety of different techniques responsive to a single input from a user to begin the processing, e.g., a command, gesture, voice command, and so on.

At the second stage204, for instance, syntax of the web content project is verified (block506). As described above, the web content210may include stylesheet declarations and objects214. Accordingly, the content packaging module122may employ a content verification module228to check syntax, including type errors and so on. For example, declaratives (e.g., LESS/CSS declaratives) and objects (e.g., Javascript® or other dynamic runtime objects) may be linted and verified such that the declaratives and objects do not contain syntax errors or break defined styling rules of the stylesheet language.

At the third stage206, one or more static files of the web content project are converted from the dynamic stylesheet language into a configuration in accordance with Cascading Style Sheets (CSS) (block508). As previously describes, LESS files212may be generated for use of a variety of functionality such as nesting, variables, mixins, and so on. However, LESS files212may be incompatible with browsers and other functionality (e.g., web-enabled applications) that are configured to consume web content210. Accordingly, the content packaging module122may leverage a file conversion module230to convert the LESS files into CSS files232or other stylesheet language that is consumable by such functionality.

FIG. 3depicts a system300in an example implementation in which one or more additional techniques are performed to process the web content project into a content package. The system300is also illustrated through the use of first, second, and third stages302,304,306in this example. At the first stage302, images in the web content are processed (block510), if included. For example, the web content210may optionally include images308, which may be configured in a variety of ways. Accordingly, the images308may be processed for inclusion as part of the web content project210in a corresponding variety of ways. This may include placement as an inline directive into a CSS class312, such as by conversion into a format in accordance with Base64which is included as part of the CSS files. The images308may also be converted by the image processing module310into a font. This may include processing vector graphics (e.g., monochrome vector graphics) by the image processing module310into parts of a font file to support use in a manner that is similar to use of any other defined font. The image processing module310may also support techniques involving sprites316such that a portion of a larger image is defined. In this way, that portion may be used such that a larger image may be leveraged for a variety of uses. A variety of other examples are also contemplated.

At the second stage304, one or more unit tests are performed on the web content project (block512). As previously described, the web content210may include unit test cases318. These unit test cases may be specified manually as part of the web content. Accordingly, a content test module320may be employed to perform these tests to determine if functions operate as intended, e.g., to test variables, mathematical operations, and so on. If one of the tests fail, the content packaging module122may cease processing of the web content210used to form the content package124.

At the third stage306, documentation is extracted from one or more static files of the web content210to create one or more pages having the documentation (block514). As illustrated, the web content210may include inline documentation322as part of the source code of the web content210. This inline documentation may be parsed and applied by a documentation module324to a template to form one or more documentation pages326that include this inline documentation. In this way, the documentation page326may serve as a resource to locate documentation that describes functions included in the source code in a markup language page that may be included as part of the content package124.

FIG. 4depicts a system400in an example implementation in which one or more further techniques are performed to process the web content project into a content package. The system400is also illustrated through the use of first and second stages402,404.

At the first stage402, portions of the web content project are taking into corresponding location in a hierarchical structure of nodes of the content package (block516). The content structuring module406, for instance, may be employed to process a result of one or more of the previous operations ofFIGS. 2 and 3. This processing may include placement into a hierarchical structure408that corresponds to a client library structure of the content management system126. In this way, the content package214is formed that is compatible with a content repository API128such that the content management system126knows “where” to place portions of the content package124(i.e., which nodes) in a content repository maintained by the content management system126.

Additional operations may also be performed by the content structuring module406. This may include formation of reference files, e.g., to be compatible with a content repository API for Java® (JCR) through generation of “js.txt” and “css.txt” files that include line-by-line lists of files to be used for JavaScript® and CSS files, respectively.

At the second stage404, the content package420is illustrated as being installed on an actively executing content management system126. The content package124as previously describe may include a hierarchical structure408that is understood via the content repository API128, which is this instance is illustrated as being executed by a computing device102of the developer. Other examples are also contemplated, such as automatic upload of the content package124to the service provider104as part of the web content112, output of a prompt to perform this upload, and so on.

Example System and Device

FIG. 6illustrates an example system generally at600that includes an example computing device602that is representative of one or more computing systems and/or devices that may implement the various techniques described herein. This is illustrated through inclusion of the content packaging module122, which may be configured to package web content as described above. The computing device602may be, for example, a server of a service provider, a device associated with a client (e.g., a client device), an on-chip system, and/or any other suitable computing device or computing system.

The processing system604is representative of functionality to perform one or more operations using hardware. Accordingly, the processing system604is illustrated as including hardware element610that may be configured as processors, functional blocks, and so forth. This may include implementation in hardware as an application specific integrated circuit or other logic device formed using one or more semiconductors. The hardware elements610are not limited by the materials from which they are formed or the processing mechanisms employed therein. For example, processors may be comprised of semiconductor(s) and/or transistors (e.g., electronic integrated circuits (ICs)). In such a context, processor-executable instructions may be electronically-executable instructions.

Combinations of the foregoing may also be employed to implement various techniques described herein. Accordingly, software, hardware, or executable modules may be implemented as one or more instructions and/or logic embodied on some form of computer-readable storage media and/or by one or more hardware elements610. The computing device602may be configured to implement particular instructions and/or functions corresponding to the software and/or hardware modules. Accordingly, implementation of a module that is executable by the computing device602as software may be achieved at least partially in hardware, e.g., through use of computer-readable storage media and/or hardware elements610of the processing system604. The instructions and/or functions may be executable/operable by one or more articles of manufacture (for example, one or more computing devices602and/or processing systems604) to implement techniques, modules, and examples described herein.

The cloud614includes and/or is representative of a platform616for resources618. The platform616abstracts underlying functionality of hardware (e.g., servers) and software resources of the cloud614. The resources618may include applications and/or data that can be utilized while computer processing is executed on servers that are remote from the computing device602. Resources618can also include services provided over the Internet and/or through a subscriber network, such as a cellular or Wi-Fi network.

The platform616may abstract resources and functions to connect the computing device602with other computing devices. The platform616may also serve to abstract scaling of resources to provide a corresponding level of scale to encountered demand for the resources618that are implemented via the platform616. Accordingly, in an interconnected device embodiment, implementation of functionality described herein may be distributed throughout the system600. For example, the functionality may be implemented in part on the computing device602as well as via the platform616that abstracts the functionality of the cloud614.

CONCLUSION