SYSTEM AND METHOD FOR SMART INTERACTION BETWEEN WEBSITE COMPONENTS - Patent application

Abstract

To improve website building experience by a system which handles website components having parameterized-behavior elements within themselves, which may define operational and / or visual behavior of a component.SOLUTION: A website building system (WBS) includes: at least one database storing extended website components comprising parameterized-behavior elements; and an extended data handler which calls an override request between a first extended website component and a second extended website component using the parameterized-behavior elements. The override request implements style, behavior and operational changes.SELECTED DRAWING: None

Description

[Technical field]

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

[0002] (CROSS REFERENCE TO RELATED APPLICATIONS) This application claims priority to and the benefit of U.S. Provisional Patent Application No. 62 / 516,682, filed June 8, 2017, and U.S. Provisional Patent Application No. 62 / 665,629, filed May 2, 2018, which are incorporated herein by reference.

[0003] Web site building systems have become very popular, allowing novice web site builders to create web sites that look and function like professionally created sites. Many of these systems offer both novice and experienced users ways to build a web site from scratch.

[0004] A website typically consists of a visually designed application that is made up of multiple pages. These pages are displayed individually and may contain components. The website building system may support a hierarchical organization of components using atomic components (text, image, shape, video, etc.) and various types of container components that contain other components (e.g., normal container, single page container, multi-page container, gallery container, etc.). Sub-pages contained within the container components are called mini-pages and may each contain multiple components. Some container components may display only one mini-page at a time, while others may display multiple mini-pages simultaneously. Referring now to FIG. 1, a general representation of a website building system 1 is shown that is made up of a website 2 having a web page 3 that may be composed of a component 4 that is composed of an atomic component 5 and a container component 6. The container components 6 may further be composed of various single page containers 7 and multi-page containers 8 that further contain mini-pages 9. Other component types may include a semantic composite 11 , a data / text repeater 12 and an image repeater 13 .

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

[0006] Components can be contentless or they can have internal content. An example of the first category is a star component, which has no internal content (although it has color, size, position, and a few other parameters). An example of the second category is a text paragraph component, whose internal content includes the inner text, as well as font, formatting, and layout information. Of course, this content can vary from one instance of the text paragraph component to another. Components that have content are often called fields (e.g., "text fields").

[0007] Existing web pages are typically composed of a combination of declarative HTML code, which provides the content and formatting, Cascading Style Sheets (CSS), which provide additional styling, and procedural JavaScript (JS), which provides the procedural infrastructure for the page.

[0008] The content of a web page may reside in a single file or a combination of files (e.g., HTML, CSS, and JS files). A typical setup is a main HTML file that includes additional HTML, CSS, and JS files, where some of those included files are common to multiple pages (e.g., a common set of styles or JS libraries are used in multiple pages).

[0009] Such included files may come from multiple sources: some files may be created by a single web page author, while others may be created from various predefined HTML, CSS or JS libraries or plugin modules created by multiple authors.

[0010] The pages of a website may be statically defined, i.e., files of their final form 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 may be created using a system (e.g., web page editing or generation software) that creates (static) web pages based on user definitions.

[0011] Website pages may also be dynamically generated, i.e. dynamically (or semi-dynamically) constructed, when requested by a user. Such dynamic generation may be performed via a complete page generation, where the whole page is created from predefined sub-elements, where how these elements should be combined is defined separately. Existing page templates can be used, where some placeholders are filled with data obtained from other sources.

[0012] An online website building system may be used to create and implement such dynamic pages. A page definition may be created by a designer using the website building system, where the designer creates the page definition using various provided elements (e.g., components, containers, third party applications, and page segments) that are assembled through the page creation environment.

[0013] A website building system typically stores page definitions in a repository. These page definitions are read by the website building system during runtime and transformed into web page information that is transmitted to the site viewer. These are then rendered for the current view and components are instantiated.

[0014] A website building system may include client-side components, such as, for example, JS application segments that are embedded in generated pages and run on client-side or server-side code contained within the application.

[0015] The process of converting the website building system's internal representation of the page definition into HTML / CSS / JS code (executable by a browser) may be split in several ways between the website building system's components running on the server and the client. In one embodiment, the entire conversion work is performed on the website building system server, which provides a complete executable page to the viewer's client machine. By "executable" we mean a page that can be directly processed and rendered by a browser client.

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

[0017] In yet another embodiment, the conversion work is divided between the server and the client, each of which performs a portion of the conversion.

[0018] Such client-side applications may also play further roles such as handling image galleries to allow client-side manipulation (moving / sorting images, etc.) (using the server, e.g. simply interfacing to an 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 U.S. Patent Application Publication No. 2013 / 0133999, entitled "DEVICE, SYSTEM, AND METHOD OF WEBSITE BUILDING BY UTILIZING DATA LISTS," published September 18, 2014, and assigned to the common assignee of the present invention, which is incorporated herein by reference).

[0021] Such third-party applications and list applications may be purchased (or otherwise obtained) through some delivery mechanism, such as being pre-included in the website building system's design environment, from an application store (either built into the website building system or external thereto), or directly from a third-party application vendor.

[0022] A website building system is typically provided by a website building system vendor. The website building system is used by users (also called designers) who design websites, and those websites are then used by users-of-users (also called end-users).

[0023] Third party applications may be hosted on the website building system vendor's own servers, on the third party application vendor's servers, or on a 4th party server infrastructure.

[0024] Existing systems typically allow editing to be performed at the component level, including the container level, and thus typically provide operations such as adding components (e.g., by selecting a component from a menu of available component types and using drag and drop), removing components, moving and resizing components, changing the content of a component, changing the attributes of a component (e.g., through floating or fixed attribute panels that are applicable to the component being edited), placing a component within a container, or removing a component from within a container.

[0025] Existing systems may also allow components to be grouped (e.g., by using multiple selection of components in conjunction with group / ungroup operations). The system may then allow operations such as moving, resizing, or changing attributes (e.g., color) to be performed on all components in the group.

[0026] US Patent Application Publication No. 2013 / 0133639, entitled “SYSTEM AND METHOD FOR IMPLEMENTING CONTAINERS WHICH EXTRACT AND APPLY SEMANTIC PAGE KNOWLEDGE”, published Feb. 1, 2018, and assigned to the common assignee of the present invention, which is incorporated herein by reference, describes how a container may be composed of a set of components that may form a semantic composite (e.g., semantic composite 11 in FIG. 1) as a result of an analysis of the components of a web page known as smart boxes. A smart box may provide a UI or interface that allows certain changes to be applied to multiple contained smart boxes (possibly at multiple containment levels). US Patent Application Publication No. 2013 / 0133639 describes strict semantic composite matching (applying changes only to types that fit the smart box) and soft matching (simply applying changes if applicable to a particular smart box). These changes may include style changes, adding / removing components, layout changes, decorative element changes, etc. US Patent Application Publication No. 2013 / 0133639 also describes special editing behaviors that adapt a set of components with specific functionality 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] US Patent Application Publication No. 2014 / 0282218 [Patent Document 2] US Patent Application Publication No. 2018 / 0032626 [Patent Document 3] US Patent Application Publication No. 2017 / 0046317 [Patent Document 4] U.S. Pat. No. 9,747,258 [Patent Document 5] U.S. Pat. No. 9,753,911 [Patent Document 6] US Patent Application Publication No. 2013 / 0219263 [Patent Document 7] US Patent Application Publication No. 2013 / 0232403 [Patent Document 8] US Patent Application Publication No. 2013 / 0086496 [Patent Document 9] US Patent Application Publication No. 2015 / 0310124 [Patent Document 10] U.S. Pat. No. 9,436,765 Summary of the Invention [Means for solving the problem]

