System and method for smart interaction between website components

Abstract

To provide a Website architecture system.SOLUTION: A Website architecture system (WBS) comprises a processor, at least one database for storing a Website component, and an extension component stored in the at least one database. The extension component 10 has an editor-behavior driver that provides a WBS editor with a container-specific edit logic and an override data handler that processes an override request between a smart container component and at least one received component and realizes a change of style, behavior and action.SELECTED DRAWING: Figure 3

Description

Technical Field

[0001] The present invention generally relates to website construction systems, and more particularly to smart containers and components.

Background Art

[0002] (Cross-reference to related applications) This application claims priority and benefit from U.S. Provisional Patent Application No. 62 / 516,682, filed Jun. 8, 2017, and U.S. Provisional Patent Application No. 62 / 665,629, filed May 2, 2018, which are hereby incorporated by reference herein.

[0003] Website construction systems are very popular and allow users to build websites that look and function like those created by professionals. Many of these systems offer both a method for beginners to build a website from scratch and a method for more experienced users.

[0004] A website generally consists of a visually designed application composed of multiple pages. These pages are displayed individually and may contain components. A website construction system may support a hierarchical composition of components that uses atomic components (such as text, images, shapes, videos, etc.) and various types of container components that house other components (such as normal containers, single-page containers, multi-page containers, gallery containers, etc.). Sub-pages contained within a container component are called mini-pages, each of which may contain multiple components. Some container components may display only one mini-page at a time, while others may display multiple mini-pages simultaneously. Next, referring to FIG. 1, a general representation of a website construction system 1 is shown, which consists of a website 2 having a web page 3. The web page 3 may be composed of a component 4 consisting of an atomic component 5 and a container component 6. Further, the container component 6 may be composed of various single-page containers 7 and multi-page containers 8. Additionally, the multi-page container 8 may house mini-pages 9. Other component types may include semantic composites 11, data / text repeaters 12, and image repeaters 13.

[0005] Repeaters (such as data / text repeater 12 and image repeater 13) can integrate information and data sources that are not related to the actual page editing process and the visual attributes of components. These data sources can be internal data lists or data from external sources, such as business or other information related to a website, its pages, and the website owner (if available). This data is combined with component / layout information to form multiple instances of repeating components within the repeater container, which may be automatically updated when the underlying data source changes. Such dynamic content repeaters can also support overrides and other operations.

[0006] Components may be contentless or may have internal content. Examples of the first category are star components, which have no internal content (although they have color, size, position, and several other parameters). Examples of the second category are text paragraph components, whose internal content includes internal text, as well as font, formatting, and layout information. Of course, this content may vary for each instance of the text paragraph component. Components with content are often called fields (such as "text fields").

[0007] Existing web pages generally consist of a combination of declarative HTML code that provides content and formatting, Cascading Style Sheets (CSS) that provides additional styling, and procedural JavaScript (JS) that provides a procedural foundation for the page.

[0008] The content of a web page may exist within a single file or a combination of files (e.g., HTML, CSS, and JS files). A typical configuration is a main HTML file that includes additional HTML, CSS, and JS files, with some of the included files being common to multiple pages (e.g., a common set of styles or JS libraries are used within multiple pages).

[0009] Such included files may be derived from multiple sources. Some files may be created by a single web page creator, or they may be created from various pre - defined HTML, CSS, or JS libraries or plugin modules created by multiple creators.

[0010] The pages of a website may be statically defined, i.e., the final - form files of those pages are stored on a web server and accessed by users via a browser (or other user - agent software). Such web pages may be created manually or using a system (e.g., web page editing or generation software, etc.) that creates (static) web pages based on user definitions.

[0011] Also, website pages may be dynamically generated when requested by a user, i.e., they may be dynamically (or semi - dynamically) composed. Such dynamic generation may be carried out via complete page generation. The entire page is created from defined sub - elements, where how to combine these elements is defined individually. Existing page templates can be used, filling some placeholders with data obtained from other sources.

[0012] Such dynamic pages may be created and implemented using an online web site construction system. The page definition may be created by a designer using the web site construction system, in which case the page definition is created using various provided elements (such as components, containers, third party applications, and page segments, etc.) assembled through the page creation environment.

[0013] The web site construction system generally stores the page definitions in a repository. These page definitions are read by the web site construction system during the runtime period and converted into web page information that is transferred to the site viewer. Next, these are rendered for the current view and instances of components are created.

[0014] The web site construction system may include client - side components, such as, for example, a JS application segment that is embedded in the generated page and executed by client - side or server - side code included within the application.

[0015] The process of converting the internal representation of the page definition of the web site construction system into HTML / CSS / JS code (executable by a browser) may be split in several ways between the elements of the web site construction system executed on the server and the client. In one embodiment, the entire conversion operation is performed on the web site construction system server, whereby a complete executable page is provided to the client machine of the viewer. Here, "executable" means a page that can be directly processed and rendered by the browser client.

[0016] In another embodiment, the definition of the internal format of the web site construction system is provided to the client (optionally extended with additional information), and the client - resident browser application performs the conversion and dynamic page construction to create the browser display page.

[0017] In yet another embodiment, the conversion operation is split between the server and the client, with each performing a part of the conversion.

[0018] Such a client-side application may also perform further roles such as processing of an image gallery that enables operations on the client side (such as moving / rearranging of images) (using the server to interface with, for example, simply the underlying database).

[0019] The processing and rendering may be performed in the context of a session between the server and the client. Such a session may be maintained by the server, for example, to support an application viewing session.

[0020] The website building system may be extended using third-party applications and their components and list applications (as described in more detail in Patent Document 1 entitled "DEVICE, SYSTEM, AND METHOD OF WEBSITE BUILDING BY UTILIZING DATA LISTS", which is incorporated herein by reference, assigned to the common assignee of the present invention, and published on September 18, 2014).

[0021] Such third-party applications and list applications may be purchased (or otherwise obtained) from an application store (either incorporated within or external to the website building system) or directly from the vendor (seller) of the third-party application through some distribution mechanism, such as being pre-included in the design environment of the website building system.

[0022] A website construction system is usually provided by a website construction system vendor. The website construction system is used by a user (also called a designer) who designs a website. And those websites are used by the users-of-users (also called end users) of the user.

[0023] Third-party applications may be hosted on the servers of the website construction system vendor itself, on the servers of the third-party application vendor, or on the infrastructure of a fourth-party server.

[0024] Existing systems usually enable editing at the component level, including the container level. Therefore, existing systems usually provide operations such as adding components (e.g., by selecting components from a menu of available component types and using drag-and-drop), deleting components, moving and resizing components, changing the content of components, changing the attributes of components (e.g., through a floating or fixed attribute panel applicable to the component being edited), placing components within a container, or removing components from a container.

[0025] Also, existing systems may allow components to be grouped (e.g., by using multiple selections of components along with a group / ungroup operation). Then, the system may allow operations such as moving, resizing, or changing an attribute (e.g., color) to be performed on all components within the group.

[0026] Patent Document 2 titled "SYSTEM AND METHOD FOR IMPLEMENTING CONTAINERS WHICH EXTRACT AND APPLY SEMANTIC PAGE KNOWLEDGE", which is incorporated herein by reference, assigned to the common assignee of the present invention, and published on February 1, 2018, describes how a container can be composed of several sets of components that can form a semantic composite (such as the semantic composite 11 in FIG. 1) as a result of the analysis of components of a web page known as a smart box. The smart box may provide a UI or interface that enables specific changes to be applied to multiple contained smart boxes (in some cases, at multiple containment levels). Patent Document 2 describes strict semantic composite matching (applying changes only to types that match the smart box) and soft matching (applying changes simply when applicable to a specific smart box). These changes may include style changes, addition / removal of components, layout changes, decorative element changes, etc. Patent Document 2 also describes special editing behaviors for adapting a set of components with specific functions and requirements. Such smart box containers (defined based on page analysis) may also support overrides and other operations.

PRIOR ART DOCUMENTS

PATENT DOCUMENTS

[0027]

PATENT DOCUMENT 1

PATENT DOCUMENT 2

PATENT DOCUMENT 3

PATENT DOCUMENT 4

Patent Document 5

Patent Document 6

Patent Document 7

Patent Document 8

Patent Document 9

Patent Document 10

Summary of the Invention

Means for Solving the Problems

[0028] According to a desirable embodiment of the present invention, a website construction system is provided. This system is at least one database that stores website components and a component hierarchy associated therewith, each component including an overrideable parameterized behavior element, a non-overrideable parameterized behavior element, and a data handler, the data handler handling an override protocol for the component; an element handler that reviews all components to be rendered for the current view and for the current component, processes a request for communication between the current component and at least one other component within the component hierarchy to satisfy an override request from at least one other component, and updates the current component according to the data handler of the current component only when the override request relates to an overrideable parameterized behavior element of the current component.

