Patent Application
20200210210
The present disclosure relates generally to systems and methods for enabling widget extension via extension point hooks.
This section is intended to introduce the reader to various aspects of art that may be related to various aspects of the present disclosure, which are described and/or claimed below. This discussion is believed to be helpful in providing the reader with background information to facilitate a better understanding of the various aspects of the present disclosure. Accordingly, it should be understood that these statements are to be read in this light, and not as admissions of prior art.
Enterprises and other organizations may develop various applications that are licensed or sold to other entities and which may be implemented on various types of computational hardware, network infrastructures, or computational instances. The implementation of the applications to perform a given operation may be realized via the implementation of script (e.g., computer code or logic). In some contexts, the script configured to run on a given client environment instance may be extensible, such that an initial version of an application provided or sold to the entity using the application may be extended to include additional or alternative sets of instructions specific to that entity, such as instructions for accommodating entity-specific functions and widgets into an initial version of the application. In this manner, an entity may extend aspects of the initial version of the application (e.g., the “out-of-the-box” version) to specifically cater to diverse and/or specific needs of the entity. For example, a given application script may be modified to include specific branding or interface themes, selectable widgets, and the like, altering the initial version of the application to meet the needs or purposes of the organization or entity using the application.
However, extending the initial version of the application to cater to these entity preferences, by modifying the associated script, alters the application in a way unique that is unique to the client. In some contexts these customer extensions to the initial version of the application may be overridden and undone at a later time, for example, after performing an enterprise-prompted update to the initial version of the application. When the enterprise-prompted update is applied, the enterprise may prompt the entity to update the application from the initial version of the application to an updated version of the application to improve functionality, remedy previous issues in the script, and so forth. As a result, the script associated with the initial version of the application and its various widgets may be modified in response to the update, such that the extension of the customer may be overridden or erased in response to the update, resulting in a loss of productivity, time, and resources, as the entity may have to remodify the updated script (of the updated version of the application) to include the previously incorporated modifications to the initial version of the application. In addition or alternatively, the enterprise-prompted update may be ignored (i.e., not be applied) in order to preserve customer extensions, resulting in the entity not having access to the latest version of an application and the most recent functionality. As a result, regardless of whether the update is applied or whether the update is ignored, choosing between apply or ignoring the enterprise-wide update may be inconvenient and inefficient. Accordingly, there is a need to improve the manner in which applications are extended and updated.
A summary of certain embodiments disclosed herein is set forth below. It should be understood that these aspects are presented merely to provide the reader with a brief summary of these certain embodiments and that these aspects are not intended to limit the scope of this disclosure. Indeed, this disclosure may encompass a variety of aspects that may not be set forth below.
The present approach relates to updating an initial version of an application in such a manner that customer extension of certain widgets in the initial version of the application are preserved thorough the update. Using embodiments disclosed herein, a cloud-computing system may facilitate customer extension of a widget of an initial version of the application by providing a first subset of script associated with an extension point hook, such that the first subset of script may receive customer script to extend the widget. In this manner, customers may extend aspects of the widget by modifying script via the extension point hooks to cater those extensible widgets to specific customer needs in a manner that can be maintained as updates occur over time. Indeed, using the embodiments disclosed herein, the cloud-computing system may receive the customer extensions, such as modifications to script (e.g., computer code or logic) via the extension point hooks, to extend the widget. An enterprise who licenses usage of the initial version of the application to the customers may push server-wide updates to the initial version of the application, such that the customer extensions made via the extension point hooks to certain widgets are preserved through the update, allowing the customer to retain customization through the update, while enabling the customer to save time and resources that would otherwise be consumed by re-extending the application after the enterprise upgrades the application.
Various aspects of this disclosure may be better understood upon reading the following detailed description and upon reference to the drawings in which:
One or more specific embodiments will be described below. In an effort to provide a concise description of these embodiments, not all features of an actual implementation are described in the specification. It should be appreciated that in the development of any such actual implementation, as in any engineering or design project, numerous implementation-specific decisions must be made to achieve the developers' specific goals, such as compliance with system-related and business-related constraints, which may vary from one implementation to another. Moreover, it should be appreciated that such a development effort might be complex and time consuming, but would nevertheless be a routine undertaking of design, fabrication, and manufacture for those of ordinary skill having the benefit of this disclosure.
As used herein, the term “computing system” may refer to client-server electronic computing system accessible via various electronic devices, such as, but not limited to, a single computer, virtual machine, virtual container, host, server, laptop, and/or mobile device, or to a plurality of electronic computing devices working together to perform the function described as being performed on or by the computing system. In some embodiments, the computing system may be realized via any suitable circuitry, such as a processor-based device, memory devices, storage devices, and the like. As used herein, the term “medium” refers to one or more non-transitory, computer-readable physical media that together store the contents described as being stored thereon. Embodiments may include non-volatile secondary storage, read-only memory (ROM), and/or random-access memory (RAM). As used herein, the term “application” refers to one or more computing modules, programs, processes, workloads, threads and/or a set of computing instructions executed by a computing system. Example embodiments of an application include software modules, software objects, software instances and/or other types of executable code.
As used herein, the term “widget” refers to a user interface element of a graphical user interface (GUI) that operate as a small, self-contained application or applet within the GUI. As such, a widget may be associated with instructions that are executed by a processor-based device to present data (e.g., a graph, plot, etc.) to the user, and to update the data (e.g., summary or graphic data) based on changes to the underlying data. Additionally, certain widgets can be configured by users to provide extended functionality that can be saved for later access and/or transferred to other users. In some contexts, the selection of the widget may present a scripting interface that includes a rectangular area with inextensible (e.g., out-of-the-box (OOTB)) content and empty boxes, such that the empty boxes represent the extension point hooks. Customers may fill these empty boxes (e.g., extension point hooks) within the overall rectangular widget with their extended script (e.g., computer code or logic) to extend the overall widget functionality. In some contexts, the extension point hooks may be easily identified by customers, for example, because the extension point hooks are labelled differently (e.g., with a different color, font size or style, etc.) than the content that may not be extended.
Furthermore, as used herein, an “initial version” of an application may refer to a version of an application (e.g., software modules, software objects, software instances and/or other types of executable code) distributed by a developer, such as an enterprise, a software or application developer, and the like, as part of a sale, licensing arrangement, or other distribution scheme. In some contexts, an initial version of an application as used herein may refer to an OOTB version of the application, which corresponds to an initial, prior, or original version of the application as, for example, as distributed for sale or licensing by one or more clients or customers. Additionally or alternatively, the initial version of an application may correspond to versions of the application unextended, unmodified, or uncustomized by the customer. In other contexts, the initial version of the application may refer to the last functioning version of the application, which in some instances, may correspond to the earlier version of the application or the product release version of the application. In certain instances, the initial version of the applications may be extensible by a purchasing or licensing entity to accommodate client-specific constraints and/or enhance performing client-specific operations. The extended version of the application, as discussed herein, may be referred to as a version of the application that has been extended (e.g., customized, modified, etc.) to include additional functionality or features specific to the customer.
As set forth above, extension of the initial version of the application may be realized via selection of a visual indication on the widget. As used herein, “visual indication” may refer to a portion of the widget that when selected causes a scripting interface to be presented. The scripting interface may include the extension point hooks. “Extension point hooks” refer to an area within the scripting interface where additional content (e.g., script) may be added by a customer via an extension. Such an extension involves adding Hypertext Markup Language (HTML) script, Cascading Style Script (CSS), and/or any other suitable script code or logic. Visual indications on the GUI may be associated to and/or presented on a corresponding widget to indicate that the corresponding widget is extensible, for example, in such a manner that the corresponding widget is able to receive client modifications that may be preserved through an enterprise-wide update.
Along similar lines, the scripting interface associated with the corresponding widget may open in response to selection of the visual indication of the widget. The scripting interface may include script associated with the corresponding widget. The scripting interface may also include extension point hooks that may receive script modification to modify the corresponding widget, accommodating client-specific constraints and/or enhancing the performance of client-specific operations. The scripting interface may also include portions of the script that do not include the extension point hooks, and are therefore inextensible script. After the initial version of the application has been extended based on customer preferences, the application is herein referred to as an “extended version of the application.” Additionally, “updated version of the application” as used herein, refers to a version of an application updated, for example, in response to an enterprise-wide software update.
With this in mind, enterprises and other organizations may develop various applications licensed or sold to other entities and which may be implemented on various types of computational platforms. The implementation of the applications to perform a given operation may be realized via the implementation of script. In some contexts, the script configured to run on a given platform or client instance may be extensible, such that an initial version of an application provided or sold to the entity may be extended to include additional or alternative sets of instructions specific to that entity, such as instructions for addressing issues or contexts specific to that entity. In this manner, an entity may extend aspects of the initial version of the application (e.g., the “out-of-the-box” version) to specifically cater to diverse and/or specific needs of the entity. For example, a given application script may be modified to include specific branding or interface themes, selectable widgets, and the like, altering the initial version of the application to meet the needs or purposes of the organization or entity using the application.
However, extending the initial version of the application to cater to these entity preferences, may alter the application in such a manner than the customer extensions may be overridden and undone at a later time, for example, after performing an enterprise-prompted update to the initial version of the application. Typically, the enterprise may prompt the entity to update the application from the initial version of the application to an updated version of the application to improve functionality, remedy previous issues in the script, and the like. As a result, the script associated with the initial version of the application and its various widgets may be modified in response to the update, such that the extension of the entity may be overridden or erased in response to the update, resulting in a loss of productivity, time, and resources, as the entity may have to remodify the script to include its previously incorporated modifications to the application. In addition or alternatively, the enterprise-prompted update may be ignored (i.e., not be applied) in order to preserve customer customizations, resulting in the customer not having access to the latest version of an application and the most recent functionality. As a result, regardless of whether the update is applied or whether the update is ignored, choosing between apply or ignoring the enterprise-wide update may be inconvenient and inefficient. Accordingly, there is a need to improve the manner in which applications are customized and/or updated, such that entity extension of the widgets or features with respect to the initial version of the application are preserved through subsequent changes (e.g., periodic software updates), the implementation of which may be difficult to employ in practice.
The present approach relates to updating an initial version of an application in such a manner that customer extension of certain widgets in the initial version of the application are preserved thorough the update. Using embodiments disclosed herein, a cloud-computing system may facilitate customer extension of a widget of an initial version of the application by providing a first subset of script associated with an extension point hook, such that the first subset of script may receive customer script to extend the widget. In this manner, customers may extend aspects of the widget by modifying script via the extension point hooks to cater those extensible widgets to specific customer needs in a manner that can be maintained as updates occur over time. Furthermore, using the embodiments disclosed herein, the cloud-computing system may receive the customer extensions, such as modifications to script (e.g., computer code), via extension point hooks, to extend the functionality of widgets. Additionally, script without extension point hooks may be inextensible to the client. The script may be presented via a scripting interface. The cloud-computing system may include one or more extension point, each extension point hook may be associated with a specific scripting language (e.g., HTML, CSS, etc.). In this manner, an enterprise who licenses usage of the initial version of the application to the customers may upgrade an extended version of the application in such a manner that the customer modifications to the second set of the plurality of widgets (e.g., the widgets having the visual indication) are preserved through the upgrade, allowing the customer to retain extensions through the upgrade and enabling the customer to save time and resources that would otherwise be consumed by modifying the extended version of the application after the enterprise upgrades the application.
With the preceding in mind, and by way of context, the following figures relate to various types of generalized system architectures or configurations that may be employed to provide services to an organization in a multi-instance framework and on which the present approaches may be employed. Correspondingly, these system and platform examples may also relate to systems and platforms on which the techniques discussed herein may be implemented or otherwise utilized. Turning now to
For the illustrated embodiment,
In
To utilize computing resources within the platform 20, network operators may choose to configure the data centers 22 using a variety of computing infrastructures. In one embodiment, one or more of the data centers 22 are configured using a multi-tenant cloud architecture, such that one of the server instances 24 handles requests from and serves multiple customers. Data centers with multi-tenant cloud architecture commingle and store data from multiple customers, where multiple customer instances are assigned to one of the virtual servers 24. In a multi-tenant cloud architecture, the particular virtual server 24 distinguishes between and segregates data and other information of the various customers. For example, a multi-tenant cloud architecture could assign a particular identifier for each customer in order to identify and segregate the data from each customer. Generally, implementing a multi-tenant cloud architecture may suffer from certain drawbacks, such as a failure of a particular one of the server instances 24 causing outages for all customers allocated to the particular server instance.
In another embodiment, one or more of the data centers 22 are configured using a multi-instance cloud architecture to provide every customer its own unique customer instance or instances. For example, a multi-instance cloud architecture could provide each customer instance with its own dedicated application server(s) and dedicated database server(s). In other examples, the multi-instance cloud architecture could deploy a single physical or virtual server and/or other combinations of physical and/or virtual servers 24, such as one or more dedicated web servers, one or more dedicated application servers, and one or more database servers, for each customer instance. In a multi-instance cloud architecture, multiple customer instances could be installed on one or more respective hardware servers, where each customer instance is allocated certain portions of the physical server resources, such as computing memory, storage, and processing power. By doing so, each customer instance has its own unique software stack that provides the benefit of data isolation, relatively less downtime for customers to access the platform 20, and customer-driven upgrade schedules. An example of implementing a customer instance within a multi-instance cloud architecture will be discussed in more detail below with reference to
Although
As may be appreciated, the respective architectures and frameworks discussed with respect to
With this in mind, and by way of background, it may be appreciated that the present approach may be implemented using one or more processor-based systems such as shown in
With this in mind, an example computer system may include some or all of the computer components depicted in
With respect to other components, the one or more busses 84 includes suitable electrical channels to provide data and/or power between the various components of the computing system 80. The memory 86 may include any tangible, non-transitory, and computer-readable storage media. Although shown as a single block in
With the preceding in mind,
The flow diagram 100 may include presenting (process block 102) a first set of widgets (i.e., those widgets with the visual indications) and/or presenting (process block 104) a second set of widgets (i.e., those widgets without the visual indications), in response to running an initial version of an application. The client instance 42 may present (process blocks 102, 104) the widgets with and/or the widgets without the visual indications on the GUI accessible to a client, as illustrated and described below with regard to
In this manner, the cloud-computing system 10 may enable (process block 106) client extension of the script (e.g., via extension point hooks) associated with a widget having the visual indication and prevent client extension of the script associated with a widget not having the visual indication. As discussed in detail below, with regard to
Furthermore, one or more devices of the cloud-computing system 10 may update (process block 108) the extended or initial version of the application and the widgets associated with that version of the application, for example, in accordance with an enterprise-wide software update pushed to all client instances. By employing the embodiments disclosed herein, updating the extended or initial version of the application may upgrade the widgets associated with the extended or initial version of the application while preserving the client extensions to a widget made via the extension point hooks. In one embodiment, updating (process block 108) the initial version of the application may include modifying (process block 110) a portion of the scripting interface without extension point hooks to include aspects of the update while incorporating (process block 112) the client extensions made via extension point hooks onto the updated application. In one implementation, modifying (process block 110) the portion of the scripting interface without extension point hooks may include replacing the script without extension point hooks with the new script associated with the update. In another implementation, updating the extended or initial version of the application may include portions of the script that have not received customer extensions, regardless of whether the script include extension point hooks or not.
Incorporating (process block 112) onto the updated application the client extensions made via the extension point hooks may include leaving the script associated with the extension point hooks unaltered by the update, such that the client extensions to the widget are preserved through the update. Alternatively, incorporating process block 112) the client extensions of the script with extension point hooks onto the upgraded application may include modifying the script with extension point hooks that have been extended by the client and not modifying the script with extension point hooks that have not been extended by the client. In this manner, the client extensions are preserved through the update, while updating as much of the application that has not been extended by the client.
After the initial version of the application has been updated, a client instance running on the cloud-computing system 10 may run the updated version of the application. The updated version of the application may apply the update while maintaining the customer extensions made via the extension point hooks.
To help illustrate,
As discussed above, the visual indication 212 may serve as a visual indication, conveying to the customer that the corresponding widget 210 may be extended by a customer in such a manner that the extension is preserved through an update, such as an enterprise-wide software update. Furthermore, a customer may customize those widgets 210 with the visual indication 212 by selecting the visual indication 212. For example, a customer may select the first visual indication 212A to customize the article number 230 associated with the first widget 210A or the customer may select the second visual indication 212B to customize the article information (including, in the this example, the state, audience, author, date created, and so forth) associated with the second widget 210B. For purposes of this discussion, after the customer extends functionality of a widget 210 having a visual indication 212, the initial version of the application 202 becomes an extended version of the application.
While the illustrated example includes three widgets, it should be understood that provision of such example is meant to facilitate discussion and is not intended to limit the scope of the disclosure. For example, in some contexts, an application may include any number of widgets with any suitable selectable visual indication that may convey to a customer that the corresponding script may be extended by the customer in such a manner that the extension is preserved through an update.
In response to selection of the visual indication 212, the cloud-computing system may cause the client device 14 to present a scripting interface that may allow a customer to modify existing script, add existing script, or delete existing script associated with the widget via extension point hooks. To that end,
In this example, the scripting interface 302 may include respective text boxes (or scroll down menus) for specifying a widget name 310 (in this example “KBArticleViewHeader”), an API name 312, an application type 316, and a brief description 320. Furthermore, the scripting interface 302 may include a scripting window 330 for extending (e.g., modifying), adding, deleting, and so forth, script associated with the widget 210 via the extension point hooks 304. The scripting window 330 may include extension point hooks 304 that may receive customer extended script, such that the script received via the extension point hooks 304 is preserved through an update. As illustrated, the extension point hook 304 may include a blank text box that may receive suitable script (e.g., HTML, CSS, etc.). In some contexts, the extension point hooks 304 may be associated with existing script, such that the existing script associated with the extension point hooks 304 may be extended based on customer extensions made via the extension point hook 304. Further, the scripting interface may include any number of (e.g., one or more) extension point hooks 304. As illustrated, the scripting window 330 may also include inextensible script 332. In some contexts, the extension point hooks 304 may be separated from the inextensible script 332, such that the extension point hooks 304 and the inextensible script 332 are contained in respective text boxes.
The scripting interface 302 may also include a first selectable feature 340 for updating and saving changes made to the script via the extension point hooks 304, such that the saved changes are pushed into the widget 210 when the application containing the widget is run. Additionally, the scripting interface 302 may include a second selectable feature 350 for deleting the selected script. While only a few features of the scripting interface are discussed with respect to
The specific embodiments described above have been shown by way of example, and it should be understood that these embodiments may be susceptible to various modifications and alternative forms. It should be further understood that the claims are not intended to be limited to the particular forms disclosed, but rather to cover all modifications, equivalents, and alternatives falling within the spirit and scope of this disclosure.
The techniques presented and claimed herein are referenced and applied to material objects and concrete examples of a practical nature that demonstrably improve the present technical field and, as such, are not abstract, intangible or purely theoretical. Further, if any claims appended to the end of this specification contain one or more elements designated as “means for [perform]ing [a function] . . . ” or “step for [perform]ing [a function] . . . ”, it is intended that such elements are to be interpreted under 35 U.S.C. 112(f). However, for any claims containing elements designated in any other manner, it is intended that such elements are not to be interpreted under 35 U.S.C. 112(f).