[0028] According to a preferred embodiment of the present invention, there is provided a website building system comprising: at least one database storing website components and their associated component hierarchies, each component including overridable and non-overridable parameterized behavior elements and data handlers, the data handlers handling an override protocol for the components; and an element handler for reviewing all components to be rendered for a current view and for a current component, and for processing a request for communication between the current component and at least one other component in the component hierarchy to satisfy an override request from the at least one other component, and updating the current component according to the data handlers of the current component only if the override request concerns an overridable parameterized behavior element of the current component.

[0029] Additionally, in accordance with a preferred embodiment of the present invention, the system further comprises a runtime server that invokes an element handler for the current component for the current view.

[0030] Furthermore, in accordance with a preferred embodiment of the present invention, the system further comprises a WBS (Web Site Building System) editor having parameterized behavior element information that allows a user to select components and apply editing changes to the selected components.

[0031] Furthermore, in accordance with a preferred embodiment of the present invention, the current component is at least one of a predefined component, a repeater component, and a semantic composite.

[0032] Furthermore, in accordance with a preferred embodiment of the present invention, the system further comprises a page analyzer that identifies a component hierarchy for a current component and determines whether the current component is a semantic composite.

[0033] Further, in accordance with a preferred embodiment of the present invention, the element handler comprises: a request receiver for receiving 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 for receiving from the data handler of the current component which parameterized behavior elements of the current component are overridable and applying the changes in the override request accordingly to resolve override conflicts between the current component and at least one other component in the hierarchy; and a negotiator for enabling communication between the at least one parameterized behavior element of the current component and at least one other component according to a protocol based on the component resolver and predefined override rules for the at least one other component.

[0034] Further, in accordance with a preferred embodiment of the present invention, the element handler includes an artificial intelligence / machine learning engine that performs artificial intelligence and machine learning analysis based on user activity and analysis of other websites and pages, and recommends modification overrides for the website components based on the analysis.

[0035] Furthermore, in accordance with a preferred embodiment of the present invention, the WBS editor includes a component editor that allows a user to create and define override rules for parameterized behavior elements of a website component, a component selector that allows a user to select a component, and an edit behavior applier that applies edit changes to the selected component.

[0036] Furthermore, in accordance with a preferred embodiment of the present invention, the editing changes include at least one of selecting, dragging, dropping, resizing, copying, pasting, and modifying attributes.

[0037] Furthermore, in accordance with a preferred embodiment of the present invention, a parameterized behavior element represents at least one of a style, a body, and a logic of the current component.

[0038] Furthermore, in accordance with a preferred embodiment of the present invention, the override request is for an overridable parameter of a parameterized behavior element.

[0039] Furthermore, in accordance with a preferred embodiment of the present invention, the website component further includes at least one of an editor behavior driver that affects the presentation 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 preferred embodiment of the present invention, there is provided a method for a website building system comprising the steps of storing website components and their associated component hierarchies, each component including overridable and non-overridable parameterized behavior elements and data handlers, the data handlers handling an override protocol for the component; reviewing all components to be rendered for a current view and for a current component, processing a request for communication between the current component and at least one other component in the component hierarchy to satisfy an override request from the at least one other component, and updating the current component according to the data handlers of the current component only if the override request relates to an overridable parameterized behavior element of the current component.

[0041] Furthermore, in accordance with a preferred embodiment of the present invention, the method further comprises the step of initiating, at run-time, the above-mentioned steps of reviewing, processing and updating the current components for the current view.

[0042] Additionally, in accordance with a preferred embodiment of the present invention, the method includes the step of allowing a user to select a component during an editing session and apply editing changes to the selected component.

[0043] Furthermore, in accordance with a preferred 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, in accordance with a preferred embodiment of the present invention, the method further comprises the steps of identifying a component hierarchy for the current component, and determining whether the current component is a semantic composite.

[0045] Further, in accordance with a preferred embodiment of the present invention, the reviewing, processing and updating step includes the steps of receiving an override request from the current component from the user enabling step as a result of an editing change and / or from the invoking at runtime step as a result of a change to the current component due to a change from an external source, receiving from a data handler of the current component which parameterized behavior elements of the current component are overridable and applying the changes in the override request accordingly to resolve override conflicts 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 in accordance with the receiving, applying and resolving steps and a protocol based on predefined override rules for the at least one other component.

[0046] Furthermore, in accordance with a preferred embodiment of the present invention, the reviewing, processing and updating steps further include performing artificial intelligence and machine learning analysis based on user activity and analysis of other websites and pages, and recommending override modifications to website components based on the analysis.

[0047] Furthermore, in accordance with a preferred embodiment of the present invention, the above-mentioned steps of enabling a user to select a component and apply editing changes include the steps of enabling a user to create and define override rules for parameterized behavioral elements of the website component, enabling a user to select a component, and applying the editing changes to the selected component.

[0048] Furthermore, in accordance with a preferred embodiment of the present invention, the editing changes include at least one of selecting, dragging, dropping, resizing, copying, pasting, and modifying attributes.

[0049] Furthermore, in accordance with a preferred 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, in accordance with a preferred embodiment of the present invention, the override request is for an overridable parameter of a parameterized behavior element. [Brief description of the drawings]

[0051] The subject matter which is believed to be the invention is particularly pointed out and distinctly claimed in the concluding portion of this specification, however, the invention, together with its objects, features and advantages, both as to organization and method of operation, may best be understood by reading the following detailed description when read in conjunction with the accompanying drawings, in which:

[0052] [Figure 1] FIG. 1 is a schematic illustration of a representative representation of a website building system and a page created using the website building system. [Diagram 2] 2 is a schematic illustration of the application of parameterized behavioral elements on a semantic composite constructed and operative in accordance with the present invention; FIG. [Diagram 3]1 is a schematic illustration of an extended component constructed and operative in accordance with the present invention; [Figure 4] 2 is a schematic illustration of the relationship between two components that employ parameterized behavior elements constructed and operative in accordance with the present invention; FIG. [Diagram 5] 1 is a schematic illustration of a system for smart interaction between components and containers of a website constructed and operative in accordance with the present invention; [Figure 6] FIG. 6 is a simplified schematic illustration of elements of the extended element handler of FIG. 5 constructed and operative in accordance with the present invention; [Figure 7] FIG. 6 is a schematic illustration of elements of the content management system of FIG. 5 constructed and operative in accordance with the present invention; [Figure 8] FIG. 6 is a simplified schematic illustration of elements of the WBS editor of FIG. 5 constructed and operative in accordance with the present invention; [Figure 9] FIG. 2 is a schematic illustration of an exemplary flow of overrides within a hierarchy of components constructed and operative in accordance with the present invention; [Figure 10] 1 is a schematic illustration of an arrangement for vertical alignment lines in a V-box smart container constructed and operative in accordance with the present invention; [Figure 11] 1 is a simplified schematic illustration of a specialized container component for managing move, resize and additional handles for contained components constructed and operative in accordance with the present invention;