[0029] Furthermore, according to a desirable embodiment of the present invention, this system further comprises a runtime server that activates an element handler for the current components of the current view.

[0030] Furthermore, according to a desirable embodiment of the present invention, this system further comprises a WBS (Website Building System) editor having information on parameterized behavior elements that enable a user to select a component and apply editing changes to the selected component.

[0031] Furthermore, according to a desirable embodiment of the present invention, the current component is at least one of a pre-defined component, a repeater component, and a semantic composite.

[0032] Furthermore, according to a desirable embodiment of the present invention, this system further comprises a page analyzer that identifies a component hierarchy for the current component and determines whether the current component is a semantic composite.

[0033] Furthermore, according to a desirable embodiment of the present invention, the element handler includes a request receiver that receives the current component and an override request from the WBS editor as a result of an editing change and / or from the runtime server as a result of a change to the current component by an external source, a component resolver that receives from the data handler of the current component which parameterized behavior elements of the current component are overrideable, applies a change to the override request accordingly, and resolves an override conflict between the current component and at least one other component in the hierarchy, and a negotiator that enables communication between at least one parameterized behavior element of the current component and at least one other component according to a protocol based on pre-defined override rules for the component resolver and the at least one other component.

[0034] Furthermore, according to a desirable embodiment of the present invention, the element handler is provided with an artificial intelligence / machine learning device that performs artificial intelligence and machine learning analysis based on user activities and the analysis of other websites and pages, and recommends an override of the website component based on the analysis.

[0035] Furthermore, according to a desirable embodiment of the present invention, the WBS editor includes a component editor that enables a user to create and define override rules for the parameterized behavior elements of website components, a component selector that enables the user to select components, and an editing behavior applicator that applies editing changes to the selected components.

[0036] Furthermore, according to a desirable embodiment of the present invention, the editing changes include at least one of selection, drag, drop, size change, copy, paste, and attribute modification.

[0037] Furthermore, according to a desirable embodiment of the present invention, the parameterized behavior element represents at least one of the style, body, and logic of the current component.

[0038] Furthermore, according to a desirable embodiment of the present invention, the override request is for the overrideable parameters of the parameterized behavior element.

[0039] Furthermore, according to a desirable embodiment of the present invention, the website component further includes at least one of an editor behavior driver that affects the representation and editing process of the component by the WBS editor, a runtime behavior driver that affects how the component is processed by the runtime server at runtime, and a component rendering function that provides rendering instructions for the current component to the WBS editor and the runtime server.

[0040] According to a desirable embodiment of the present invention, a method for a website construction system, comprising: storing website components and a component hierarchy associated therewith, each component including an overrideable parameterized behavior element, a non-overrideable parameterized behavior element, and a data handler, the data handler handling an override protocol for the component; reviewing all components to be rendered for the current view and the current component, processing a request for communication between the current component and at least one other component within the component hierarchy to satisfy an override request from the at least one other component, and updating the current component according to the data handler of the current component only when the override request relates to the overrideable parameterized behavior element of the current component.

[0041] Furthermore, according to a desirable embodiment of the present invention, this method further comprises, at runtime, initiating the steps of reviewing, processing, and updating as described above for the current component of the current view.

[0042] Furthermore, according to a desirable embodiment of the present invention, this method comprises, during an editing session, enabling a user to select a component and apply editing changes to the selected component.

[0043] Furthermore, according to a desirable embodiment of the present invention, the current component is at least one of a predefined component, a repeater component, and a semantic composite.

[0044] Furthermore, according to a desirable embodiment of the present invention, this method further comprises identifying a component hierarchy for a current component and determining whether the current component is a semantic composite.

[0045] Furthermore, according to a desirable embodiment of the present invention, the above-mentioned steps of reviewing, processing, and updating are, as a result of an editing change, from the above-mentioned steps enabling the user to do so, and / or as a result of a change to the current component due to a change from an external source, receiving the current component and an override request from the above-mentioned step of starting in the runtime, receiving from the data handler of the current component which parameterized behavior elements of the current component are overrideable, applying a change to the override request accordingly, and resolving an override conflict between the current component and at least one other component in the hierarchy, and enabling communication between at least one parameterized behavior element of the current component and at least one other component according to a protocol based on the above-mentioned steps of receiving, applying, and resolving and a predefined override rule for at least one other component.

[0046] Moreover, according to a desirable embodiment of the present invention, the above-mentioned steps of reviewing, processing, and updating further comprise performing artificial intelligence and machine learning analysis based on user activity and analysis of other websites and pages, and recommending an override of a modification for a website component based on the analysis.

[0047] Furthermore, according to a desirable embodiment of the present invention, the above steps that enable a user to select a component and apply an editing change include steps that enable the user to create and define an override rule for a parameterized behavior element of a website component, steps that enable the user to select a component, and steps that apply the editing change to the selected component.

[0048] Furthermore, according to a desirable embodiment of the present invention, the editing change includes at least one of selection, drag, drop, size change, copy, paste, and attribute modification.

[0049] Furthermore, according to a desirable embodiment of the present invention, the parameterized behavior element represents at least one of the style, body, and logic of the current component.

[0050] Furthermore, according to a desirable embodiment of the present invention, the override request is for an overrideable parameter of the parameterized behavior element.

Brief Description of the Drawings

[0051] The gist considered to be the present invention is shown in detail in the conclusion part of this specification and is clearly claimed. However, the present invention will be best understood with respect to both its configuration and operation method, together with their objectives, features, and advantages, by reading the following detailed description while referring to the accompanying drawings below.

[0052]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

[0053] It will be understood that, for the sake of simplicity and clarity of the explanatory diagrams, the illustrated elements are not necessarily drawn at a constant scale. For example, the dimensions of some elements may be exaggerated compared to other elements for clarity. Further, reference numerals may be repeated between the figures to indicate corresponding or similar elements when considered appropriate.

Embodiments for Carrying Out the Invention

[0054] In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to one of ordinary skill in the art that the present invention may be practiced without these specific details. In other instances, well-known methods, procedures, and components have not been described in detail so as not to obscure the present invention.

[0055] The applicant of the present application has noticed that the prior art systems do not take into account the complex behaviors and complex component interactions often required to maintain the look and feel of a website that is constantly in need of updates based on internal (i.e., designed by or explicitly for the website designer) and external factors. These updates (which may be specific at the component level) often require detailed knowledge of the use of the website construction system itself in order to efficiently define and implement them simply and efficiently. Further, website components (including external third-party application components) may have behaviors applied to them that affect other components within the same hierarchical structure across multiple hierarchical levels within the website construction system environment.

[0056] It will be understood that a typical website building system can have three types of users, namely, website building system vendor staff or component providers themselves who can be part of separate component providers (e.g., via a component store or a third-party application store), website designers themselves who build sites using the components, and viewers or end users who use the completed sites. It will also be understood that there may be some mixing among the classes. In particular, a website building system can allow a designer (or part of them) to edit existing components or even add their own new components. For example, a collection of components defined by a site designer can be saved as one component and made available to other site designers similar to those described in Patent Document 2, which is incorporated herein by reference, assigned to the common assignee of the present invention, and published on February 16, 2017 under the name "METHOD AND SYSTEM FOR SECTION-BASED EDITING OF A WEBSITE PAGE", and Patent Document 3.

[0057] The applicant of the present application recognizes that a website construction experience can be improved by a system that processes website components that have within themselves parameterizable behavior elements that can define, for example, the operational and / or visual behavior of the components. The components may use their parameterizable behavior elements to invoke a form of communication with other components and may be able to send and receive parameters, as will be described in more detail hereinafter. For example, Component A may notify Component B to replace parameterizable behavior element X of Component B with parameterizable behavior element Y. It will be understood that a given parameterizable behavior element may be pre-defined to be overrideable or not (otherwise not overrideable) in the context of a given component type or component instance. Thus, due to the hierarchical nature of a web page (shown in FIG. 1, for example), an operational change applied to a single current component may affect other components at all containment levels (although perhaps not at the same sub-level of the component having the effect), and vice versa. For example, containers may interact with multiple levels of contained components therein, and this interaction is based on a pre-defined protocol of rules that allows both the container and the contained components to determine in what manner any attribute of the contained components may be affected (by the container). The logic for this protocol may include rules for "negotiable" overrides for parameterizable behavior elements, along with awareness of component relationships with other components / containers such as, for example, geometry, semantics, content, edit history, etc. The contained components may likewise be able to affect their container.Override may mean changing the attributes or parameters of a parameterized behavior element, or as will be described in more detail herein, may mean a complete replacement of one or more parameterized behavior elements.

[0058] The applicant of the present application further recognizes that the above principles may be extended to support a container that can provide artificial intelligence (AI) and machine learning (ML)-based modifications to the layout configuration of the contained components. Such modifications may include only the layout (e.g., selecting a position and size), a set of restricted attributes (e.g., the container may provide a specific background image / video to the sub-container within it, or may simply affect the selection of colors, etc.), behavior, or the behavior of any specific contained component such as addition, removal, rearrangement, etc. of the contained components. In some embodiments, this may also be applied to non-container components.

[0059] Also, the applicant of the present application recognizes that the use of the above-described parameterized behavior elements can improve the manner in which web page formatting is defined compared to prior art methods such as Cascading Style Sheets (CSS). Existing CSS-based systems collect rules from multiple style sheets (provided by the browser, the user, and the site itself) and affect the style or behavior of elements by matching these rules to elements within the site. This matching is based on the selectors provided for each rule, which are generally based on HTML element types (e.g., DIV, etc.), classes, IDs, or combinations thereof. Prior art systems may further include components with default behavior and options to override them, but not by using parameterized behavior elements. Elements may have implicit (default) styles or behaviors. For example, a DIV is implicitly a box that expands to 100% of the available space of its parent element.

[0060] The applicant of the present application further recognizes that the use of the parameterized behavior elements enables the construction of styles across the entire web page by an additional function that allows the component to define who may or may not affect itself (for example, "only the gallery may modify its own size"). In particular, this definition may be based on component analysis regarding (for example) the content, geometry, type, semantic type, edit history, business information (BI), and relationships between components of the component. Such analysis may provide additional component classification and related information (not explicitly provided by the designer), and this information may be used to determine the applicability of styles (or other attributes) to the analyzed components. For example, in the case of "applying a red bevel to all pairs of detected images and captions within the container", the pairs of captions and images are detected (not predefined) through component analysis as described in Patent Document 2.

[0061] Next, refer to FIG. 2 which illustrates this detection and classification. In row 1, six unrelated objects, namely, three smiling faces and three captions, are shown. In row 2, it shows how the system, in accordance with the instruction, recognizes the pairs of smiling faces and captions (as semantic composites) and applies a frame around each face / caption pair. In row 3, it shows how, even when the user moves the caption of the "pair" on the right end, the distance between them is still within the definition of the face / caption pair, and thus the frame is still applied. Next, referring to row 4, it shows how, when the caption is moved outside the scope of the requirements of the semantic composite definition (and thus is no longer recognized as a semantic composite of the face / caption pair), the frame disappears from around this pair. In row 5, the image on the right end has been changed and the system does not recognize it as a smiling face, and thus no frame is drawn. It will be understood that this function cannot be applied to normal CSS because it cannot identify the pairs of face images and captions.

[0062] By this use, the Applicant of the present application has recognized that the components being housed can affect multiple levels (the components being housed nested within component containers), and as a result, the component modifications applied can become "deep". For example, "make all housed video players appear without a rewind button at all housing levels", or "apply a video background with video X to all housed sub - containers", etc.

[0063] Generally, the components of a website are highly configurable, and their attributes and operations can be affected by both internal and external sources (for example, components that are outside the normal site hierarchy and may not be visible within the site) up to the website construction system with which they are associated. For example, services that adapt specific site components to time or season. The list of housed components (within a given container of a page) may be predefined or may be determined dynamically and may be used in a number of different scenarios, for example, in a website construction system scenario where the components are predefined with accessible attributes, or in a non - website construction system scenario where an analysis is performed on a given website page to identify the categorization of that page into components, containers, and their attributes.

[0064] It will be understood that the definition of a website component generally includes three main sub-entities, namely, style, body, and logic elements (as well as additional elements as described in more detail hereinafter in this specification). The style of a component may be defined by any style definition language or an extended version thereof. The body of a component may be defined by any standard content definition language (such as HTML, XML, or JSON, for example), or by a self-developed or non-standard language (such as JSX, for example).

[0065] The logic of a component may be defined by any procedural language, such as JavaScript or TypeScript, or by any ordinary programming language that enables the use of native code elements in a website. Alternatively, it may be defined through a dedicated browser, a browser add-on, or a mobile app if the relevant website construction system at runtime is implemented using a native client. It contains the business / operational logic of the component. The logic definition language may also include various language extensions to the underlying language (such as the E-JS language that extends the ordinary JavaScript language, for example).

[0066] These elements, which are part of the component definition, will be understood to be referenceable (together) as the SBL (Style / Body / Logic) elements of the component. Such component definitions may be created outside the system using normal tools available to developers (such as editors). Alternatively, the system may provide a component editing environment (which may or may not be integrated with an editor). Such a component editing environment may be available only to the staff of the website construction system vendor. Or, this component editing environment may be made available to external component developers or site designers so that they can define their own components.

[0067] The component definition may also include additional information, such as multiple configurations and variants used under different conditions, and editing drivers and additional editing-related information (such as dynamic layout hints) that a system editor may use to support the editing of instances of a particular component within a web page. This additional information may also include, as will be described in more detail later in this specification, an editing preview for the current view and component rendering functionality used during both the runtime period.

[0068] It will be understood that the pages of a website may be constructed using a hierarchy of component instances that, in addition to the component definition reference, may include additional information (such as content, hierarchical position, screen position, size, various layouts, component metadata, and other attributes).

[0069] Next, referring to FIG. 3, this illustrates the definition of a representative extension component 10 in accordance with an embodiment of the present invention. It will be understood that the extension component 10 can enable smart interactions between related components by communicating style, behavior, and operation changes through the parameterized behavior elements contained therein. The extension component 10 may have an extended or additional structure that goes beyond the structure of a conventional web site component. The definition of the extension component may include elements of style, body, and logic as described above in this specification. However, it will be understood that it may also include parameterized behavior elements that allow overriding in some cases and not in others according to defined rules and protocol resolutions as described in more detail below.

[0070] The extension component 10 may also include an editor behavior driver 15A, a runtime behavior driver 15B, a component rendering function 15C, an override data handler 16, metadata 17, and a fixed area 18.

[0071] The editor behavior driver 15A can affect the manner in which the component and the components contained therein are processed by the editor in use (e.g., by providing dynamic layout hints).

[0072] The runtime behavior driver 15B can affect the manner in which the component and the components contained therein are processed during the runtime period. The component rendering function 15C can provide rendering instructions during both the edit preview and runtime periods. For example, an input component may use a quick response renderer to provide feedback useful to the user of the web site construction system.

[0073] The component rendering function 15C may usually be coordinated with the main rendering process of the website construction system and can affect (depending on the implementation of the website construction system) any part of the display process of the website construction system. For example, for a website construction system that displays pages through a browser, the component rendering function 15C can affect both the conversion of the saved page into HTML / CSS / JS and the rendering of the generated HTML / CSS / JS in the browser.

[0074] The override data handler 16 can notify the above-mentioned predefined rules and protocol resolution information about the component, that is, what the override conditions are. The metadata 17 may also include the metadata of the component (such as author information and internal reference ID, etc.). The fixed area 18 houses elements of the component that cannot be overridden, such as the area within the component where content is stored for each component instance.

[0075] It will be understood that the parameterized behavior elements can be regarded as equivalent to the function parameters in ordinary programming languages. Therefore, a single extended component 10 may accommodate a plurality of parameterized behavior elements, each of which has a different type and affects (if permitted) different parts of the extended component 10. For example, the parameterized behavior element type of the style may process the style, and the parameterized behavior element type of the layout may process the layout, etc. It will also be understood that the parameterized behavior elements do not necessarily conform to the standard SBL classification and may override a plurality of SBL elements and other elements.

[0076] Hereinafter, for the sake of convenience of explanation, it will be understood that the reference to the website component means the extended component 10 described above in this specification.

[0077] The parameterized behavior elements of the layout may define the manner in which internal (sub) components of a component, such as a slider gallery vs. a grid gallery vs. a Vbox, are arranged. The parameterized behavior elements of the style may define the visual parameters used by a component or its sub-elements.

[0078] Thus, for example, a page designer may embed a desired grid gallery component, but override its internal behavior and use a slider layout (by providing the parameterized behavior elements of the slider layout as part of a grid-based gallery) to arrange the contents of the gallery.