[0053] It will be understood that for simplicity and clarity of illustration, elements shown in the figures have not necessarily been drawn to scale. For example, the dimensions of some elements may be exaggerated relative to other elements for clarity. Further, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or analogous elements. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[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 understood by those skilled 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 has realized that 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, which requires constant updating based on internal (i.e., designed by the website designer or explicitly) and external factors. These (sometimes component-level specific) updates often require detailed knowledge of the use of the website building system itself in order to effectively define them and implement them simply and efficiently. Furthermore, website components (including external third-party application components) may have behaviors applied to them that may affect other components in the same hierarchical configuration across multiple hierarchical levels within the website building system environment.

[0056] It will be appreciated that a typical website building system may have three types of users: the component providers themselves, who may be part of the website building system vendor staff or a separate component provider (e.g., via a component store or third-party application store), the website designers themselves who build the site using the components, and the viewers or end users who use the completed site. It will also be appreciated that there may be some intermixing between the classes. In particular, the website building system may allow the designers (or some of them) to edit existing components or even add their own new components, for example, to save a component collection defined by the site designer as a component that may be made available to other site designers similar to those described in U.S. Patent No. 6,399,433 and U.S. Patent No. 6,399,433, entitled “METHOD AND SYSTEM FOR SECTION-BASED EDITING OF A WEBSITE PAGE,” published Feb. 16, 2017, which are incorporated herein by reference and are assigned to the common assignee of the present invention.

[0057] Applicant recognizes that a website building experience may be improved by a system that processes website components having parameterized behavior elements therein that may define the behavioral and / or visual behavior of the components (for example). Components may use their parameterized behavior elements to invoke a form of communication with other components to send and receive parameters, as described in more detail later in this specification. For example, component A may notify component B to replace parameterized behavior element X of component B with parameterized behavior element Y. It will be appreciated that a given parameterized behavior element may be predefined to be overridable or not overridable in the context of a given component type or component instance (and not overridable in others). Thus, due to the hierarchical nature of web pages (for example) (as shown in FIG. 1), behavioral changes made to a single current component may affect other components at all contained levels (although perhaps not in the same sub-hierarchy of the affecting component), and vice versa. For example, containers may interact with multiple levels of contained components within them, based on a protocol of predefined rules that allow both the container and the contained components to determine which attributes of the contained components may be affected and in what manner. The logic for this protocol may include rules for "negotiable" overrides of parameterized behavior elements, along with awareness of component relationships with other components / containers, such as geometry, semantics, content, edit history, etc. Contained components may similarly affect their containers.It will be understood that overriding may mean modifying the attributes or parameters of a parameterized behavior element, or may mean completely replacing one or more parameterized behavior elements, as will be described in more detail later in this specification.

[0058] Applicants further recognize that the principles described above may be extended to support containers that may provide artificial intelligence (AI) and machine learning (ML) based modifications to the layout configuration of contained components. Such modifications may include layout only (e.g., selecting position and size), a restricted set of attributes (e.g., a container may provide a specific background image / video for sub-containers within it, or may simply affect color selection, etc.), behavior, or behavior of any particular contained component, such as adding, removing, reordering contained components, etc. In some embodiments, this may also be applied to non-container components.

[0059] Applicant also recognizes that the use of the above-described parameterized behavior elements may improve the manner in which web page formatting is defined over prior art methods such as Cascading Style Sheets (CSS). Existing CSS-based systems affect the style or behavior of elements by collecting rules from multiple style sheets (provided by the browser, the user, and the site itself) and matching these rules to elements in the site. This matching is based on the selectors to which each rule is provided, which are typically based on HTML element type (e.g., DIV), class, ID, or a combination thereof. Prior art systems may also have components with default behaviors and the option to override them, but not through the use of parameterized behavior elements. Elements may have an implicit (default) style or behavior. For example, a DIV is a box that implicitly expands to 100% of the available space of its parent element.

[0060] The applicant further recognizes that the use of parameterized behavior elements allows for building styles across a web page with the additional functionality of allowing components to specify who may or may not affect them (e.g., "only galleries may modify their size"). In particular, this specification may be based on component analysis of (for example) the component's content, geometry, type, semantic type, edit history, business information (BI), and relationships between components. Such analysis may provide additional component classification and related information (not explicitly provided by the designer), which may be used to determine the applicability of styles (or other attributes) to the analyzed components. For example, in the case of "apply a red bevel to all image-caption pairs found in a container", caption-image pairs are found (rather than predefined) through component analysis, as described in U.S. Patent No. 5,399,363.

[0061] Reference is now made to FIG. 2, which illustrates this detection and classification. In line 1, six unrelated objects are shown: three smiles and three captions. In line 2, it is shown how the system, in accordance with the instructions, recognizes the smile and caption pairs (as semantic composites) and applies a frame around each face / caption pair. In line 3, it is shown how, even if the user moves the caption of the rightmost "pair," the distance between them is still within the definition of the face / caption pair, and therefore the frame is still applied. Reference is now made to line 4, which shows how, when the caption is moved outside the requirements of the semantic composite definition (and therefore is no longer recognized as a semantic composite for the face / caption pair), the frame is removed from around this pair. In line 5, the rightmost image has been altered, and the system does not recognize it as a smile, and therefore does not draw a frame. It will be appreciated that this feature is not applicable to regular CSS since it cannot identify pairs of face images and captions.

[0062] Applicant also recognizes that this use allows a containing component to affect multiple levels (containing components nested within a component container) so that the component modifications applied can be "deep" - for example, "make all contained video players at all contained levels appear without rewind buttons" or "apply video background with video X to all contained sub-containers".

[0063] It will be appreciated that, in general, website components are highly configurable and their attributes and operation can be influenced from both internal and external sources (e.g., components that are outside the normal site hierarchy and may not be visible within the site) to the website building system with which they are associated. For example, a service that adapts a particular site component to the time of day or season. The list of contained components (within a given container of a page) may be predefined or dynamically identified and may be used in a number of different scenarios, for example in a website building system scenario where components are predefined with their accessible attributes, or in a non-website building system scenario where an analysis is performed on a given website page to identify the division of that page into components and containers and their attributes.

[0064] It will be understood that the definition of a website component generally includes three main sub-entities: style, body, and logic elements (as well as additional elements as described in more detail later 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 (e.g., HTML, XML, or JSON, etc.) or by a proprietary or non-standard language (e.g., JSX, etc.).

[0065] The logic of the component may be defined by any procedural language, e.g. JavaScript or TypeScript, or by any regular programming language that allows the use of native code elements in the website, or it may be defined through a dedicated browser, a browser add-on or a mobile app if the associated website building system at runtime is implemented using a native client. It houses the business / operational logic of the component. The logic definition language may also include various language extensions to the underlying language (e.g. the E-JS language that extends the regular JavaScript language).

[0066] It will be understood that these elements (which are part of the component definition) may be referred to (together) as the SBL (style / body / logic) elements of the component. Such component definitions may be created outside the system using the usual tools available to developers (e.g., editors, etc.). 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 website building system vendor's staff. Alternatively, this component editing environment may be made available to external component developers or to site designers (allowing them to define their own components).

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

[0068] It will be appreciated that a website page may be constructed using a hierarchy of component instances that may contain additional information in addition to the component definition reference (e.g., content, hierarchical position, screen position, size, various layouts, component metadata, and other attributes).

[0069] Reference is now made to FIG. 3, which illustrates a definition of a representative extended component 10 in accordance with one embodiment of the present invention. It will be appreciated that the extended component 10 may enable smart interaction between related components by communicating style, behavior, and operation changes through the parameterized behavior elements contained therein. The extended component 10 may have an extension or additional structure beyond that of a typical website component of the prior art. It will be appreciated that the definition of an extended component may include style, body, and logic elements as described herein above, but may also include parameterized behavior elements that may or may not allow overriding according to predefined rules and protocol resolution 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] Editor behavior drivers 15A can influence the way in which a component and its contained components are processed by the editor in use (eg, by providing dynamic layout hints).

[0072] Runtime behavior drivers 15B can affect the way in which a component and its contained components are processed during runtime. Component rendering functions 15C can provide rendering instructions during both edit preview and runtime. For example, an input component may use a quick response renderer to provide helpful feedback to a user of the website building system.

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

[0074] The override data handler 16 may communicate information about the above predefined rules and protocol resolution for the component, i.e., what the override conditions are. Metadata 17 may also include metadata for the component (e.g., author information and internal reference IDs, etc.). Fixed area 18 contains elements of the component that cannot be overridden, such as areas within the component where content is stored in each component instance.

[0075] It will be appreciated that a parameterized behavior element may be equated to a function parameter in a typical programming language. Thus, a single extension component 10 may contain multiple parameterized behavior elements, each of which may have a different type and affect different parts of the extension component 10 (if permitted). For example, a style parameterized behavior element type may handle style, a layout parameterized behavior element type may handle layout, etc. It will also be appreciated that a parameterized behavior element does not necessarily conform to standard SBL classification, but may override multiple SBL elements as well as other elements.

[0076] Hereinafter, for ease of explanation, references to a website component will be understood to mean the extension component 10 described herein above.

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

[0078] So, for example, a page designer may embed a desired grid gallery component, but override its internal behavior to position the gallery contents using slider placement (by providing a parameterized behavior element of the slider layout as part of the grid-based gallery).

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

[0080] Components may also support including multiple parameterized behavior elements that together with the component definition form a complete component. For example, a button component may support including a background parameterized behavior element and a layout parameterized behavior element. A button component alone may provide the basic framework for a button (e.g., provide a displayed object with "pressed" and "not pressed" configurations and an "I was pressed" event trigger associated with them). These two contained parameterized behavior elements may provide the background for the button and the display layout for the elements that are 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 a button) and a layout parameterized behavior element of type Hbox (horizontal box) (which displays button surface elements such as a label and a small icon arranged horizontally).

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

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