[0079] It will also be understood that some types of parameterized behavior elements (such as the parameterized behavior elements of the layout) may function as stand-alone components, i.e., without being applied to another component. Thus, the parameterized behavior elements of the grid layout may function as a simple grid component (alone).

[0080] Also, a component may support including a plurality of parameterized behavior elements that together with the component definition form a complete component. For example, a button component may support including a parameterized behavior element for the background and a parameterized behavior element for the layout. The button component may provide a basic framework for the button alone (e.g., provide a display object having a "pressed" and "not pressed" configuration and an "I was pressed" event trigger associated therewith). These two included parameterized behavior elements may provide the background for the button and the display layout for the elements described on the button.

[0081] These two parameterized behavior elements may be, for example, a video background parameterized behavior element (which displays a video background for the button) and a layout parameterized behavior element of the Hbox (horizontal box) type (which displays button surface elements such as labels and small icons horizontally side by side).

[0082] It will be understood that (for the above example) the parameterized behavior elements are not specific to the components of the button. The same video background parameterized behavior element and the Hbox type layout parameterized behavior element may be used separately or together for other component types (such as forms or containers, etc.). Furthermore, the invocation of the parameterized behavior elements may be part of a component instance (not its definition), so that one button may use, for example, the parameterized behavior element of the video background, and another button may use the parameterized behavior element of the image background.

[0083] It will also be understood that the parameterized behavior elements used within a component may use the properties and parameters of the component itself, and for a specific invocation of the parameterized behavior element, the specific properties and parameters provided as part of the instance definition of the host or parent component may also be used. A component may use multiple parameterized behavior elements of the same type for different parts of that component. For example, a two-column component may use one layout parameterized behavior element (such as a Vbox, etc.) for the first column and another layout parameterized behavior element (such as an Hbox, etc.) for the second column.

[0084] A parent component instance that includes a child component instance may modify the child component instance through the application of parameterized behavior elements, as described in more detail below herein (and vice versa). It will be understood that a single component may be modified by multiple types of parameterized behavior elements that affect various elements of the component's display and functionality. Such parameterized behavior element types may affect any of the component's SBL sub-entities, i.e., its style, body, and logic. Different parameterized behavior elements typically (but not always) affect different aspects of the component, and thus the order in which multiple parameterized behavior elements are "applied" to a component may or may not be relevant depending on the situation. A single parameterized behavior element may affect multiple SBL sub-entities of a component, e.g., both the style and body of a component. The actual application of parameterized behavior elements may be performed during the rendering process. A system that implements parameterized behavior elements may perform pre-processing while calling a component or page publication (to save follow-up processing).

[0085] As described above herein, one type of parameterized behavior element type is layout, which controls the layout (position and optionally size) of a component's sub-elements, such as the above-described Hbox (horizontal box) layout parameterized behavior element that displays internal elements along a horizontal line.

[0086] Another example is applying a parameterized behavior element of a matrix gallery layout to a general gallery component. A created matrix gallery component displays its internal elements in a matrix of rows and columns and may, in some cases, show more elements than allowed by the basic matrix size, by scrolling.

[0087] Yet another example is the parameterized behavior element of the user-movable layout, which arranges the internal elements in the order of a predetermined initial position, but allows the end user of the application to move these elements within the container during runtime (as defined by the container runtime behavior driver 15B).

[0088] As described above in this specification, another type of the parameterized behavior element type is style, which controls elements of the visual representation of a component (e.g., the color, margin, etc. of the component).

[0089] The parameterized behavior element type of style may be used, for example, for background replacement. A sophisticated video player component may include multiple customizable buttons and control areas. The parameterized behavior element type of style may be used to replace the colors and patterns of the backgrounds of the buttons and control areas to create a personalized version of the video player component.

[0090] Also, the parameterized behavior element type of style may affect other (non-layout) parameters of the contained component. This may be different from the parameterized behavior element that affects the representation of the component itself (rather than the component contained within the component).

[0091] As described above in this specification, a component definition may consist of a plurality of sub-elements (representing style, body, logic, and additional elements). As part of the component instance definition within an application, some of these elements may be overridden by parameterized behavior elements (which follow appropriate rule negotiation). These parameterized behavior elements for substitution may themselves have parameters that define their own behavior or function. There may be cases where such parameters are necessary (i.e., the parameterized behavior elements do not function without them), or alternatively, the parameterized behavior elements may provide defaults for their values.

[0092] For example, a button component may allow the specification of a parameterized behavior element for the style that controls the shape of the button. The parameterized behavior element for a particular style may provide a shape such as an ellipse and may accept parameters that define the vertical and horizontal diameters of the ellipse. A button instance may call this parameterized behavior element for the ellipse and may provide specific parameter values (e.g., 100 pixels for the vertical diameter, 200 pixels for the horizontal diameter, etc.).

[0093] Next, referring to FIG. 4, this illustrates the relationship between two components within an application. As can be seen, an instance of COMP2 within the application requires parameterized behavior elements obtained from another component (COMP1 in this scenario) for its component definition, as well as specific parameters for these parameterized behavior elements. And then, these parameterized behavior elements and parameters can affect the style, body, logic, and other elements of the component.

[0094] As illustrated in FIG. 4, a single component may receive a plurality of parameterized behavior elements from other components. This may be via a negotiation element (as described in more detail below in this specification). Such a plurality of parameterized behavior elements may have different or cumulative effects. For example, a gallery component may allow the use of two style parameterized behavior elements, namely, one that affects the background area of the gallery frame and one that affects the sub-components managed by the gallery.

[0095] It will be understood that a component may also receive from another component other (non-parameterized behavior element) composite or hybrid parameters, for example, parameters based on an aggregate type (such as a list, a structure, and a union, etc.).

[0096] Also, in embodiments where a web-like language (i.e., E-HTML / CSS / JS) is used to define a page or a component, the parameterized behavior elements may also use call parameters / attributes for the component (described in more detail below in this specification), or a style sheet having additional rules for a particular parameterized behavior element type, for example,

[0097]

Number

[0098] Parameterized behavior elements (such as parameterized behavior elements for layouts) will generally be understood to have limited / specific functions. This may only handle the physical layout of the components contained within the gallery (e.g., providing a matrix / slider carousel arrangement), and thus typically does not include the complete SBL specification. However, the parameterized behavior elements may contain certain additional attributes. For example, a parameterized behavior element type for a specific matrix layout may also include some visual attributes (e.g., applying a yellow background to some sub-components of the host component). However, the normal definition of a parameterized behavior element type for a layout focuses on the arrangement of sub-components and typically does not include additional attributes and properties.

[0099] Also, it will be understood that parameterized behavior elements are typically created through the component editing function of a website construction system (described in more detail below in this specification), or, in some cases, by a dedicated editor specific to the parameterized behavior element.

[0100] Thus, an extended component may include, in addition to its standard style, body, and logic, a parameterized behavior element that contains information regarding the component's layout, configuration, editor-driven aspects, rendering process, and runtime behavior. The extended component may accept parameters that can define, add, or modify SBL elements or portions thereof from other related components (via the parameterized behavior element).

[0101] Next, referring to FIG. 5, this illustrates a system 200 for smart interaction between a website component and a container, according to an embodiment of the present invention.

[0102] System 200 may include a website building system, an element to be extended handler 210, a WBS (website building system) runtime server 220, a WBS (website building system) editor 230, a site generation system 240, a content management system 250, and a page analyzer 260. The website building system 205 may communicate with a client system operated by the vendor staff 261 of the website building system, a site designer 262, a site viewer 263, and an external system 270.

[0103] It will be understood that the functions of System 200 and its elements may be similar to those of System 100 described in Patent Document 2.

[0104] It will be further understood that the workflow of System 200 may have three stages. The first stage may be component definition, the second stage may be page definition, and the third stage may be page resolution as part of a runtime process implemented by the WBS runtime server 220 through a preview process using the WBS editor 230, as described in Patent Document 2.

[0105] The element to be extended handler 210 may process the communication between related website components regarding the parameterized behavior elements. Next, referring to FIG. 6, the elements of the element to be extended handler 210 are illustrated therein. The element to be extended handler 210 may include a request receiver 211, a resolver 212, a negotiator 213, and an AI / machine learning device 214 that may incorporate AI and machine learning principles to be described in more detail below in this specification.

[0106] Next, referring to FIG. 7, as illustrated therein, a CMS (content management system) 250 may hold all forms of content and layout related to the website construction system 205. The content management system 250 may include a website component type repository 2501, a website Parameterized-Behavior Elements repository 2502, a WBS (website construction system) component repository 2503, a WBS site repository 2505, a business intelligence repository 2506, an Editing History repository 2507, a user information repository 2508, a rule repository 2509, an ML / AI (machine learning / artificial intelligence) repository 2510, a layout repository 2511, and a Content Management System COORDinator 2512 for coordinating data between the content management system 250 and the system 200. It will be understood that the setup and functions of the CMS 250 may be similar to those of the CMS 50 in Patent Document 2.

[0107] The page analyzer 260 may preprocess and analyze an incoming web page to identify data structures and the relationships between them, as described regarding the page analyzer 44 in Patent Document 4, which is the specification of a U.S. patent entitled "SYSTEM AND METHOD FOR THE CREATION AND USE OF VISUALLY-DIVERSE HIGH-QUALITY DYNAMIC LAYOUTS," issued on Aug. 29, 2017, and assigned to the common assignee of the present invention. It will be understood that in this way, the page analyzer 260 may identify semantic composites, repeater components, and a general component hierarchy.

[0108] The WBS editor 230 may be a visual editor of a normal website construction system that recognizes how to process parameterized behavior elements and the ability regarding extended components that provide special editing behavior. The WBS editor 230 may also have a sufficient understanding of the data structure of the page being edited. The WBS editor 230 may enable vendor staff 261 and / or designers 262 to interactively edit / create website pages as described in more detail below in this specification. Next, referring to FIG. 8, elements of the WBS editor 230 are illustrated therein. The WBS editor 230 may include a component selector 231, an editing behavior applicator 232, and a component / container editor 233.

[0109] The WBS editor 230 may include a visual editing stage, a set of component selection panels, and a visual property editor that includes a plurality of (layout-related or non-layout-related) properties for each component or container. These visual property editors may be displayed through a property sheet presenter. The WBS editor 230 may access a set of available components (provided by the vendor of the website construction system (from the CMS 250) and by third-party component providers) and use the information obtained from these components in the page editing environment.

[0110] One such use is in creating an interface that enables the component metadata 17 (such as the component name, description, type, and origin), the SBL information, and the selection of components to be included in the page. The component selector 231 may further construct an interface for each of the SBL elements of the selected components, for example, by providing a style selection UI that displays styles related to a set of components on the page or a selected subset thereof.

[0111] Another such use is for components to provide their corresponding customization / configuration / property editing UIs, which are included in the WBS editor 230 and may enable the website designer 262 to customize specific component instances. This can be implemented in several ways.

[0112] A component may provide a complete configuration UI (user interface), i.e., the component definition may include the configuration UI used in the WBS editor 230 to configure the component. This may be a complete UI code (e.g., a UI that can be displayed using an individual iFrame), or a set of parameters provided to the WBS editor 230 that generate and present the actual configuration UI.

[0113] Such a configuration UI takes the form of an alternative component version used to edit the aspects and attributes of the component in-place, providing an editing function and UI at the same location occupied by the component. Also, a component may provide multiple such versions for editing different aspects or attributes of the component.

[0114] It will be understood that a component may provide a set of customization properties and associated information (known as a customization record). Next, the WBS editor 230 may create a customization dialog by collecting these customization records, integrating records obtained from multiple components as needed, and generating a customization UI. Such functionality is incorporated herein by reference and is described in further detail in Patent Document 5, the specification of a U.S. patent entitled "SYSTEM AND METHOD FOR DIALOG CUSTOMIZATION," issued on September 5, 2017, and assigned to a common assignee of the present invention. It will be understood that an overridden parameterized behavior element may override these customization records to provide an alternative customization interface.

[0115] It will also be understood that a component may include additional non-configuration information that may be useful to the WBS editor 230. Such information may be internal to the component, may affect the content of the component, or may affect components disposed within the component that are affected (e.g., as will be described in more detail below in connection with smart containers herein). Additionally, this information may be external to the component and may affect the manner in which the WBS editor 230 and the containing component interact with a given component (e.g., specific guidelines on how a component can be dragged or resized).

[0116] As another example, the component may provide alternative component versions or configurations. One example is to provide a simplified or lightweight version of the component, in which case the system 200 may display the component (partially) “live” while dragging or zooming the component (as opposed to the component display when the component is static). For example, a video player component may provide an alternative lightweight version to be used while dragging and resizing the component. In such a version, a lower resolution, a lower frame rate, or repeated display of a small video section may be used (for example) to make the display during dragging and resizing easier.

[0117] The component may also provide information related to the layout and composition of the component. Such information may include (for example) minimum or maximum component sizes, a whitelist of allowable layout-by-parameterized behavior elements, and the like.

[0118] Component definitions may also include specific hints that direct the dynamic layout process in which this component is involved (as described in Patent Document 6 entitled "WEB SITE DESIGN SYSTEM INTEGRATING DYNAMIC LAYOUT AND DYNAMIC CONTENT", which is incorporated herein by reference, assigned to the common assignee of the present invention, and published on August 22, 2013), or specific guidelines used to create special editing handles for certain components that affect the behavior of any dynamic layout and the operation of dynamic layout rules when the component is edited (as described in Patent Document 7 entitled "METHOD AND SYSTEM FOR THE USE OF ADJUSTMENT HANDLES TO FACILITATE DYNAMIC LAYOUT EDITING", which is incorporated herein by reference, assigned to the common assignee of the present invention, and published on September 5, 2013).

[0119] As described above herein, the process of system 200 has different stages. In the component definition stage, the WBS vendor staff 261 (and, often, the designer 262) may define and create some standard parameterized behavior elements, including specifying which parameterized behavior element types may be overridden and under what conditions, using the component / container editor 233. It will be understood that the person defining the component (vendor 261 / designer 262) may define, under relevant conditions, a container component (including the parameterized behavior elements to be overridden within the containing component), and in some cases, specific parameter values.

[0120] The site designer 262 may design his or her website at the page definition stage using these components and containers. The site designer may also modify any pre-defined overrides, or, in some cases, define his or her own parameters using the editing behavior applicator 232. The system 200 may additionally enable the site designer to define his or her own override requirements for components within a container, or may enable complete editing of all parts of the components and containers, as will be understood.

[0121] It will be understood that the editing behavior applicator 232 may typically apply various object editing operations that are affected using a mouse, keyboard, or both (and any other user interface input means). These may include, as described in Patent Document 2, selection, drag, drop, sizing, copy, paste, etc.

[0122] It will be understood that the site designer 262 may work using WYSIWYG (what you see is what you get). Thus, the page may be interactively resolved and displayed during editing. However, the associated web site pages may also be modified at runtime by changes to the database (underlying database) within the CMS 250, or by changes to databases within external sources that are displayed via repeater containers (indicating, for example, added or deleted records that reflect these database changes).

[0123] As described above in this specification, a component may accept parameters that can define, add, or modify any of the SBL elements, such as any of the parameterized behavior elements described above. Further, a parameterized behavior element may accept its own parameters, such as, for example, "Modify all the contained components with a color modifier that weakens the color by X%".

[0124] The extended element handler 210 may handle all functions related to the parameterized behavior element. For example, the site designer 262 may select a component (also known as the user-selected component) using the component selector 231 at runtime and apply the necessary behavior using the edit behavior applicator 232. It will be understood that the application by this edit behavior applicator 232 may change one or more parameters of the parameterized behavior element of the selected component.

[0125] It will be understood that the element handler 210 may be triggered by the WBS runtime server 220 (before the page can be loaded or refreshed), or by the WBS editor 230 when an edit change is made to the current component during an editing session (thereby causing a full or partial refresh, or directly causing an override request).

[0126] The request receiver 211 may receive override requests (from user edit requests or from automatic system requests as a result of changes from an external source 270 / CMS 250 during page load / refresh / rendering). The resolver 212 may identify which components are affected within the relevant accommodation level based on the conditions and selection rules defined by the request component, together with the results of the page analyzer 260, and may receive from the data handler 16 which parameterized behavior elements from each component are overrideable. As described above herein, the page analyzer 260 may identify the complete component hierarchy. This may include the detection of semantic composites (described above herein) that have elements subject to override and that can be part of the hierarchy. Thus, the complete hierarchy may be based on predefined containers, repeater containers (defined based on data sources), and semantic composites (defined based on page analysis).

[0127] For each of the components identified based on the output of the resolver 212, the negotiator 213 may communicate with the relevant parameterized behavior elements of the selected components to identify overrides of the contained components, in accordance with a negotiation protocol to satisfy communication requests (including procedural negotiation such as using variables and decision logic). This protocol may be regarded as a form of communication between two components A and B1, for example, to determine whether a parameter X obtained from component A can be applied to component B1.