[0084] It will be appreciated that a parent component instance that contains a child component instance may modify the child component instance (and vice versa) through the application of parameterized behavior elements as described in more detail herein below. A single component may be modified by multiple parameterized behavior element types that affect various aspects of the component's display and functionality. Such parameterized behavior element types may affect any of the component's SBL subentities, i.e., its style, body, and logic. Different parameterized behavior elements usually (but not always) affect different aspects of a 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 subentities of a component, for example both the component's style and body. The actual application of parameterized behavior elements may be performed during the rendering process. The system that implements the parameterized behavior elements may perform pre-processing during the invocation of the component or page publication (to save follow-up processing).

[0085] As described above in this specification, one type of parameterized behavior element type is a layout, which controls the layout (position and sometimes size) used for sub-elements of a component, such as the Hbox (horizontal box) layout parameterized behavior element described above, which displays its inner elements along a horizontal line.

[0086] Another example is applying the parameterized behavior element of a matrix gallery layout to a generic gallery component: A pre-built matrix gallery component displays its internal elements in a matrix of rows and columns, possibly scrolling to reveal more elements than the basic matrix size allows.

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

[0088] As mentioned herein above, another type of parameterized behavior element type is a style, which controls aspects of the visual presentation of a component (eg, the component's color, margins, etc.).

[0089] The style's parameterized behavioral element type may be used, for example, for background replacement. An advanced video player component may include multiple buttons and control regions that are customizable. The style's parameterized behavioral element type may be used to replace the colors and patterns of the button and control region backgrounds to create personalized versions of the video player component.

[0090] A style's parameterized behavior element type may also affect other (non-layout) parameters of the contained component, which may be distinct from parameterized behavior elements that affect the presentation of the component itself (rather than the components it contains).

[0091] As described herein above, a component definition may consist of multiple sub-elements (representing style, body and logic, plus additional elements). As part of a component instance definition within an application, some of these elements may be overridden (subject to appropriate rule negotiation) by parameterized behavior elements. These replacement parameterized behavior elements may themselves have parameters that define their behavior or functionality. Such parameters may be required (i.e., if they are not provided, the parameterized behavior element will not function), or instead, the parameterized behavior element may provide defaults for their values.

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

[0093] Now, referring to Figure 4, this illustrates the relationship between two components in an application. As can be seen, an instance of COMP2 in an application requires for its component definition the Parameterized-Behavior Elements obtained from another component (COMP1 in this scenario) and certain parameters for these Parameterized-Behavior Elements. These Parameterized-Behavior Elements and parameters can then affect the style, body, logic and other elements of the component.

[0094] As illustrated in Figure 4, a single component may accept multiple parameterized behavior elements from other components. This may be via negotiation elements (as described in more detail later in this specification). Such multiple parameterized behavior elements may have distinct or cumulative effects. For example, a gallery component may allow the use of two style parameterized behavior elements: one that affects the background region of the gallery frame and one that affects the subcomponents that the gallery manages.

[0095] It will be appreciated that a component may also accept other composite or hybrid parameters (of non-parameterized behavior elements) from another component, for example parameters based on aggregate types (e.g., list, structure, union, etc.).

[0096] Also, in embodiments where a web-like language (i.e., E-HTML / CSS / JS) is used to define a page or component, parameterized behavior elements may also be defined using call parameters / attributes (described in more detail later in this specification) for the component, or by using stylesheets with additional rules for the particular parameterized behavior element type, e.g.

[0097]

number

[0098] It will be understood that a parameterized behavior element type (e.g., a layout parameterized behavior element, etc.) generally has limited / specific functionality. It may only deal with the physical layout of contained components in a gallery (e.g., providing a matrix / slider carousel arrangement), and therefore typically does not include a complete SBL specification. However, a parameterized behavior element may include specific additional attributes. For example, a specific matrix layout parameterized behavior element type may also include some visual attributes (e.g., applying a yellow background to some subcomponents of a host component). However, the typical definition of a layout parameterized behavior element type focuses on the arrangement of subcomponents, and typically does not include additional attributes and properties.

[0099] It will also be appreciated that parameterized behavioral elements are typically created through the component editing functionality of a website building system (described in more detail below) or, in some cases, by a dedicated parameterized behavioral element-specific editor.

[0100] Thus, in addition to its standard style, body and logic, an extended component may have parameterized behavior elements that contain information about the component's layout, configuration, editor drive, rendering process and runtime behavior. Extended components may accept parameters from other associated components (via parameterized behavior elements) that can define, add or modify any of the SBL elements or parts of them.

[0101] Referring now to FIG. 5, there is illustrated a system 200 for smart interaction between website components and containers in accordance with one embodiment of the present invention.

[0102] The system 200 may include a website building system, extensible element handler 210, a website building system (WBS) runtime server 220, a website building system (WBS) 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 client systems operated by website building system vendor staff 261, a site designer 262, a site viewer 263, and an external system 270.

[0103] It will be appreciated that the functionality of the system 200 and its elements may be similar to that of the system 100 described in US Pat. No. 6,399,326.

[0104] It will be further appreciated that the workflow of the 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 via a preview process using the WBS editor 230 and as part of a runtime process performed by the WBS runtime server 220 as described in U.S. Patent No. 6,399,436.

[0105] The extended element handler 210 may handle communication between associated website components regarding parameterized behavior elements. Referring now to Figure 6, which illustrates elements of the extended element handler 210. The extended element handler 210 may include a request receiver 211, a resolver 212, a negotiator 213, and an AI / machine learning machine 214, which may incorporate AI and machine learning principles described in more detail herein below.

[0106] 7, as illustrated, a CMS (content management system) 250 may hold all forms of content and layouts related to the website building 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 building 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 that coordinates data between the content management system 250 and the system 200. It will be understood that the setup and functionality of the CMS 250 may be similar to that of the CMS 50 in Patent Document 2.

[0107] The page analyzer 260 may pre-process and analyze the incoming web pages to identify data structures and their interrelationships, as described with respect to the page analyzer 44 in U.S. Patent Application Publication No. 2013 / 0133991, entitled “SYSTEM AND METHOD FOR THE CREATION AND USE OF VISUALLY-DIVERSE HIGH-QUALITY DYNAMIC LAYOUTS,” issued on August 29, 2017, and assigned to the common assignee of the present invention. In this manner, it will be appreciated that the page analyzer 260 may identify semantic composites, repeater components, and general component hierarchies.

[0108] The WBS editor 230 may be a visual editor of a typical website building system that knows how to handle parameterized behavior elements and the ability for extended components to provide special editing behaviors. The WBS editor 230 may also be fully aware of the data structure of the page being edited. The WBS editor 230 may allow vendor staff 261 and / or designers 262 to interactively edit / create website pages, as described in more detail herein below. Referring now to FIG. 8, elements of the WBS editor 230 are illustrated. The WBS editor 230 may include a component selector 231, an editing behavior applier 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 contains multiple (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 website building system vendor (from the CMS 250) and by third-party component providers) and use information from these components in the page editing environment.

[0110] One such use is the use of component metadata 17 (e.g., component name, description, type, and origin), SBL information, and SBL interface definitions to create an interface that allows selection of components for inclusion on a page. It will be appreciated that the component selector 231 may further build an interface for each of the SBL elements of the selected component, for example 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 UI, which may be included in the WBS editor 230, to enable the website designer 262 to customize a particular component instance. 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 that is used in the WBS editor 230 to configure the component. This may be the complete UI code (e.g., a UI that can be displayed using a separate iFrame) or it may be a set of parameters that are provided to the WBS editor 230, which generates and presents the actual configuration UI.

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

[0114] It will be appreciated that a component may provide a set of customization properties and related information (known as a customization record). The WBS editor 230 may then create a customization dialog by collecting these customization records, optionally integrating records from multiple components, and generating a customization UI. Such functionality is described in more detail in U.S. Patent Publication No. 2013 / 0133994, entitled “SYSTEM AND METHOD FOR DIALOG CUSTOMIZATION,” issued September 5, 2017, which is incorporated herein by reference and is assigned to the common assignee of the present invention. It will be appreciated that an override parameterized behavior element may override these customization records to provide an alternative customization interface.

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

[0116] As another example, a component may provide alternative component versions or configurations. One example is to provide a simplified or lightweight version of the component; in this scenario, the system 200 may display the component (partially) "live" while dragging or zooming the component (as opposed to displaying the component when it is static). For example, a video player component may provide an alternative lightweight version to use while dragging and resizing the component. Such a version may use (for example) a lower resolution, a lower frame rate, or repeated display of small video sections to make it easier to display while dragging and resizing.

[0117] A component may also provide information related to the layout and organization of the component. Such information may include (for example) minimum or maximum component size, a whitelist of allowable layout-parameterized behavior elements, etc.

[0118] The component definition may also include specific hints that direct the dynamic layout process in which this component participates (as described in U.S. Patent No. 6,363,313, entitled “WEB SITE DESIGN SYSTEM INTEGRATING DYNAMIC LAYOUT AND DYNAMIC CONTENT” published Aug. 22, 2013, which is incorporated by reference herein, and is assigned to the common assignee of the present invention), or may also include specific guidelines that are used to create special edit handles for a given component that affect any dynamic layout behavior and the operation of dynamic layout rules when the component is edited (as described in U.S. Patent No. 6,363,313, entitled “METHOD AND SYSTEM FOR THE USE OF ADJUSTMENT HANDLES TO FACILITATE DYNAMIC LAYOUT EDITING” published Sep. 5, 2013, which is incorporated by reference herein, and is assigned to the common assignee of the present invention).

[0119] As described herein above, the process of the system 200 has different stages. During the component definition stage, the WBS vendor staff 261 (and often the designer 262) may use the component / container editor 233 to define and create some standard parameterized behavior elements, including specifying which parameterized behavior element types may be overridden and under which conditions. It will be appreciated that the component definer (vendor 261 / designer 262) may also define a container component (containing the parameterized behavior elements they wish to override in the contained component) and possibly specific parameter values, under the relevant conditions.

[0120] A site designer 262 may use these components and containers to design his or her website at the page definition stage. The site designer may also modify any predefined overrides, or in some cases, define his or her own parameters using the edit behavior applier 232. It will be appreciated that the system 200 may additionally allow the site designer to define his or her own override requirements for components within containers, etc., or may allow full editing of all parts of the components and containers.

[0121] It will be appreciated that the editing behavior applier 232 may apply various object editing operations typically effected using a mouse, keyboard or both (as well as any other user interface input means). These may include select, drag, drop, resize, copy, paste, etc., as described in US Pat. No. 6,399,363.

[0122] It will be appreciated that the site designer 262 may work using WYSIWYG (what you see is what you get) and thus interactively resolve and display pages during editing. However, the associated website pages may also be modified at run-time by changes to databases in the CMS 250 (the underlying databases) or by changes to databases in external sources displayed via repeater containers (reflecting these database changes, e.g., showing added or deleted records).

[0123] As described herein above, components may accept parameters that can define, add or modify any of the SBL elements, such as any of the parameterized behavior elements described above. Additionally, parameterized behavior elements may accept their own parameters, such as "modify all contained components with a color modifier that fades the color by X%."

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

[0125] It will be understood that the element handler 210 can be triggered by the WBS runtime server 220 (before a page can be loaded or refreshed) or by the WBS editor 230 when editing changes are 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 an override request (from a user edit request, or from an automated system request, as a result of a change from an external source 270 / CMS 250 during page load / refresh / rendering). The resolver 212 may identify which components are affected within the relevant containment level (based on the conditions and selection rules specified by the request component) and the results of the page analyzer 260, and may receive from the data handler 16 which parameterized behavior elements (from each component) are overridable. As described above in this specification, the page analyzer 260 may identify the complete component hierarchy. This may include detection of semantic composites (described above in this specification) that have elements that are subject to override and may be part of the hierarchy. Thus, the complete hierarchy may be based on predefined containers, repeater containers (defined based on the data source), and semantic composites (defined based on the page analysis).

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

[0128] 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 it. Meanwhile, the container may be trying to override elements of its contained component. Thus, loops or conflicts may result that can be resolved by resolver 212 (through determining which override requests to ignore, thereby breaking the loop).

[0129] As described herein above, some parameterized behavior elements may be predefined as overridable, while others may not be predefined as such, and if an override is permitted according to the protocol, resolver 212 may implement the override.

[0130] Thus, although component changes may result in crossing hierarchical boundaries, resolver 212 may apply component changes based on rules that flow generally along the container hierarchy. It will be appreciated that resolver 212 is typically part of a complete run that is performed while converting the web site building system's database structure into HTML (or otherwise preparing it for display), but may be re-run due to a trigger. This may be a stand-alone step, or may be integrated into the complete conversion step.

[0131] Based on this analysis and the identified component hierarchy, resolver 212 may traverse the page hierarchy to identify all override requests made by various overriding components. An override request may include the application of a parameterized behavior element, but may also be a simple attribute override ("set color to green") that does not include a parameterized behavior element.

[0132] It will be appreciated that resolver 212 may identify a list of all override requests and any corresponding components, i.e., components to which those override requests should apply. Resolver 212 may also receive responses from each corresponding component to each override request applicable to each corresponding component, as identified by the corresponding component's own whitelist / blacklist or other corresponding component-specific rules governing the override request. Referring now to FIG. 9, an example override flow that may occur within a hierarchy of components is illustrated. For example, a component (comp1) may override associated parameterized behavior elements of a set of components that are in or contained within the same container as comp1 (e.g., components 2 and 3 and semantic composite 1, except repeater 1). Also, component (comp1) may override comp4, which is at a different containment level (i.e., within comp3).

[0133] Resolver 212 may also determine the order in which override requests should be applied, which can be based on a user-specified order (e.g., an override component providing multiple override requests and specifying their order or priority) or based on system rules (similar to specificity rules that specify the order in which CSS rules are applied).

[0134] The resolver 212 may then apply the override request to all corresponding components according to the determined order. It will be appreciated that applying the override request to a particular corresponding component may affect the manner in which the affected component interacts with other components (as condition evaluations may yield different results). For example, if component A affects component B, a change to component B may result in a situation in which component B affects component C, or is affected by component D, being resolved differently. This may be due, for example, to special rules for component B (as part of the override data handler 16) that may cause some or all changes to component B to further initiate overriding of other components by component B. It will be appreciated that such override rules may cause the phenomenon of "chain reactions" between components and may also cause "overriding circles", which may be detected and resolved by the resolver 212.

[0135] In an advanced 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 may be written using a regular programming language (e.g., JavaScript, etc.) or a restricted scripting language adapted for such negotiation. In either case, the negotiator 213 may execute such code snippets in a sandbox or other closed execution environment.

[0136] In general, it will be appreciated that overriding of parameterized behavior elements (including resolution and negotiation) typically occurs during the rendering stage of a page, i.e., when a page is edited or refreshed (at edit time and at runtime). It will be appreciated that the extendable element handler 210 may be integrated with the part of the system 200 that processes the definitions of the website building system CMS 250 and generates an output for the user. This may be a physical rendering to a screen (e.g., using a dedicated client application) or it may be the creation of an HTML version of the site. It will be appreciated 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 a combination of both.

[0137] In another embodiment, the browser may reactivate the web site building system to HTML process upon the occurrence of a trigger (possibly including a user interaction) to recreate part or the entire rendered page. This may also be performed based on operational code (JS) within the page that operates based on various triggers.

[0138] Triggers can include a variety of events that can be described as dynamic layout triggers (data changes, site edits from another user, server notifications) and manipulation triggers on the page itself (user interactions, JS operations).

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

[0140] It will also be appreciated that updates to components are not saved in CMS 250 since they are part of the dynamic page resolution, i.e., performed at the preview stage (during editing) or at runtime. It will also be appreciated that resolution needs to be performed at runtime / preview because the components themselves may further change during runtime due to (for example) dynamic layout triggers and component logic. It will also be appreciated that such changes may further affect the override process, such as changing the results of geometry / content analysis. For example, if component A (via a parameterized behavior element) changes attribute X of component B (which updates the value of attribute X to create version 2 of component B), component B is not saved in CMS 250 with the new value of attribute X, since this change may affect component B on its next use. The next time component B is used (for example), component A may not override component B and the original value of attribute X will be lost. One exception may be the saving of a cached version of the page with component B with the new value of attribute X for quick rendering.

[0141] As described herein above, a parent component or page may set (or specify) properties of predefined components contained within the parent component by call line parameters or by associated style sheets that contain rules that set certain properties. Such specifications may also include some overrides. For example, a component may have a predefined default color, and this specification may override the default color. This may also apply to system specific attributes. For example, a component may have parameterized behavior elements of a default or built-in layout, and a calling component may specify parameterized behavior elements of an alternative layout.

[0142] A component may also explicitly override attributes of a managed component provided to it by its parent, for example:

[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. Within div2, the gallery component overrides the CSS 'color' attribute for the receiving child components and sets it to green. This would concern the children of grid1 (which presumably have a background color), but not the children of image (i.e. image1, image2, which would not have any background color definition). It will be understood that such overrides do not apply to the predefined button components nav1 and nav2.

[0145] As described herein above, the element handler 210 may apply a parameterized behavior element type (e.g., layout, etc.) to a managed element (contained component). This may be done, for example, by making a call such as "child.toVdom({--display: Carousel})" at the component's definition. It will be appreciated that in the above example, such an override would pertain to the grid component managed element (grid1), but not to the image component managed element.

[0146] As another example, a format like "child.toVdom({display: 'block'})" may be used to override a particular layout's parameterized behavior element parameters (i.e. how images are displayed), if this is relevant.

[0147] In systems based on the E-HTML / CSS page specification, such overrides may also be achieved through specific styles that can be referenced through inline class references or the class add function, for example as follows:

[0148]

number

[0149] As described above in this specification, the WBS vendor 261 / website designer 262 may use the WBS editor 230 to place limitations on a component's ability to set or override certain attributes of elements it predefined (i.e., subcomponents), elements it manages (i.e., contained children), or both. Exemplary embodiments may limit property setting or override to outer layout and style properties, and may not allow setting, overriding, or modifying properties of other elements (including, among other things, the content of the element).

[0150] As described herein above, the functionality of the system 200 may include special handling of managed elements (ie, components within a container).

[0151] For example, when a container component X is passed a list of managed elements (A1..An) for inclusion / display, it may transform those managed elements in some manner before displaying them, based on (for example) the type of X, the parameters of the 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 displaying every odd-numbered item to the right and every even-numbered item to the left (also known as zigzag display). This may also be based on the attributes, content or structure of the managed elements, for example, managing elements may be justified from the top to the right or left based on whether their brightness is higher or lower than a certain value.

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

[0153] It will be appreciated that the E-HTML / CSS-based embodiment of system 200 also allows for the definition of extensible stylesheets, which may provide a path or API through which a component's elements may be modified from outside the component. This may be used, for example, to override parameterized behavior elements or regular attributes, and may also be extended to CSS (by adding on-top parameterized behavior elements to the component).

[0154] A typical definition has the following form (as used, for example, in the definition of a gallery component):

[0155]

number

[0156] It will be appreciated that the E-CSS definition and use of the above layout parameterized behavior element type allows us to define a set of extensible and overridable layout properties that can be applied to an instance of this component (i.e., grid1 in the gallery definition), including setting the gutter, column and color properties of grid1.

[0157] It may also define the above "layout parameterized behavior element type" as a custom pseudo-element that can be customized or overridden from external components that use this gallery component.

[0158] The "@extend" statement above informs the system 200 that this style sheet may be extended or overridden by a parent component. The list of properties defined in the style sheet containing this "@extend" acts as a whitelist of properties that may be overridden. Furthermore, the style sheet itself may be extended by adding other properties. It will be understood that values ​​specified for different attributes in the style sheet (e.g., gutter=3 above) act as default values ​​if a 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 (eg, "-public: true") instead of the "@extend" directive.

[0160] In this scenario, no other properties of grid1 or of grid2 are "open" and are not part of the public interface of the gallery component: other properties of the gallery component, whether custom or predefined, are not inherited from the containing component in order to preserve the integrity of the component, except for potential explicit overrides of properties through an @extend-based API as described above in this specification.

[0161] The use of the wildcard property specification above represents all properties beginning with the prefix "prop-gallery-*." The system 200 may support other wildcard specifications as well (including the specification of CSS properties that follow color-related, background-related, etc. property groups). It will be understood that the specification may also represent regular CSS properties (non-extended properties), such as the reference to 'color' above.

[0162] As discussed herein above, resolver 212 may further implement white / black listing according to "who can override" (i.e., which "parent" components may override the public property) rather than "what can be overridden." As discussed herein above, this information may be provided by data handler 16, and may also be based on various parameters and properties of parent components, such as the component's type, name, screen area, or other attributes (e.g., what layout parameterized behavior element types are used). The syntax for such a specification may be, for example, as follows:

[0163]

number

[0164] For the invocation, the component or page that contains the above gallery component (as the owner) may use the public properties as parameters, for example:

[0165]

number

[0166] This can be accomplished using any of the methods described above. The number of columns specified in the calling parameters (4) overrides the default value, which is 5. Such overrides or specifications can only be applied to directly owned components (e.g., the gallery in the example above). Overrides may also be applied to indirectly owned components when a shared root component is involved.

[0167] As described herein above, the system 200 may support smart containers, i.e., container definitions may include editor interactions, special handles, and editing and runtime behaviors.

[0168] The component / container editor 233 may also allow for the creation of smart containers and may further interface with specific edit drivers 15A that may be associated with smart container types.

[0169] It will be appreciated that smart containers may manage the components they house and interact with them via resolvers 212 to provide a set of behaviors not found in regular containers.

[0170] In particular, the container may define certain 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 below a certain size), and a specialized container may transform the various components contained within it, for example converting all contained galleries into slider-type galleries.

[0171] The container may define the style of the components contained within it. This may be done, for example, through a set of settings and attributes that can be applied to those components. These may include presentation elements (e.g., color, bevel, etc.) and functional elements that drive the WBS editor 230 (e.g., additional handles that allow certain operations, etc.).

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

[0173] The container may determine the manner in which contained components are arranged therein (e.g., gallery, accordion, book format, etc.) and may impose specific behaviors on subcomponent layouts therein, for example affecting dragging and resizing therein (e.g., requiring snapping to a grid or specific alignment). The container may also determine the dynamic layout handling therein, which may differ from the default dynamic layout handling methods used for normal containers. It will be appreciated that the dynamic layout handling may be based on dynamic layout hints as described herein above. It will be appreciated that the functionality as described herein above may be defined through the editor behavior driver 15A and the runtime behavior driver 15B.

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

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

[0176] One such aspect is the drag behavior of components within the editor during editing. Possible behaviors may include VBox (vertical box) behavior, where all drags are snapped to a vertical line. Components may be auto-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 its content to properly position components that are dragged into "invisible" positions.

[0177] Yet another such aspect is drag-and-drop behavior: for example, a text edit box may be implemented as a smart container that, instead of using a precise drop location, places dropped components in the right position so that they are integrated into the flow of the text already typed in the text edit box.

[0178] As yet another example, a 3D container type may add 3D manipulation handles and 3D behaviors to contained components. The container may provide associated logic and UI elements to the WBS editor 230 to support such 3D behaviors. 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 editing actions are performed.

[0179] The container may allow the designer 262 to define some parameters that control the editing and runtime behavior of the container, and in some cases, to override some existing component attributes. For example, as illustrated in Figure 10, to which reference will now be made, a Vbox container A may define a default behavior in which the (vertical) line L along which contained components C1-C4 are aligned is at the center of the container. The container may allow the user to override this parameter and specify 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 from the above, a runtime modifiable smart container may allow components contained within it to be moved or resized during runtime (as defined by runtime behavior drivers 15B). A Vbox version of such a smart container may enforce aligning moved contained components to vertical lines within the container as described above.

[0181] In yet another example, a Vbox container places a control between the components it contains that invokes the visual editor's "add component in place" function when the components are arranged along a vertical line.

[0182] In yet another example (as shown in FIG. 11 to which reference is now made), a smart container component A may have the ability to define its internal layout (e.g., by dividing this particular container into X×Y equal rectangles). In this particular example, A is divided into 4×5 rectangles.

[0183] A component placed within this smart container A (e.g., example image component B) "grows" multiple resize handles on each edge, such as handles c and d on the top edge (a similar pair of handles is on each of component B's four edges).

[0184] Smart container A may further implement additional code (working in conjunction with visual stage area E of the website building system) that causes resizing via handle c to snap to the internal grid of A, and causes resizing via handle d to not snap to the internal grid of A. Additional examples of such various behaviors and handle types are described in detail in US Pat. No. 6,399,433, including behaviors that affect dynamic layout parameters and rules.

[0185] It will be appreciated that instead of actual visual handles, the WBS editor 230 may implement "invisible" handle regions that provide specific functionality when the mouse is interacted with. The WBS editor 230 may inform the user when the user is using such an invisible handle, for example, by changing the shape of the mouse pointer.

[0186] The system 200 may support containers that position elements within them according to a visual optimization of the element's placement (eg, using component placement rules) rather than based on predefined positions.

[0187] The dragging implementation 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 captures 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 the component X.

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

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

[0191] Thus, the editor behavior driver 15A may operate within the WBS editor 230 to translate user interactions into property updates. These interactions may include drags, clicks, etc. These may be higher level actions (e.g., "drop component") or lower level actions (tracking each mouse position update). This driver may be monolithic or may consist of a generic driver with component specific drivers embedded in the generic part. It will be appreciated that in some embodiments, 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 the new component may send parameters for its own parameterized behavior element.

[0192] It will be appreciated that other (non-container) components may also have editor behavior drivers 15A, for example a label component may have an editor behavior driver 15A that supports a particular variant of in-place editing.

[0193] As another example, an image display component may provide region-of-interest based processing during editing of a displayed image. Under such a scheme, the system 200 may define a region of interest (e.g., a predefined object in the image) in the displayed image. Such 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 when resizing the image (during editing) to focus on the visible area of ​​the region of interest in the image. Thus, a new combination of positing and cropping may provide optimal focus on the region of interest for a new zoom factor.

[0194] It will also be appreciated that system 200, through AI / machine learning machine 214, may perform modification recommendations for containers providing AI / machine learning based modifications or layout recommendations for components housed therein. It will be appreciated that the functionality of AI / machine learning machine 214 may be similar to that described in U.S. Patent No. 6,399,633, which describes the recommendation of design options and applies the same principles for AI-based recommendations that recommend overrides and parameters in addition to a complete layout.

[0195] Such recommended modifications may include layout only (e.g. position and size choices), a limited set of attributes (e.g. a container providing a specific background image / video to inner sub-containers, or simply influencing color choices etc.), behavior, or any particular contained component sub-elements.

[0196] This may be done for contained components within a single container (page sections, pages and page sets being "higher container levels"), or for a set of containers (e.g. a number of separate page sections that are processed together to provide color matching between each other).

[0197] As described herein above, WBS vendors 261 and designers 262 may use component / container editors 233 to define components with instructions as to how their attributes may be modified.

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

[0199] The AI / machine learning engine 214 may analyze input material, which may include bulk editorial changes (obtained from the editorial history) and application of parameterized behavioral elements, and information about the popularity and ranking of the analyzed sites, pages, and components. This input material may be used to train a machine learning engine (e.g., a neural network-based engine, etc.), which may then provide remediation recommendations. The current state of this machine learning engine may be stored in the ML / AI repository 2510.

[0200] Such recommendation containers may be mixed with other (regular) containers that are subject to relevant privacy and intellectual property laws (e.g., copyright and trademark laws), i.e. laws that govern the use of such information and ensure that the privacy of data belonging to other users is not compromised.

[0201] As described in U.S. Patent Application Publication No. 2005 / 0139991, changes to the structure of a website component may affect the indexing of the website by search engine spiders and therefore may affect search engine optimization. It will be appreciated that the system 200 may also include a search engine friendly renderer that sends information regarding updated containers and components to be indexed to the search engine spiders, as described in U.S. Patent Application Publication No. 2005 / 0139991, entitled "SYSTEM FOR DEEP LINKING AND SEARCH ENGINE SUPPORT FOR WEB SITES INTEGRATING THIRD PARTY APPLICATION AND COMPONENTS," issued September 6, 2016, which is incorporated herein by reference and is assigned to the common assignee of the present invention.

[0202] Thus, parameterized behavior elements may be used to automatically transform the visual and behavioral parameters of components and containers within all containing levels based on override protocols.

[0203] Unless otherwise specifically indicated, and as is apparent from the above description, references throughout this specification using terms such as "processing," "computing," "calculating," "determining," and the like refer to the 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 physical quantities, such as electronic quantities, in the computing system's registers and / or memory, and / or transforms this data into other data that is similarly represented as physical quantities in the computing system's memory, registers, or other such information storage, transmission, or display device).

[0204] An embodiment 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 on the computer. The resulting apparatus, when instructed by software, may transform the general purpose computer into the inventive elements described herein. These instructions may define the inventive device, as necessary, in conjunction with a computer platform. Such a computer program may be stored on a computer readable storage medium, such as any type of disk, including but not limited to optical and magneto-optical disks, read only memory (ROM), volatile and non-volatile memory, random access memory (RAM), electrically programmable read only memory (EPROM), electrically erasable and programmable read only memory (EEPROM), magnetic or optical card, flash memory, disk-on-key, or any other type of medium suitable for storing electronic instructions and capable of being coupled to a computer system bus.

[0205] The processes and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct a more specialized apparatus to perform the desired method. The desired structure for a variety of these systems will be apparent from the above description. In addition, embodiments of the present invention are not described with reference to any particular programming language. It will be understood that a variety of programming languages ​​may be used to implement the teachings of the present invention as described herein.

[0206] While certain features of the invention have been illustrated and described herein, many modifications, substitutions, changes, and equivalents will occur to those skilled in the art, and it is therefore 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 building system (WBS), A processor; at least one database for storing extended website components having parameterized behavioral elements; an extension element handler executing on the processor for invoking an override request between a first extended website component and a second extended website component using the parameterized behavior element; having The override requests implement style, behavior and operation changes in a website building system.

2. The WBS of claim 1 , wherein the first extended website component and the second extended website component include an overridable parameterized behavior element, a non-overridable parameterized behavior element, and an override data handler.

3. an editor behavior driver that influences the rendering and editing of the first extended website component by a WBS editor; a runtime behavior driver that influences how the first extended website component is processed by a runtime server at runtime; a component rendering function that provides rendering instructions for the first extended website component between the runtime server and the WBS editor; The WBS of claim 2 , further comprising at least one of:

4. The extension element handler: a request receiver that receives the first extended website component and the override request from at least one of a runtime server as a result of a change to the first extended website component due to a change from a source external to the WBS and a WBS editor as a result of an editorial change; a component resolver that receives from an override data handler of the first extended website component which parameterized behavior elements of the second extended website component are overridable, applies override request changes, and resolves override conflicts between the first extended website component and the second extended website component; a negotiator that enables communication requests between at least one parameterized behavior element of the first extended website component and at least one parameterized behavior element of the second extended website component in accordance with the component resolver and a negotiation protocol and in accordance with predetermined override rules for the second extended website component; The WBS of claim 1 , comprising at least one of:

5. 5. The WBS of claim 4, further comprising an artificial intelligence / machine learning engine that applies artificial intelligence and machine learning techniques to analysis of other websites and pages of the WBS and user activity to recommend modification overrides for changing style, behavior and operation of the second extended website component.

6. The WBS editor: a component editor that allows users of the WBS to create and define override rules for parameterized behavioral elements of extended website components; a component selector that allows the user to select a first extended website component; an edit behavior applier that enables the user to apply an edit request to the selected first extended website component; The WBS of claim 3 .

7. A method for a website building system (WBS), comprising: The processor: storing in at least one database the extended website components having parameterized behavioral elements; Invoking an override request between a first extended website component and a second extended website component using the parameterized behavior element; Run The override requests implement style, behavior and action changes.

8. 8. The method of claim 7, wherein the first extended website component and the second extended website component include an overridable parameterized behavior element, a non-overridable parameterized behavior element, and an override data handler.

9. affecting the presentation and editing process of the first extended website component by editing; affecting how the first extended website component is processed by a runtime server at run time; and providing rendering instructions for the first extended website component of the runtime server and the WBS editor; The method of claim 8 , further comprising at least one of:

10. Invoking the override request comprises: receiving the first extended website component and the override request from at least one of a runtime server as a result of a change to the first extended website component due to a change from a source external to the WBS and as a result of an editorial change; receiving from an override data handler of the first extended website component which parameterized behavior elements of the second extended website component are overridable, applying override request changes, and resolving override conflicts between the first extended website component and the second extended website component; facilitating a communication request between at least one parameterized behavior element of the first extended website component and at least one parameterized behavior element of the second extended website component in accordance with the conflict resolution and negotiation protocol and in accordance with predetermined override rules for the second extended website component; The method of claim 7, comprising at least one of the following:

11. 11. The method of claim 10, further comprising applying artificial intelligence and machine learning techniques to analysis of other websites and pages of the WBS and user activity to recommend modification overrides for changing style, behavior and operation of the second extended website component.

12. The said edit is Enabling users of the WBS to create and define override rules for parameterized behavioral elements of extended website components; enabling the user to select a first extended website component; enabling the user to apply an edit request to the selected first extended website component; 10. The method of claim 9, comprising:

Images