[0128] The resolver 212 may also handle conflict resolution. For example, a contained component that processes a format may override elements of its container based on the data presented to itself. On the other hand, the container may attempt to override elements of the contained component. Thus, loops or conflicts may occur, which can be resolved by the resolver 212 (by determining which override requests to ignore and thereby breaking the loop).

[0129] As described above herein, some parameterized behavior elements may be pre - defined as overridable, while others may not be so pre - defined. If overriding is permitted according to the protocol, the resolver 212 may perform the override.

[0130] Thus, although changes to components may potentially cross hierarchical boundaries, the resolver 212 may apply component changes based generally on rules flowing along the container hierarchy. The resolver 212 is typically part of a full run that occurs while converting the database structure of a website building system to HTML (or otherwise preparing it for display), but it will be understood that it may be re - run by a trigger. This may be in a stand - alone stage or integrated into the full conversion stage.

[0131] Based on this analysis and the identified component hierarchy, the resolver 212 may identify all override requests made by various override components across the page hierarchy. Override requests may include the application of parameterized behavior elements, or may be simple attribute overrides (such as "set color to green") that do not include parameterized behavior elements.

[0132] It will be understood that the resolver 212 may identify a list of all override requests and any corresponding components, i.e., the components to which those override requests are to be applied. Further, the resolver 212 may receive, for each corresponding component, a response to each override request applicable to that corresponding component, as specified by the corresponding component's own whitelist / blacklist or by other corresponding component-specific rules that define the override requests. Next, referring to FIG. 9, this illustrates an example of the override flow that can occur within the component hierarchy. For example, component (comp1) may override the relevant parameterized behavior elements of a series of components (such as components 2 and 3 and semantic composite 1, excluding repeater 1) that are within or contained within the same container as comp1. Further, component (comp1) may override comp4, which is at a different containment level (i.e., within comp3).

[0133] Also, the resolver 212 may determine the order in which override requests are to be applied. This can be based on a user-specified order (e.g., an override component that provides a plurality of override requests and defines their order or priority), or on system rules (similar to the specificity rules that define the order in which CSS rules are applied).

[0134] Next, resolver 212 may apply the override requests to all corresponding components in the determined order. Applying an override request to a particular corresponding component may affect the way the affected components interact with other components (since the condition evaluation yields different results). For example, if component A affects component B, changes to component B may cause situations where component B affects component C or is affected by component D to be resolved in different ways. This may be due to special rules for component B (as part of override data handler 16), where some or all changes to component B may cause further overrides of other components by component B to be initiated. Such override rules may cause a "chain reaction" phenomenon among components and may also cause an "overriding circle", which can be detected and resolved by resolver 212.

[0135] In an extended embodiment, both the override component and the corresponding component may provide code snippets that can interact and negotiate with each other to determine whether an override should occur. These snippets can be created using a normal programming language (e.g., JavaScript) or a restricted scripting language adapted for such negotiation. In either case, negotiator 213 may execute such code snippets in a sandbox or other closed execution environment.

[0136] Generally, it will be understood that overriding of parameterized behavior elements (including resolution and negotiation) typically occurs during the rendering stage of a page, i.e., when the page is edited or refreshed (both during editing and at runtime). It will be understood that the extended element handler 210 may be integrated as part of a system 200 that processes the definitions of a website construction system CMS250 to generate output to the user. This may be a physical rendering to a screen (e.g., using a dedicated client application), or alternatively, the creation of an HTML version of the site. It will be understood that the final resolution and rendering may be performed by the WBS editor 230 (for editing purposes) and the runtime server 220, or by the user's browser, or by a combination thereof.

[0137] In another embodiment, the browser may reactivate the process from the website construction system to HTML by the occurrence of a trigger (optionally including user interaction), and recreate part or all of the page to be rendered. This may also be performed based on operation code (JS) within the page that operates based on various triggers.

[0138] Triggers can include various events as described as dynamic layout triggers (data changes, site editing from another user, server notifications) and page operation triggers (user interaction, JS operations).

[0139] It will be understood that the negotiation protocol via the negotiator 213 may be performed across rendering boundaries (such as different iFrames, different browser windows, different machines for server-rendered third-party applications).

[0140] Also, since updates to components are part of dynamic page resolution, i.e., they are performed during the preview stage (while editing) or at runtime, it will be understood that they are not saved within CMS250. Further, it will be understood that the resolution needs to be performed at runtime / during preview because the component itself can further change during runtime (e.g.,) due to dynamic layout triggers and component logic. Further, it will be understood that such changes can further affect the override process, such as changing the results of geometry / content analysis. For example, if Component A changes the attribute X of Component B (via a parameterized behavior element) (thereby updating the value of attribute X and creating version 2 of Component B), Component B is not saved in CMS250 with the new value of attribute X because this change can affect Component B during its next use. For example, when Component B is used next time, Component A may not override Component B and the original value of attribute X is lost. One exception may be the saving of a cached version of the page with Component B having the new value of attribute X for fast rendering.

[0141] As described above in this specification, the parent component or page may set (or define) the properties of the pre-defined components contained within the parent component by call line parameters or by a related style sheet containing rules for setting specific properties. Such definitions may also include some overrides. For example, a component may have a pre-defined default color and this definition may override the default color. This may also apply to system-specific attributes. For example, a component may have parameterized behavior elements for a default or built-in layout and the calling component may define parameterized behavior elements for an alternative layout.

[0142] Also, a component may explicitly override the attributes of the managed component provided to itself by its parent, for example, as follows.

[0143]

Number

[0144] In the above example, the gallery component (gallery1) is a container component and receives three children (grid1, image1, image2) as managed components. Inside div2, the gallery component overrides the CSS 'color' attribute for the received child components and sets it to green. This will be relevant for the children of grid1 (which probably has a background color), but not for the children of image (i.e., image1, image2, which probably have no definition of background color). It will be understood that such an override does not apply to the pre - defined button components nav1 and nav2.

[0145] As described above in this specification, the element handler 210 may apply a parameterized behavior element type (e.g., layout, etc.) to a managed element (the contained component). This may be implemented, for example, by making a call such as "child.toVdom({--display: Carousel})" during the definition of the component. In the above example, it will be understood that such an override will be relevant for the grid component managed element (grid1), but not for the image component managed element.

[0146] In another example, the parameterized behavior element parameters of a specific layout (i.e., the image display method), such as in the format of "child.toVdom({display: 'block'}), may be overridden if this is relevant.

[0147] In a system based on the E-HTML / CSS page specification, such an override may also be realized through specific styles that can be referenced, for example, as follows, through an inline class reference or a class addition function.

[0148]

Number

[0149] As described above in this specification, the WBS vendor 261 / website designer 262 may set limitations on the functions of components that set or override specific attributes of elements (i.e., sub-components) predefined by itself, elements (i.e., containers) managed by itself, or both. A typical embodiment thereof may limit the setting or override of properties to the properties of the outer layout and style, and may not permit the setting, override, or modification of the properties of other elements (especially including the content of the element).

[0150] As described above in this specification, the functions of the system 200 may include special processing of the elements to be managed (i.e., components within the container).

[0151] For example, when a list (A1..An) of managed elements for inclusion / display is passed to container component X, container component X may transform those managed elements in several ways before displaying them, based on, for example, the type of X, the parameters of a particular instance of X, or the parameters and attributes of those managed elements. Such transformations may include changing the order of display and setting a particular location or position, for example, arranging the elements vertically and aligning every odd-numbered item to the right and every even-numbered item to the left (which is also known as a zigzag display). This may be based on the attributes, content, or structure of the managed elements, for example, aligning the managed elements to the right or left from the top based on whether their brightness is higher or lower than a predetermined value.

[0152] Other transformations may include changing (overriding) the attributes of the managed elements, for example, overriding their color and border settings, omitting elements, for example, displaying only a subset of the provided managed elements or showing only a particular 10-element "window" of a complete and much larger list, expanding elements, for example, providing managed elements that are themselves containers with specific or additional managed elements, and duplicating or repeating elements, for example, displaying a managed element twice and, in some cases, overriding some of the attributes within the displayed managed elements to distinguish different duplicates of a particular managed element. This can be used, for example, to display multiple variants for selection.

[0153] The E-HTML / CSS-based embodiment of the system 200 enables the definition of extensible style sheets, whereby a path or API may be provided that allows the elements of a component to be modified from outside the component. It will be understood that this can be used, for example, for parameterized behavior elements or overriding normal attributes and can also be extended to CSS (by adding parameterized behavior elements on top of the component).

[0154] A representative definition has the following form (used, for example, within the definition of a gallery component).

[0155]

Number

[0156] By the E-CSS definition and use of the above-mentioned parameterized behavior element types of the layout, a set of extensible and overrideable layout properties that can be applied to an instance of this component (i.e., grid1 within the gallery definition) can be defined, and furthermore, it will be understood that this includes setting the properties of the gutter, columns, and colors of grid1.

[0157] Also, this may define the above-mentioned "parameterized behavior element type of the layout" as a custom pseudo-element that can be customized or overridden from an external component using this gallery component.

[0158] The above “@extend” statement notifies the system 200 that this style sheet may be extended or overridden by a parent component. The list of properties defined within the style sheet that houses this “@extend” functions as a whitelist of properties that may be overridden. Further, this style sheet itself may be extended by adding other properties. It will be understood that values defined for different attributes within the style sheet (e.g., the above gutter = 3) function as default values in the event that the parent component does not specify a value for a particular attribute.

[0159] In an alternative embodiment, the system 200 may use a directive format similar to other system-specific CSS attributes (e.g., “-public: true”) instead of the “@extend” directive.

[0160] In this scenario, other properties of grid1 or properties of grid2 are not “open” nor are they part of the public interface of the gallery component. As described above herein, other properties of the gallery component, except for potential explicit overrides of properties through the @extend-based API, whether custom or pre-defined, are not inherited from the containing component in order to maintain component integrity.

[0161] The use of the above wildcard property specification represents all properties starting with the prefix “prop-gallery-*”. The system 200 may also support other wildcard specifications (including specifications of CSS properties following property groups such as color-related, background-related, etc.). It will be understood that the specification may also represent normal CSS properties (non-extended properties) such as the reference to ‘color’ above.

[0162] As described above in this specification, the resolver 212 may further perform white / blacklisting according to "who can override" (i.e., which "parent" component may override the public property), rather than "what can be overridden". As described above in this specification, this information may be provided by the data handler 16 and may also be based on various parameters and properties of the parent component, such as the type, name, screen area, or other attributes of the component (e.g., which parameterized layout behavior elements types to use). The syntax for such a specification may be, for example, as follows.

[0163]

Number

[0164] Regarding the call, a component or page that includes the above-described gallery component (as the "owner") may use, for example, the following public properties as parameters.

[0165]

Number

[0166] This can be implemented using any of the above-described methods. The number of columns (4) specified in the call parameters overrides the default value of 5. Such an override or specification can only be applied to the directly owned component (e.g., the gallery in the above example). The override may be applied to the indirectly owned component if the shared root component is involved.

[0167] As described above in this specification, the system 200 may support smart containers, i.e., the container definition may include editor interaction, special handles, and editing and runtime behavior.

[0168] Also, the component / container editor 233 may enable the creation of smart containers and may further interface with a specific editing driver 15A that can be associated with the smart container type.

[0169] It will be understood that a smart container may manage the components it contains and interact with them via the resolver 212 to provide a set of behaviors not seen in normal containers.

[0170] In particular, this container may define specific restrictions or rules regarding component types or other parameters. For example, an album container may contain only image components, or only image and video components, or only images smaller than a predetermined size. Also, a specialized container may transform the various components it contains. For example, it may transform all contained galleries into slider - type galleries.

[0171] This container may define the style of the components it contains. This may be implemented, for example, via a set of settings and attributes applicable to those components. These may include presentation elements (e.g., color, bevel, etc.) and functional elements that operate the WBS editor 230 (e.g., additional handles that enable specific operations, etc.).

[0172] Furthermore, it will be understood that this container may define different settings for each type of contained component (e.g., all contained galleries may be made yellow, all contained text boxes may be made wide and green, etc.).

[0173] This container may determine the manner in which the contained components are arranged therein (e.g., gallery, accordion, book format, etc.), and may also impose specific behavior on the sub-component layout therein, for example, it may affect dragging and resizing therein (e.g., it may require snapping to a grid or a specific layout). This container may also determine the processing of dynamic layout therein, which may be different from the default dynamic layout processing method used for normal containers. It will be understood that the dynamic layout processing may be based on the hints of dynamic layout as described above in this specification. It will be understood that the functions as described above in this specification may be defined through the editor behavior driver 15A and the runtime behavior driver 15B.

[0174] It will also be understood that the above functions may depend on the type of contained components, component content, component age, component edit history, component inheritance history, component size, component shape, component z-order, component usage within the application, component format information, native reading order of the components, association of components between pages, user-defined hints, and any combination thereof. Some of these component attributes are incorporated herein by reference and assigned to the common assignee of the present invention and are described in more detail in Patent Document 8 entitled "Adaptive User Interface Creation in Multimedia Creative Design System" published on April 4, 2013.

[0175] The smart container may also interact with the WBS editor 230 to provide container-specific drivers and logic to the WBS editor 230 (via the editor behavior driver 15A). Such drivers may control aspects of the editing behavior. Such aspects are separate from any container runtime behavior, but may affect the final presentation of the containers and components.

[0176] One such aspect is the drag behavior of components within the editor during editing. The executable behavior may include VBox (vertical box) behavior, where all drags snap to a vertical line. Components may be automatically aligned on this line, for example, centered or left-aligned. Another such aspect is the slider behavior when the drag becomes discontinuous and moves between discrete slider positions, where the slider may slide / scroll the content so that components dragged to "invisible" positions can be properly positioned.

[0177] Yet another such aspect is the drag-and-drop behavior. For example, a text editing box may be implemented as a smart container that places these dropped components in appropriate positions such that the dropped components are integrated into the flow of the text already typed within this text editing box, instead of using an exact drop position.

[0178] As yet another example, a 3D container type may add 3D manipulation handles and 3D behavior to the contained components. This container may provide the relevant logic and UI elements to the WBS editor 230 to support such 3D behavior. The WBS editor 230 may add new handle types and new handles, control the resizing and movement of the contained components, and control the order in which various edit actions are performed.

[0179] This container may allow designer 262 to define some parameters that control the editing and runtime behavior of this container, and in some cases, may also allow overriding some existing component attributes. For example, as illustrated in FIG. 10 referred to below, the Vbox container A may define a default behavior where the (vertical) line L along which the contained components C1 - C4 are aligned is at the center of the container. This container may allow the user to override this parameter and define a different position for the vertical line L by specifying an absolute or percentage - based position R for the line L.

[0180] As another example distinct from the above example, a runtime - modifiable smart container may allow the components within it to be moved or resized during runtime (as defined by the runtime behavior driver 15B). The Vbox version of such a smart container may enforce aligning the moved contained components to the vertical line within the container as described above.

[0181] In yet another example, when the Vbox container arranges the components it contains along a vertical line, it places a control that invokes the "add component in place" function of the visual editor among these child components.

[0182] In yet another example (as shown in FIG. 11 referred to below), the smart container component A may have a function to define an internal layout (for example, by dividing this special container into X×Y equal rectangles). In this particular example, A is divided into 4×5 rectangles.

[0183] The components (e.g., the exemplary image component B) disposed within this smart container A "grow" a plurality of resizing handles at each edge, such as handles c and d at the upper edge (similar handle pairs are at each of the four edges of component B).

[0184] The smart container A may further implement additional code that snaps resizing via handle c to the internal grid of A and causes resizing via handle d not to snap to the internal grid of A (functioning with the visual staging area E of the website construction system). Such various behaviors and additional examples of handle types are described in detail in Patent Document 7, including behaviors that affect the parameters and rules of the dynamic layout.

[0185] The WBS editor 230 may implement "invisible" handle regions instead of actual visual handles, and it will be understood that these provide specific functions when the mouse interacts with them. The WBS editor 230 may notify the user when the user is using such invisible handles, for example, by changing the shape of the mouse pointer.

[0186] The system 200 may support containers that place elements internally according to the visual optimization of the element placement (e.g., using component placement rules) rather than based on pre - defined positions.

[0187] The implementation of the drag may be based on, for example, an editor behavior driver 15A that interfaces with the WBS editor 230 and a smart container driver provided by the container Y. For example: The WBS editor 230 acquires the mouse movement for component X.

[0188] The WBS editor 230 may send an event description (mouse movement) to the editor behavior driver 15A of the container Y that houses component X.

[0189] The editor behavior driver 15A may process the mouse movement information and the existing layout information object of X to generate a modified layout information object.

[0190] The editor behavior driver 15A updates the WBS editor 230 and the container Y with this new information.

[0191] Accordingly, the editor behavior driver 15A may operate within the WBS editor 230 to convert user interactions into property updates. These interactions may include drags, clicks, etc. These may be higher-level actions (such as "dropping a component") or lower-level actions (tracking each mouse position update). This driver may be monolithic or may be composed of a general-purpose driver with component-specific drivers incorporated into the general-purpose part. In some embodiments, it will be understood that some of the interactions between the editor behavior driver 15A and the WBS editor 230 may be implemented via the resolver 212. For example, a new component may be added to the container, and that new component may send parameters of its own parameterized behavior elements.

[0192] It will be understood that other (non-container) components may also include the editor behavior driver 15A. For example, a label component may include the editor behavior driver 15A that supports a particular variant of in-place editing.

[0193] As another example, the image display component may provide region-of-interest based processing during the editing of the display image. Under such a scheme, the system 200 may define a region of interest within the display image (e.g., a predetermined object within the image, etc.). Such a definition may be based on user input, image content analysis of other factors. Once the region of interest is defined, the system 200 may modify the positioning and cropping of the image during image resizing (during editing) to focus on the visible area of the region of interest of the image. Thus, with a new combination of positioning and cropping, an optimal focus may be achieved for the region of interest for the new zoom factor.

[0194] It will also be understood that the system 200 may perform either recommending modifications to containers that provide AI / machine learning based modifications through the AI / machine learning unit 214, or layout recommendations for components contained therein. The functions of the AI / machine learning unit 214 may be similar to those described in Patent Document 9, which describes recommendations for design options and applies the same principles to AI-based recommendations that recommend overrides and parameters in addition to the complete layout.

[0195] Such recommended modifications may include only layout (e.g., selection of position and size, etc.), a restricted set of attributes (e.g., a container that provides a specific background image / video to an internal sub-container, or a container that affects simply color selection, etc.), behavior, or sub-elements of any specific contained component.

[0196] This may be implemented for the contained components within a single container (where the page section, page, and page set are at a "higher container level"), or for a set of containers (e.g., a certain number of separate page sections that are processed together to provide color matching between each other).

[0197] As described above herein, the WBS vendor 261 and the designer 262 may define components according to instructions regarding how the attributes may be modified using the component / container editor 233.

[0198] The AI / machine learning device 214 may use this information collected about the WBS vendor 261 / designer 262 and other users (including the editing history stored in the CMS 250, BI, other websites, etc.) regarding what constitutes a good design, color matching, etc. The AI / machine learning device 214 may classify related users and sites according to their attributes (business type, subtype, geographical location, user experience, system functions used, etc.).

[0199] The AI / machine learning device 214 may analyze input materials that may include a large number of editing changes (obtained from the editing history) and the application of parameterized behavior elements, and information regarding the popularity and ranking of analyzed sites, pages, and components. This input material may be used for the training of a machine learning engine (e.g., a neural network-based engine, etc.), and this machine learning engine may then provide recommendations for modifications. The current state of this machine learning engine may be stored in the ML / AI repository 2510.

[0200] Such recommended containers may be intermixed with other (ordinary) containers that are subject to the regulations of relevant privacy and intellectual property laws (such as copyright law and trademark law), that is, laws that regulate the use of such information and ensure that the privacy of data belonging to other users is not compromised.

[0201] As described in Patent Document 2, changes to the structure of the components of a website may affect the indexing of the website by a search engine spider, and thus may affect the optimization of the search engine. It will be understood that the system 200 may also include a search engine-friendly renderer that, as described in Patent Document 10, which is incorporated herein by reference and is the specification of a U.S. patent entitled "SYSTEM FOR DEEP LINKING AND SEARCH ENGINE SUPPORT FOR WEB SITES INTEGRATING THIRD PARTY APPLICATION AND COMPONENTS" issued on September 6, 2016 and assigned to the common assignee of the present invention, transmits information about updated containers and components to be indexed to a search engine spider.

[0202] Accordingly, the parameterized behavior elements may be used to automatically convert the visual and operational parameters of components and containers within all accommodation levels based on an override protocol.

[0203] Unless otherwise specified, as is apparent from the above description, throughout this specification, descriptions using terms such as "processing," "calculating," "computing," "determining," etc. refer to actions and / or processes of any type of general-purpose computer, such as a server, client, mobile computing device, smart appliance, or similar electronic computing device (i.e., a general-purpose computer that manipulates data represented as a physical quantity, such as an electronic quantity, in the registers and / or memory of a computing system and / or converts this data into other data similarly represented as a physical quantity in the memory, registers, or other such information storage, transmission, or display devices of the computing system).

[0204] Embodiments of the present invention may include an apparatus for performing the operations described herein. This apparatus may be specially constructed for the desired purpose or may comprise a general-purpose computer or a client / server configuration selectively activated or reconfigured by a computer program stored therein. As a result, the resulting apparatus may, when instructed by software, transform the general-purpose computer into an element of the invention described herein. These instructions may, if necessary, define a device of the present invention operating with a computer platform. Such a computer program may be stored on a computer-readable storage medium, such as, but not limited to, any type of disk, including optical and magneto-optical disks, read-only memory (ROM), volatile and non-volatile memories, random access memory (RAM), electrically programmable read-only memory (EPROM), electrically erasable and programmable read-only memory (EEPROM), magnetic or optical cards, flash memory, disk-on-key, or any other type of medium suitable for storing electronic instructions and connectable to a computer system bus.

[0205] The processes and displays presented in this specification are not inherently related to any particular computer or other device. Various general-purpose systems may be used with programs that comply with the teachings of this specification, or it may be convenient to construct more specialized devices to implement the desired method. The desired structures for these various systems will become apparent from the above description. Furthermore, embodiments of the present invention have not been described with respect to any particular programming language. It will be understood that the teachings of the present invention described herein may be implemented using various programming languages.

[0206] Although particular features of the invention have been illustrated and described herein, many modifications, substitutions, changes, and equivalents will occur to those skilled in the art. Accordingly, it is to be understood that the appended claims are intended to cover all such modifications and changes that fall within the true spirit of the invention.

Claims

1. A website construction system (WBS), a processor, at least one database for storing website components, a smart container component stored in the at least one database, and having, the smart container component includes an editor behavior driver that provides container-specific editing logic to a WBS editor, an override data handler that processes override requests between the smart container component and at least one contained component to achieve style, behavior, and operation changes, A website construction system.

2. The smart container component further includes an internal layout definition that defines the spatial arrangement of the contained components, and the container-specific editing logic changes standard editing operations on the contained components based on the internal layout definition. The WBS according to claim 1.

3. The editor behavior driver changes the standard editing operations of the WBS editor by providing special editing handles for the at least one contained component, and different special editing handles on the same edge achieve different size change behaviors. The WBS according to claim 1.

4. The smart container component further includes a runtime behavior driver that affects the handling of the at least one contained component at runtime. The runtime behavior driver enables the movement and size change of the contained components at runtime according to predefined constraints. The WBS according to claim 1.

5. The editor behavior driver receives user events from the WBS editor, converts the user events into layout changes based on container-specific rules, and sends the updated layout information to the WBS editor. The WBS according to claim 1.

6. The smart container component includes at least one of the following: a position for alignment constraints for a site designer, constraints regarding the types of components that can be included within the smart container component, and style parameters automatically applied to at least one contained component. The WBS according to claim 1.

7. The WBS according to claim 1, wherein the smart container component is included to incorporate an artificial intelligence / machine learning device to receive a recommended layout for the at least one component to be contained.

8. A method for a website building system (WBS), comprising: a processor storing a smart container component in at least one database; providing container-specific editing logic from the smart container component to a WBS editor via an editor behavior driver; processing an override request between the smart container component and at least one component to be contained using an override data handler to implement style, behavior, and operation changes; and executing.

9. The method according to claim 8, further comprising defining an internal layout definition within the smart container component that defines a spatial arrangement of the component to be contained, and the container-specific editing logic changing standard editing operations of the component to be contained based on the internal layout definition.

10. The method according to claim 8, wherein providing the container-specific editing logic includes changing standard editing operations of the WBS editor by providing a special editing handle for the at least one component to be contained, and different special editing handles on the same edge implement different sizing behaviors.

11. The method according to claim 8, further comprising using a runtime behavior driver to affect the handling of the at least one component to be contained at runtime, and the runtime behavior driver enabling movement and resizing of the component to be contained at runtime according to predefined constraints.

12. receiving a user event from the WBS editor; converting the user event into a layout change based on container-specific rules; and sending updated layout information to the WBS editor. The method according to claim 8, further comprising.

13. The method according to claim 8, further comprising being able to define at least one of a position for alignment constraints by a site designer, constraints on types of components that can be included within the smart container component, and style parameters automatically applied to the at least one contained component.

14. The method according to claim 8, further comprising incorporating an artificial intelligence / machine learning device to receive a recommended layout for the at least one contained component.

Images