JP2024075645A - 仮想ウェブページのプレビュー中におけるデータベースの編集 - Google Patents

仮想ウェブページのプレビュー中におけるデータベースの編集 Download PDF

Info

Publication number
JP2024075645A
JP2024075645A JP2024040504A JP2024040504A JP2024075645A JP 2024075645 A JP2024075645 A JP 2024075645A JP 2024040504 A JP2024040504 A JP 2024040504A JP 2024040504 A JP2024040504 A JP 2024040504A JP 2024075645 A JP2024075645 A JP 2024075645A
Authority
JP
Japan
Prior art keywords
website
web page
code
data
user
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2024040504A
Other languages
English (en)
Inventor
ブルメンフェルド，ユヴァル，エー．
カウフマン，アミット
ワイナー，シェイ
アブラハミ，ヨアヴ
Original Assignee
ウィックス．コム リミテッド．
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ウィックス．コム リミテッド． filed Critical ウィックス．コム リミテッド．
Publication of JP2024075645A publication Critical patent/JP2024075645A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/10—Text processing
    • G06F40/12—Use of codes for handling textual entities
    • G06F40/14—Tree-structured documents
    • G06F40/143—Markup, e.g. Standard Generalized Markup Language [SGML] or Document Type Definition [DTD]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25—Integrating or interfacing systems involving database management systems
    • G06F16/252—Integrating or interfacing systems involving database management systems between a Database Management System and a front-end application
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/951—Indexing; Web crawling techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/955—Retrieval from the web using information identifiers, e.g. uniform resource locators [URL]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/955—Retrieval from the web using information identifiers, e.g. uniform resource locators [URL]
    • G06F16/9558—Details of hyperlinks; Management of linked annotations
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/958—Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/958—Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking
    • G06F16/972—Access to data in other repository systems, e.g. legacy data or dynamic Web page generation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/12—Protecting executable software
    • G06F21/121—Restricting unauthorised execution of programs
    • G06F21/128—Restricting unauthorised execution of programs involving web programs, i.e. using technology especially used in internet, generally interacting with a web browser, e.g. hypertext markup language [HTML], applets, java
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/048—Interaction techniques based on graphical user interfaces [GUI]
    • G06F3/0484—Interaction techniques based on graphical user interfaces [GUI] for the control of specific functions or operations, e.g. selecting or manipulating an object, an image or a displayed text element, setting a parameter value or selecting a range
    • G06F3/0486—Drag-and-drop
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/10—Text processing
    • G06F40/103—Formatting, i.e. changing of presentation of documents
    • G06F40/106—Display of layout of documents; Previewing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/10—Text processing
    • G06F40/166—Editing, e.g. inserting or deleting
    • G06F40/186—Templates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/33—Intelligent editors
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/34—Graphical or visual programming
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
    • G06F9/44526—Plug-ins; Add-ons
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/535—Tracking the activity of the user
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63—Routing a service request depending on the request content or context

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Mining & Analysis (AREA)
  • Computer Hardware Design (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computational Linguistics (AREA)
  • Health & Medical Sciences (AREA)
  • Artificial Intelligence (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • General Health & Medical Sciences (AREA)
  • Technology Law (AREA)
  • Multimedia (AREA)
  • Human Computer Interaction (AREA)
  • Information Transfer Between Computers (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Processing Or Creating Images (AREA)
  • Debugging And Monitoring (AREA)
  • Stored Programmes (AREA)

Abstract

【課題】ウェブサイトの複数のウェブページに投入されるデータセットを含むバックエンドデータベースを更新する方法及びシステムを提供する。【解決手段】方法は、複数のデータ要素をユーザインターフェースを介して受信することと、データ要素のグループをデータベースに格納することと、複数の仮想ウェブページを生成することと、を含む。各仮想ウェブページは、対応する実際のウェブページが稼働する前における、対応する実際のウェブページのプレビューである。方法はまた、複数の仮想ウェブページのうちの個別のページにデータ要素の各グループを表示することと、ユーザが複数の仮想ウェブページからの仮想ウェブページを編集できるように編集ツールを表示することと、仮想ウェブページに対する編集をデータベースのための更新に変換することと、データベースを更新した状態で対応する実際のウェブページを表示できるようにすることと、を含む。【選択図】図２６

Description

関連出願の相互参照
本出願は、２０１７年７月２４日に出願された米国特許仮出願第６２／５３６，４０３号および２０１８年７月２３日に出願された米国特許仮出願第６２／７０２，２７８号の優先権を主張するものであり、同仮出願は共に、その全体が参照により本明細書に組み込まれる。
本出願はまた、一般に以下の出願、すなわち、２０１２年８月２８日に出願された米国特許出願第１３／５９６，１４６号、２０１３年２月２０日に出願された米国特許出願第１３／７７１，１１９号、２０１３年２月２８日に出願された米国特許出願第１３／７７９，７９８号、２０１３年３月６日に出願された米国特許出願第１３／７８６，４８８号、２０１３年８月６日に出願された米国特許出願第１３／９５９，７５９号、２０１６年１１月１日に出願された米国特許出願第１５／３３９，９８４号、２０１３年１０月１５日に出願された米国特許出願第１４／０５３，６１４号、２０１６年８月１１日に出願された米国特許出願第１５／２３３，９８７号、２０１４年２月１０日に出願された米国特許出願第１４／１７６，１６６号、２０１４年３月１３日に出願された米国特許出願第１４／２０７，７６１号、２０１４年９月１１日に出願された米国特許出願第１４／４８３，９８１号、２０１４年１２月４日に出願された米国特許出願第１４／５５９，９４３号、２０１５年２月１１日に出願された米国特許出願第１４／６１９，９０３号、２０１７年９月１８日に出願された米国特許出願第１５／７０６，７８９号、２０１４年３月１３日に出願された米国特許出願第１４／２０７，９３０号、２０１７年７月２３日に出願された米国特許出願第１５／６５７，１５６号、２０１５年４月２９日に出願された米国特許出願第１４／６９９，８２８号、２０１７年７月１９日に出願された米国特許出願第１５／６５３，５６８号、２０１５年１０月２９日に出願された米国特許出願第１４／９２６，００７号、２０１５年２月１１日に出願された米国特許出願第１４／６１９，１４５号、２０１７年９月１９日に出願された米国特許出願第１５／７０８，１６０号、２０１６年５月３１日に出願された米国特許出願第１５／１６８，２９５号、２０１６年６月７日に出願された米国特許出願第１５／１７５，２７２号、２０１６年７月３１日に出願された米国特許出願第１５／２２４，６１６号、２０１６年１０月１３日に出願された米国特許出願第１５／２９２，１７２号、２０１６年７月３１日に出願された米国特許出願第１５／２２４，５７９号、２０１８年６月６日に出願された米国特許出願第１６／０００，９０７号、２０１７年５月２９日に出願された米国特許出願第１５／６０７，５８６号、２０１７年７月２７日に出願された米国特許出願第１５／６６１，３４２号、２０１７年１２月２１日に出願された米国特許出願第１５／８５０，１５１号、２０１８年６月７日に出願された米国特許出願第１６／００２，３５６号、２０１７年１１月２８日に出願された米国特許仮出願第６２／５９１，２９７号、２０１８年２月１日に出願された米国特許仮出願第６２／６２４，８２４号、２０１８年２月４日に出願された米国特許仮出願第６２／６２６，０９３号、および２０１８年２月２５日に出願された米国特許仮出願第６２／６４７，７３６号に関連し、その全体を参照により組み込む。
本開示は、サードパーティによって完全に管理されるシステムで稼働するカスタムバックエンド機能を組み込むインデックス可能なウェブサイトおよびウェブアプリケーションを構築するためのウェブサイト構築システムに関する。例えば、実施形態は、システムのユーザがクライアントとサーバとのやり取りの管理に関与する必要なしに、フロントエンドコンポーネントまたはシステムアクティビティに関連付けられたプログラム可能なイベントがトリガされたときにステートレスサーバ環境（コンテナ、サーバレスコード、また
は仮想マシンなど）で実行され得るカスタムバックエンド機能を開発することを含む。
さらに、本開示は、ウェブサイトまたは個々のウェブページのオンデマンド実行インスタンスを即時に提供することによる、ウェブサイトの負荷のホストおよび管理に関する。インスタンスは、いくつかの実施形態では、仮想マシン、コンテナ、またはサーバレスコード要素としてスピンアップされ得る。より具体的には、本開示は、ウェブサイトを提供する要求に応答する際に著しい遅延なしに、システムでホストされるウェブサイトを提供するインスタンスを自動的に追加および除去するために、ホストされるウェブサイトの負荷およびアクティビティを監視するためのシステムおよび方法に関する。さらに、ホストされるウェブサイトは、汎用コードとウェブサイト固有コードとの組み合わせを含み得る。
またさらに、本開示は、ウェブサイトおよびウェブサイトにリンクされたデータのエンドユーザのための、およびそのエンドユーザによるプロダクション環境で生成されたデータにリアルタイムでアクセス可能なウェブサイトの視覚化およびテストに関する。より具体的には、本開示は、ウェブサイトの開発者または設計者がウェブサイトの機能およびエクスペリエンスをテストするための、ウェブサイトのエンドユーザが通常見るデータへのアクセスの提供に関する。
さらに、本開示は、仮想ウェブページのプレビュー中におけるデータベースの編集に関する。例えば、ユーザはデータベースにデータ要素（例えば、テキスト、グラフィックス、ビデオなど）のグループを格納することができ、１つまたは複数の仮想ウェブページがウェブページのプレビューを表示するために生成され得る。仮想ウェブページの表示中に、ユーザは仮想ウェブページを編集でき、ユーザによる編集がデータベースのための更新に変換され得る。さらに、仮想ウェブページに対応する実際のウェブページのライブビュー中に、データベースに対する更新を表示されたライブビューに反映させることができる。
本明細書で開示されるウェブサイト構築システムは、ソフトウェア開発経験および／またはリソースの限られている人々がカスタマイズされたウェブサイトを開発およびホストできるようにするために使用される。一方、従来のウェブサイト開発システムは、外部サービスに対する呼び出しまたはサーバサイドコードを呼び出す埋め込みコードスニペットを介したバックエンド制御を持たないか制限されているテンプレートフロントエンドＵＩを提供するため、このシステムは、データ操作または他のカスタム機能のオプションを持たないかそれが最小限であるウェブページに制限される。他のシステムでは、完全なバックエンド制御にアクセスするためには、クライアントとサーバとのやり取りのセットアップに最大限に関与することが求められる。
従来のウェブサイト開発システムには、データが投入されるウェブページのレイアウトを作成して、インデックスされ得る複数の動的ページを作成する機能がない。さらに、従来のシステムには、ユーザがウェブページにアクセスしたりウェブページと対話したりする仕方に応じて、ウェブページに異なるコンテンツや機能を異なって含めることができる、ウェブページのためのソフトウェアベースのルータを組み込む機能がない。また従来のシステムには、ウェブサイトのユーザの対話を監視し、それらの対話に関連付けられた以前に登録された機能に基づいて結果の出力を示す機能もない。
従来のマネージドウェブサイトホスティングシステムは、準備ができていて運転可能な状態を維持するために多額の費用およびリソースがかかる専用サーバを使用するか、新しいウェブサイトが要求された場合や要求に応答するのに特定のウェブサイトの負荷が一定の遅延閾値を超えた場合に新しいインスタンスのコールドスタートを用いるかのいずれか
によりウェブサイトへの要求を処理するために使用される。ウェブサイトまたはウェブページの新しいインスタンスをコールドスタートするこのようなプロセスは、大幅な処理遅延および結果として生じるユーザエクスペリエンスにおける待ち時間を伴う。
従来のウェブサイト開発システムはまた、ユーザがページのプレビューを動的に編集できるようにする能力の点でも制限されている。そのようなシステムはまた、プレビューされたページの編集を受信することも、それらの編集をページの全部または一部が基づいているデータベースに対する更新に変換することもできない。その結果、このような従来のシステムを使用することには、より多くのユーザのアクション、より多くの帯域幅、およびより多くの面倒な操作を伴う。
本明細書で開示されるウェブサイトテストシステムは、エンドユーザのエクスペリエンスに支障をきたすことなく、エンドユーザがウェブサイトを使用する現実的なエクスペリエンスを作り出すようにセットアップされ得る。しかしながら、従来のウェブサイトテストシステムでは、エンドユーザがウェブサイトを体験するようにサイトをレビューするための制限付きのプレビューインターフェースが提供されるが、テスト対象のウェブサイトで生成されたデータにはリアルタイムアクセスを提供する方法を持たない。また従来のシステムには、エンドユーザエクスペリエンスに影響を与えることなく、新しいデータを追加したり、サイトに対して生成されたデータを削除したりする機能がない。
従来のウェブサイトホスティングシステムはまた、悪意のあるコード（例えば、マルウェア）を含むプラグイン（例えば、ウェブサイトのフロントエンドまたはバックエンドに組み込まれ得るソフトウェア）に対しても脆弱である。そのようなコードが１人のウェブサイト所有者またはユーザによってアップロードされると、そのようなコードは、ウェブサイトホスティングシステムを介して拡散し、他の所有者またはユーザのウェブサイトに影響を及ぼす可能性がある。従来のウェブサイトホスティングシステムには、アップロードされたプラグインを分離し、システムが共通してホストする他のウェブサイトへの感染を防ぐ機能がない。
したがって、バックエンド機能を管理するためであり、ウェブサイトをさらにカスタマイズできる自由を提供するためであり、サーバのセットアップ、プロビジョニング、またはサーバとクライアントとのやり取りにユーザを関与させることのない、新しいウェブサイト開発システムのための技術的解決策が求められている。ユーザがウェブサイト全体を一からコーディングする必要なしに、カスタマイズされたコーディング機能などにより、カスタマイズされたウェブサイトを構築するための技術ツールをユーザに提供することがさらに求められている。
さらに、ウェブサイトへの要求を著しい遅延なく処理する新しいオンデマンドシステムのための技術的解決策が求められている。このような技術的解決策では、仮想マシン、コンテナ、サーバレスコードなどの仮想コンピューティングリソースを利用する必要がある。さらに、このような解決策では、多くのページまたはサイトに共通する機能と、特定のページまたはサイトに一意の機能と、の両方を含む、高度にカスタマイズされたウェブサイトを可能にするはずである。
またさらに、プロダクションの際に利用可能なデータにリアルタイムでアクセスできる新しいウェブサイトテストシステムのための技術的解決策も求められている。
加えて、アップロードされたプラグインを分離し、共同ホストされたウェブサイトにそれらが感染を広げるのを防ぐための技術的解決策が求められている。そのような技法は、
フロントエンドとバックエンドとの両方のプラグインを分離できる一方で、ウェブサイト所有者およびユーザがそのようなプラグインを依然としてアップロードおよび利用できるようにする必要がある。
本開示の特定の実施形態は、ウェブサイトを構築するためのシステムに関する。本システムは、ウェブサイト構築者が、一元的にホストされるウェブサイトにバックエンド機能を追加できるように構成されたオンラインウェブサイト構築システムを含むことができ、一元的にホストされるウェブサイトは、検索エンジンによりインデックス可能な１つまたは複数のウェブページを含む。オンラインシステムは、ページの編集および動的プレビューにおいて共通のオンラインデータベースを使用できるようにし、共通のオンラインデータベースには、設計者およびユーザが同時にアクセスし得る。本システムは、インデックス可能なウェブページのフロントエンドを構成するためのウェブサイト構築要素のライブラリを格納するように構成されたオンラインデータベースと、特定の動作を実行するように構成された少なくとも１つのプロセッサと、を備え得る。動作は、ユーザのリモートウェブブラウザに第１の命令を送信することであって、第１の命令は、ユーザが、リモートウェブブラウザにより表示可能な統合インターフェースを介して、格納されたライブラリにリモートでアクセスできるようにし、かつユーザが、インデックス可能なウェブページのフロントエンドを構築するための構築要素のうちの選択したものを利用できるようにし、統合インターフェースが、構築要素とインデックス可能なウェブページに関連付けられたカスタマイズされたバックエンド機能との両方へのアクセスをユーザに提供する、ことと、リモートウェブブラウザにより表示可能な統合インターフェースを介して、ユーザが、インデックス可能なウェブページに関連付けられたカスタマイズされたバックエンド機能を提供するユーザ編集可能コードをアクティブ化するためのプログラム可能なイベントを構成できるようにすることと、統合インターフェースを介して、プログラム可能なイベントに関連付けられたカスタマイズされたバックエンド機能を実装するためのユーザ編集可能コードに対するユーザの編集を受信することと、編集されたユーザ編集可能コードを、オンラインデータベースと通信するコード格納システムに格納することと、プログラム可能なイベントに関連付けられたトリガに応答して、カスタマイズされたバックエンド機能を実装するための編集されたユーザ編集可能コードを実行することと、を含み得る。
いくつかの実施形態では、本システムは、編集されたユーザ編集可能コードの実行を引き起こすフックに基づいて、カスタマイズされたバックエンド機能を実装するための編集されたユーザ編集可能コードの実行を含む。
さらに、いくつかの実施形態では、フックは、ウェブフック、データフック、またはデータバインディングルータフックである。
またさらに、いくつかの実施形態では、少なくとも１つのプロセッサが、オンラインデータベースに格納された規則に基づいて、ユーザにより選択されたウェブサイト構築要素に関連付けられたスケルトンコードを自動的に生成するように、またスケルトンコードを有効にするためにスケルトンコードをリモートウェブブラウザに送信するようにさらに構成される。
加えて、いくつかの実施形態では、本システムは、ユーザにより選択されたウェブサイト構築要素に関連付けられた機能と、自動生成されたスケルトンコードの一部としてその機能に関連付けられたコードのスニペットと、を含む。
さらに、いくつかの実施形態では、本システムは、リモートウェブブラウザにより表示可能な統合インターフェースを含み、リモートウェブブラウザは、フロントエンドウェブサイト編集ウィンドウとカスタマイズされたバックエンド編集ウィンドウとを含む。
さらに、いくつかの実施形態では、本システムは、カスタマイズされたバックエンド機能に関連付けられた特定のデータセットを含むデータアクティビティのためのトリガを含む。
またさらに、いくつかの実施形態では、本システムは、インデックス可能なウェブページ上で入力された更新のためのトリガを含む。
加えて、いくつかの実施形態では、本システムは、インデックス可能なウェブページ上のページ遷移のためのトリガを含む。
さらに、いくつかの実施形態では、本システムは、ユーザとインデックス可能なウェブページとの間の規定された対話のためのトリガを含む。
さらに、いくつかの実施形態では、少なくとも１つのプロセッサが、プログラム可能なイベントに関連付けられたトリガに応答して複数のカスタマイズされたバックエンド機能を実装するために、編集されたユーザ編集可能コードを実行するようにさらに構成される。
またさらに、いくつかの実施形態によれば、少なくとも１つのプロセッサが、複数のプログラム可能なイベントに関連付けられた複数のトリガに応答してカスタマイズされたバックエンド機能を実装するために、編集されたユーザ編集可能コードを実行するようにさらに構成される。
さらに、いくつかの実施形態によれば、本システムは、インデックス可能なウェブページに対する到来するクライアントの要求を処理するソフトウェアベースのルータのためのコードを格納するように構成されたコード格納システムを含む。
さらに、いくつかの実施形態では、本システムは、オンラインデータベースとコード格納システムとの両方である格納システムを含む。
特定の実施形態は、カスタマイズされたバックエンド機能を使用してウェブサイトを構築するためのコンピュータ実施方法に関する。本方法は、インデックス可能なウェブページのフロントエンドを構成するためのウェブサイト構築要素のライブラリを格納するように構成されたオンラインデータベースを維持するステップと、ユーザのリモートウェブブラウザに第１の命令を送信するステップであって、第１の命令は、ユーザが、リモートウェブブラウザにより表示可能な統合インターフェースを介して、格納されたライブラリにリモートでアクセスできるようにし、かつユーザが、インデックス可能なウェブページのフロントエンドを構築するための構築要素のうちの選択したものを利用できるようにし、統合インターフェースが、構築要素とインデックス可能なウェブページに関連付けられたカスタマイズされたバックエンド機能の両方へのアクセスをユーザに提供する、ステップと、リモートウェブブラウザにより表示可能な統合インターフェースを介して、インデックス可能なウェブページに関連付けられたカスタマイズされたバックエンド機能を提供するユーザ編集可能コードをアクティブ化するためのプログラム可能なイベントを構成するための仕様をユーザから受信するステップと、統合インターフェースを介して、プログラム可能なイベントに関連付けられたカスタマイズされたバックエンド機能を実装するためのユーザ編集可能コードに対するユーザの編集を受信するステップと、編集されたユーザ編集可能コードを、オンラインデータベースと通信するコード格納システムに格納するステップと、プログラム可能なイベントに関連付けられたトリガに応答して、カスタマイズされたバックエンド機能を実装するための編集されたユーザ編集可能コードを実行するス
テップと、を含み得る。
さらに、いくつかの実施形態では、本方法は、トリガに応答してカスタマイズされたバックエンド機能を実装するための編集されたユーザ編集可能コードの実行において使用するために、オンラインデータベースの外部およびリモートウェブブラウザの外部のデータを取得するステップを含む。
さらに、いくつかの実施形態によれば、本方法は、コードの選択可能なセグメントの形で編集するために、ユーザ編集可能コードの少なくとも一部分へのアクセスをユーザに提供するステップを含む。
またさらに、いくつかの実施形態によれば、本方法は、編集されたユーザ編集可能コードの実行を引き起こすフックに基づいて、カスタマイズされたバックエンド機能を実装するための編集されたユーザ編集可能コードの実行を含む。
加えて、いくつかの実施形態によれば、本方法は、ウェブフック、またはデータフック、またはデータバインディングルータフックのいずれかであるフックを含む。
さらに、いくつかの実施形態によれば、本方法は、オンラインデータベースに格納された規則に基づく少なくとも１つのプロセッサによる、ユーザにより選択されたウェブサイト構築要素に関連付けられたスケルトンコードの生成と、スケルトンコードを有効にするための、スケルトンコードのリモートウェブブラウザへの送信と、を含む。
さらに、いくつかの実施形態によれば、自動的に生成されたスケルトンコードは、ユーザにより選択された構築要素に関連付けられた機能と、その機能に関連付けられたコードのスニペットと、を含む。
さらに、いくつかの実施形態では、本方法は、リモートウェブブラウザにより表示可能な統合インターフェースを提供するステップを含み、リモートウェブブラウザは、フロントエンドウェブサイト編集ウィンドウとカスタマイズされたバックエンド編集ウィンドウとを含む。
またさらに、いくつかの実施形態では、本方法は、カスタマイズされたバックエンド機能に関連付けられた特定のデータセットを含むデータアクティビティのためのトリガを含む。
加えて、いくつかの実施形態では、本方法は、インデックス可能なウェブページ上で入力された更新のためのトリガを含む。
さらに、いくつかの実施形態では、本方法は、ユーザとインデックス可能なウェブページとの間の規定された対話のためのトリガを含む。
特定の実施形態は、ウェブサイトサーバのためのウェブサーバ実行インスタンスのオンデマンド割り当てのためのシステムに関する。本システムは、複数のウェブサイトをホストするための汎用ウェブサイトサーバコードを格納する少なくとも第１の記憶場所と、第１の記憶場所から分離された方式で、複数のウェブサイトのそれぞれに一意のウェブサイト固有コードを格納する少なくとも第２の記憶場所と、を備え得る。本システムは、複数のウェブサーバ実行インスタンスを制御することであって、少なくともいくつかのインスタンスが複数のウェブサイトのうちの少なくとも１つに一意のウェブサイト固有コードを実行し、少なくとも他のウェブサーバ実行インスタンスが、どのウェブサイトにも特定の
一意のコードがない汎用ウェブサイトサーバコードを実行する、ことと、特定のウェブサイトにアクセスする要求を受信することであって、特定のウェブサイトが汎用ウェブサイトサーバコードを含むプラットフォーム上に構築されている、ことと、特定のウェブサイトが複数のウェブサーバ実行インスタンスのうちの１つにより既にホストされているか否かを判定することと、要求された特定のウェブサイトが複数のウェブサーバ実行インスタンスのうちの１つによってまだホストされていないと判定された場合に、汎用ウェブサイトサーバコードを実行する複数のウェブサーバ実行インスタンスのうちの第１のインスタンスに要求を差し向けることと、汎用ウェブサイトサーバコードを実行する複数のウェブサーバ実行インスタンスのうちの第１のインスタンスに、少なくとも１つの第２の記憶場所からの要求されたウェブサイトに一意の追加のウェブサイト固有コードを投入することと、汎用ウェブサイトサーバコードと要求されたウェブサイトに一意の投入されたウェブサイト固有コードとの両方の組み合わせにより、複数のウェブサーバ実行インスタンスのうちの第１のインスタンスを介して要求に応答することと、を含む動作を実行するように構成された少なくとも１つのプロセッサをさらに備え得る。
いくつかの実施形態では、本システムは、複数のウェブサーバ実行インスタンスを含むことができ、複数のウェブサーバ実行インスタンスは、１つまたは複数のコンテナ、仮想マシン、または物理マシンプロセスを含み得る。
さらに、いくつかの実施形態では、要求はＨＴＴＰ要求であり、本システムは、要求がタイムアウトする前に実行される、要求に応答する動作を含む。
またさらに、いくつかの実施形態では、本システムは、要求を受信してから１００ミリ秒以内に実行される、要求に応答する動作を備える。
加えて、いくつかの実施形態では、本システムは、受信および判定する動作を含むＨＴＴＰ要求を処理するためのプロキシサーバを含む。
さらに、いくつかの実施形態では、判定する動作は、特定のウェブサイトが複数のウェブサーバ実行インスタンスのうちの１つによって既にホストされているか否かに関してウェブサーバ実行インスタンスマネージャに問い合わせることをさらに含む。
さらに、いくつかの実施形態では、判定する動作は、ウェブサーバ実行インスタンスマネージャに要求を転送することと、要求が失敗した場合、それに応じて、要求された特定のウェブサイトが複数のウェブサーバ実行インスタンスのうちの１つによって現在ホストされていないと判定することと、をさらに含む。
またさらに、いくつかの実施形態では、判定する動作は、状態テーブルに基づいて、特定のウェブサイトが複数のウェブサーバ実行インスタンスのうちの１つによって既にホストされていることを判定することを含む。
加えて、いくつかの実施形態では、本システムは、プロキシサーバで維持される状態テーブルを含み、複数のウェブサーバ実行インスタンスのうちの１つにより既にホストされているウェブサイトのリストを識別する。
さらに、いくつかの実施形態では、本システムは、非アクティブなウェブサイトに関連付けられた要求の非アクティブの所定の期間に基づいてリストから非アクティブなウェブサイトを除去する状態テーブルを更新する動作を含む。
さらに、いくつかの実施形態では、要求されたウェブサイトに一意の追加のウェブサイ
ト固有コードが、要求されたウェブサイトに一意のバックエンドコードを含む。
またさらに、いくつかの実施形態では、要求されたウェブサイトに一意の追加のウェブサイト固有コードが、要求されたウェブサイトにより参照されるプラグインに関連付けられたコードを含む。
加えて、いくつかの実施形態では、動作は、特定のウェブサイトをまだホストしていない１セットのウェブサーバ実行インスタンスを監視することと、１セットのウェブサーバ実行インスタンスのサイズが閾値よりも小さい場合に、追加のウェブサーバ実行インスタンスをスピンアップするようにウェブサーバ実行インスタンスマネージャに命令することと、をさらに含む。
さらに、いくつかの実施形態では、動作は、特定のウェブサイトをまだホストしていない１セットのウェブサーバ実行インスタンスを監視することと、１セットのウェブサーバ実行インスタンスのサイズが閾値よりも大きい場合に、少なくとも１つのウェブサーバ実行インスタンスをシャットダウンするようにウェブサーバ実行インスタンスマネージャに命令することと、をさらに含む。
本開示の特定の実施形態は、ウェブサイトサーバのためのウェブサーバ実行インスタンスのオンデマンド割り当てのためのコンピュータ実施方法に関する。本方法は、複数のウェブサイトをホストするための汎用ウェブサイトサーバコードを第１の記憶場所に格納するステップと、複数のウェブサイトのそれぞれに一意のウェブサイト固有コードを、第１の記憶場所から分離された第２の記憶場所に格納するステップと、複数のウェブサーバ実行インスタンスを制御するステップであって、少なくともいくつかのインスタンスが複数のウェブサイトのうちの少なくとも１つに一意のウェブサイト固有コードを実行し、少なくとも他のウェブサーバ実行インスタンスが、どのウェブサイトにも特定の一意のコードがない汎用ウェブサイトサーバコードを実行する、ステップと、特定のウェブサイトにアクセスする要求を受信するステップであって、特定のウェブサイトが汎用ウェブサイトサーバコードを含むプラットフォーム上に構築されている、ステップと、特定のウェブサイトが複数のウェブサーバ実行インスタンスのうちの１つによって既にホストされているか否かを判定するステップと、要求された特定のウェブサイトが複数のウェブサーバ実行インスタンスのうちの１つによってまだホストされていないと判定された場合に、汎用ウェブサイトサーバコードを実行する複数のウェブサーバ実行インスタンスのうちの第１のインスタンスに要求を差し向けるステップと、汎用ウェブサイトサーバコードを実行する複数のウェブサーバ実行インスタンスのうちの第１のインスタンスに、少なくとも１つの第２の記憶場所からの要求されたウェブサイトに一意の追加のウェブサイト固有コードを投入するステップと、汎用ウェブサイトサーバコードと要求されたウェブサイトに一意の投入されたウェブサイト固有コードとの両方の組み合わせにより、複数のウェブサーバ実行インスタンスのうちの第１のインスタンスを介して要求に応答するステップと、を含み得る。
いくつかの実施形態によれば、複数のウェブサーバ実行インスタンスは、１つまたは複数のコンテナ、仮想マシン、または物理マシンプロセスを含み得る。
さらに、いくつかの実施形態によれば、要求はＨＴＴＰ要求であり、本方法は、要求がタイムアウトする前に、要求に応答するステップを含む。
またさらに、いくつかの実施形態によれば、本方法は、要求を受信してから１００ミリ秒以内に実行されている要求に応答するステップを含む。
本開示の特定の実施形態は、ウェブサイトサーバのためのウェブサーバ実行インスタンスのオンデマンド割り当てのためのシステムに関する。本システムは、複数のウェブサイトをホストするための汎用ウェブサイトサーバコードおよび複数のウェブサイトのそれぞれに一意のウェブサイト固有コードを格納する少なくとも１つのメモリデバイスと、動作を実行するように構成された少なくとも１つのプロセッサと、を備え得る。動作は、複数のウェブサーバ実行インスタンスを制御することであって、少なくともいくつかのインスタンスが複数のウェブサイトのうちの少なくとも１つに一意のウェブサイト固有コードを実行し、少なくとも他のウェブサーバ実行インスタンスが、どのウェブサイトにも特定の一意のコードがない汎用ウェブサイトサーバコードを実行する、ことと、特定のウェブサイトにアクセスする要求を受信することであって、特定のウェブサイトが汎用ウェブサイトサーバコードを含むプラットフォーム上に構築されている、ことと、特定のウェブサイトが複数のウェブサーバ実行インスタンスのうちの１つによって既にホストされているか否かを判定することと、要求された特定のウェブサイトが複数のウェブサーバ実行インスタンスのうちの１つによってまだホストされていないと判定された場合に、汎用ウェブサイトサーバコードを実行する複数のウェブサーバ実行インスタンスのうちの第１のインスタンスに要求を差し向けることであって、要求が、汎用ウェブサイトサーバコードを実行する複数のウェブサーバ実行インスタンスのうちの第１のインスタンスに対して、少なくとも１つのメモリデバイスからの要求されたウェブサイトに一意の追加のウェブサイト固有コードを取得するように促す、ことと、汎用ウェブサイトサーバコードと要求されたウェブサイトに一意の投入されたウェブサイト固有コードとの両方の組み合わせにより、複数のウェブサーバ実行インスタンスのうちの第１のインスタンスを介して要求に応答することと、を含み得る。
いくつかの実施形態によれば、汎用ウェブサイトサーバコードを実行する複数のウェブサーバ実行インスタンスのうちの第１のインスタンスが、要求に含まれる要求されたウェブサイトの識別子に少なくとも基づいて、少なくとも１つのメモリデバイスからの要求されたウェブサイトに一意の追加のウェブサイト固有コードを取得するように構成される。
特定の実施形態は、非公開ウェブサイトテスト環境でウェブサイトのテストデータを実行しながら、ウェブサイトデプロイ環境でウェブサイトのライブデータを同時に実行するためのシステムに関する。本システムは、ウェブサイトのライブデータおよびウェブサイトのテストデータの両方を格納する少なくとも１つの共通データベースであって、テストデータが少なくとも１つの共通データベースにおいてライブデータと関連付けられる、少なくとも１つの共通データベースと、動作を実行するように構成された少なくとも１つのプロセッサと、を備え得る。動作は、少なくとも１つの共通データベースに格納されたライブデータにアクセスすることと、ウェブサイトデプロイ環境でウェブサイトをレンダリングするために、アクセスしたライブデータを使用することと、ウェブサイトがウェブサイトデプロイ環境で稼働している間に、ウェブサイトでテストを実行する要求を受信することと、少なくとも１つの共通データベースにおいて、要求に応答して１セットのテストデータにアクセスすることであって、１セットのテストデータが、それぞれのライブデータ要素に対応する１つまたは複数のテストデータ要素を含み、１セットのテストデータが、ウェブサイトデプロイ環境においてアクセス可能ではない、ことと、ウェブサイトがウェブサイトデプロイ環境で動作している間に、非公開ウェブサイトテスト環境においてウェブサイトによりテストデータとライブデータとの両方のセットが同時に使用されるように、非公開ウェブサイトテスト環境においてウェブサイトを並行してテストすることと、を含む機能を実行し得る。
いくつかの実施形態によれば、テストデータは、テスト中に、特定のライブデータ要素を特定のテストデータ要素に置き換わらせるように構成されたマーカを使用してライブデータに関連付けられる。
さらに、いくつかの実施形態によれば、マーカはテスト後に削除されるように構成される。
加えて、いくつかの実施形態によれば、マーカは、テスト中に特定のライブデータを無視する命令を指示する。
さらに、いくつかの実施形態によれば、本システムは、複数のユーザによって生成された複数のウェブサイトをホストするためのウェブサイトホスティング環境である。
さらに、いくつかの実施形態によれば、少なくとも１つの共通データベースが、複数のユーザによって生成された複数のウェブサイトに関連付けられたライブデータを格納するように構成された集中オンラインデータベースである。
またさらに、いくつかの実施形態によれば、テストデータは、ウェブサイトのライブデータに以前に関連付けられていなかった新しく追加されたデータを含む。
加えて、いくつかの実施形態によれば、テストデータはウェブサイトデプロイ環境から隠蔽される。
さらに、いくつかの実施形態によれば、本システムは、非公開ウェブサイトテスト環境においてデータを追加する要求に応答してテストデータを含む。
さらに、いくつかの実施形態によれば、テストデータは、ウェブサイトデプロイ環境から隠蔽された少なくとも１つの共通データベースの領域に作成される。
またさらに、いくつかの実施形態によれば、本システムは、それぞれのライブデータ要素の複製に対して実行される要求された変更を指示するデータ要素を含むそれぞれのライブデータ要素に対応するテストデータ要素を含む。
加えて、いくつかの実施形態によれば、本システムは、変更されるように要求されたライブデータ要素のための対応するテストデータ要素の判定と、対応するそれぞれのテストデータ要素が存在する場合、対応するそれぞれのテストデータ要素に対する要求された変更の実行と、を含む。
さらに、いくつかの実施形態によれば、本システムは、非公開ウェブサイトテスト環境で開始されたクエリの受信と、１つまたは複数のライブデータ要素が対応するそれぞれのテストデータ要素に関連付けられていない場合、ライブデータ要素のうちの１つまたは複数によりクエリに応答することと、１つまたは複数のライブデータ要素が対応するそれぞれのテストデータ要素に関連付けられている場合、テストデータ要素のうちの１つまたは複数によりクエリに応答することと、を実行する。
さらに、いくつかの実施形態によれば、少なくとも１つのプロセッサは、テストデータをライブデータにマージし、それにより、ライブデータ要素のうちの１つまたは複数をそれぞれの対応するテストデータ要素で置き換えるようにさらに構成される。
本開示の特定の実施形態は、非公開ウェブサイトテスト環境でウェブサイトのテストデータを実行しながら、ウェブサイトデプロイ環境でウェブサイトのライブデータを同時に実行するためのコンピュータ実施方法に関する。本方法は、ウェブサイトのライブデータおよびウェブサイトのテストデータの両方を格納するステップであって、テストデータが
少なくとも１つの共通データベースにおいてライブデータに関連付けられる、ステップと、少なくとも１つの共通データベースに格納されたライブデータにアクセスするステップと、ウェブサイトデプロイ環境でウェブサイトをレンダリングするために、アクセスしたライブデータを使用するステップと、ウェブサイトがウェブサイトデプロイ環境で稼働している間に、ウェブサイトでテストを実行する要求を受信するステップと、少なくとも１つの共通データベースにおいて、要求に応答して１セットのテストデータにアクセスするステップであって、１セットのテストデータが、それぞれのライブデータ要素に対応する１つまたは複数のテストデータ要素を含み、１セットのテストデータが、ウェブサイトデプロイ環境においてアクセス可能ではない、ステップと、ウェブサイトがウェブサイトデプロイ環境で動作している間に、非公開ウェブサイトテスト環境においてウェブサイトによりテストデータとライブデータとの両方のセットが同時に使用されるように、非公開ウェブサイトテスト環境においてウェブサイトを並行してテストするステップと、を含み得る。
いくつかの実施形態によれば、本方法は、テスト中に、特定のライブデータ要素を特定のテストデータ要素に置き換わらせるように構成されたマーカを使用してライブデータにテストデータを関連付けるステップを含み得る。
さらに、いくつかの実施形態によれば、マーカはテスト後に削除されるように構成される。
またさらに、いくつかの実施形態によれば、マーカは、テスト中に特定の対応するライブデータを無視する命令を指示する。
加えて、いくつかの実施形態によれば、本方法は、複数のユーザによって生成された複数のウェブサイトをホストするためのウェブサイトホスティング環境を提供するように構成されたサーバによって実行される。
さらに、いくつかの実施形態によれば、テストデータは、ウェブサイトデプロイ環境から隠蔽された少なくとも１つの共通データベースの領域に作成される。
本開示の特定の実施形態は、デプロイ環境で視覚的アプリケーションシステムのライブデータを実行しながら、非公開テスト環境で視覚的アプリケーションシステムのテストデータを同時に実行するためのコンピュータベースのシステムに関し、コンピュータベースのシステムが、視覚的アプリケーションシステムのライブデータおよび視覚的アプリケーションシステムのテストデータの両方を格納する少なくとも１つの共通データベースであって、テストデータが少なくとも１つの共通データベースにおいてライブデータに関連付けられる、少なくとも１つの共通データベースと、少なくとも１つのプロセッサであって、少なくとも１つの共通データベースに格納された視覚的アプリケーションシステムのライブデータにアクセスし、デプロイ環境で視覚的アプリケーションシステムのアクセスしたライブデータを使用し、視覚的アプリケーションシステムがデプロイ環境で稼働している間に、視覚的アプリケーションシステムでテストを実行する要求を受信し、少なくとも１つの共通データベースにおいて、要求に応答して１セットのテストデータにアクセスし、１セットのテストデータがそれぞれのライブデータ要素に対応する１つまたは複数のテストデータ要素を含み、１セットのテストデータがデプロイ環境ではアクセス可能ではなく、視覚的アプリケーションシステムがデプロイ環境で稼働している間に、テストデータとライブデータとの両方のセットが非公開テスト環境において視覚的アプリケーションシステムにより同時に使用されるように、非公開テスト環境で視覚的アプリケーションシステムを並行してテストする、ように構成される、少なくとも１つのプロセッサと、を備える。
さらに、いくつかの実施形態によれば、コンピュータベースのシステムは、ウェブサイト開発システムおよびソースコード開発システムのうちの少なくとも１つである。
本開示の特定の実施形態は、少なくとも１つのプロセッサによって実行された場合に、ウェブサイトの複数のウェブページに投入されるデータセットを含むバックエンドデータベースを更新するための特定の命令を少なくとも１つのプロセッサに実行させる命令を含むコンピュータ可読媒体を含む。命令は、複数のデータ要素をユーザインターフェースを介して受信し、データ要素が少なくとも１つのデータ要素の１つまたは複数のグループに編成され、各グループがウェブサイトの個別のウェブページに表示するためのものであり、少なくとも１つのデータ要素のグループをデータベースに格納し、複数の仮想ウェブページを生成し、各仮想ウェブページが、対応する実際のウェブページが稼働する前における対応する実際のウェブページのプレビューであり、対応する実際のウェブページのそれぞれがデータベースを更新するための機能を備えて設計されておらず、複数の仮想ウェブページのうちの個別のページに少なくとも１つのデータ要素の各グループを表示し、ユーザが複数の仮想ウェブページからの仮想ウェブページを編集できるように編集ツールを表示し、仮想ウェブページに対する編集をデータベースのための更新に変換し、データベースに更新を格納し、仮想ウェブページに関連付けられた対応する実際のウェブページのライブビュー中に、プレビュー中に仮想ウェブページに対して更新を行った状態で対応する実際のウェブページを表示できるようにするための動作を実行し得る。
加えて、いくつかの実施形態では、複数の仮想ウェブページのそれぞれが、ユーザインターフェースのエディタインターフェースに関連付けられたフレーム内に表示可能である。
さらなる実施形態では、動作は、複数の仮想ウェブページのそれぞれを個別かつ動的に表示するために、ユーザが複数の仮想ウェブページにわたってナビゲートできるようにするユーザ選択可能機能の表示を含む。
追加の実施形態では、動作は、ユーザが複数の仮想ウェブページからの特定の仮想ウェブページを特定の仮想ウェブページの識別子に基づいて選択できるようにするユーザ選択可能機能の表示を含む。
さらなる実施形態では、特定の仮想ウェブページの識別子が、特定の仮想ウェブページに関連付けられたデータ要素に基づく。
さらに、いくつかの実施形態によれば、動作は、複数の仮想ウェブページのそれぞれに一意のＵＲＬを関連付けることを含む。
追加の実施形態では、複数の仮想ウェブページのそれぞれが、複数の仮想ウェブページのそれぞれの一意のＵＲＬを参照するサイトマップに基づいて生成される。
いくつかの実施形態によれば、編集ツールが、データベースに格納された少なくとも１つのデータ要素のグループに対する編集を受信するように構成される。
さらに、いくつかの実施形態では、編集ツールが、複数の仮想ウェブページの属性に対する編集を受信するように構成される。
追加の実施形態では、編集ツールが、複数の仮想ウェブページを生成するために使用されるコードに対する編集を受信するように構成される。
さらなる実施形態では、編集ツールが、複数の仮想ウェブページを生成するために使用される実際のコードを表すスケルトンコードの複数のセグメントを表示するように、また実際のコードに対する編集に変換されるスケルトンコードに対する編集を受信するように構成される。
さらに、いくつかの実施形態では、データ要素が、外部ソースからユーザインターフェースを介して受信される。
追加の実施形態では、動作は、複数の仮想ウェブページに関連付けられたソフトウェアベースのルータにアクセスすることと、受信したＵＲＬの１つまたは複数のセグメントに基づいて複数の仮想ウェブページのそれぞれの異なるバージョンを生成するように、ソフトウェアベースのルータを構成することと、をさらに含む。
いくつかの実施形態では、少なくとも１つのデータ要素の各グループのサブセットがリピータ機能により編成され、リピータ機能が少なくとも１つのデータ要素の各グループのサブセットの１つまたは複数の表示されたインスタンスを生成する。
さらに、追加の実施形態は、１つまたは複数のインスタンスを含む対応する実際のウェブページのライブビューを含む。
また本明細書では、ウェブサイトの複数のウェブページに投入されるデータセットを含むバックエンドデータベースを更新するためのコンピュータ実施方法も開示される。本方法は、ユーザインターフェースを介して複数のデータ要素を受信するステップであって、データ要素が少なくとも１つのデータ要素の１つまたは複数のグループに編成され、各グループがウェブサイトの個別のウェブページに表示するためのものである、ステップと、少なくとも１つのデータ要素のグループをデータベースに格納するステップと、複数の仮想ウェブページを生成するステップであって、各仮想ウェブページが、対応する実際のウェブページが稼働する前における対応する実際のウェブページのプレビューであり、対応する実際のウェブページのそれぞれがデータベースを更新するための機能を備えて設計されていない、ステップと、複数の仮想ウェブページのうちの個別のページに少なくとも１つのデータ要素の各グループを表示するステップと、ユーザが複数の仮想ウェブページからの仮想ウェブページを編集できるように編集ツールを表示するステップと、仮想ウェブページに対する編集をデータベースのための更新に変換するステップと、データベースに更新を格納するステップと、仮想ウェブページに関連付けられた対応する実際のウェブページのライブビュー中に、プレビュー中に仮想ウェブページに対して更新を行った状態で対応する実際のウェブページを表示できるようにするステップと、を含み得る。
いくつかの実施形態では、複数の仮想ウェブページのそれぞれが、ユーザインターフェースのエディタインターフェースに関連付けられたフレーム内に表示可能である。
さらに、いくつかの実施形態では、本方法は、複数の仮想ウェブページのそれぞれを個別かつ動的に表示するために、ユーザが複数の仮想ウェブページにわたってナビゲートできるようにするユーザ選択可能機能を表示するステップをさらに含む。
追加の実施形態では、本方法は、ユーザが複数の仮想ウェブページからの特定の仮想ウェブページを特定の仮想ウェブページの識別子に基づいて選択できるようにするユーザ選択可能機能を表示するステップをさらに含む。
さらなる実施形態では、特定の仮想ウェブページの識別子が、特定の仮想ウェブページ
に関連付けられたデータ要素に基づく。
さらに、いくつかの実施形態では、本方法は、複数の仮想ウェブページのそれぞれに一意のＵＲＬを関連付けるステップをさらに含む。
追加の実施形態では、複数の仮想ウェブページのそれぞれが、複数の仮想ウェブページのそれぞれの一意のＵＲＬを参照するサイトマップに基づいて生成される。
さらに、いくつかの実施形態では、編集ツールが、データベースに格納された少なくとも１つのデータ要素のグループに対する編集を受信するように構成される。
追加の実施形態によれば、編集ツールが、複数の仮想ウェブページの属性に対する編集を受信するように構成される。
さらなる実施形態では、編集ツールが、複数の仮想ウェブページを生成するために使用されるコードに対する編集を受信するように構成される。
またさらに、いくつかの実施形態では、編集ツールが、複数の仮想ウェブページを生成するために使用される実際のコードを表すスケルトンコードの複数のセグメントを表示するように、また実際のコードに対する編集に変換されるスケルトンコードに対する編集を受信するように構成される。
追加の実施形態では、データ要素が、外部ソースからユーザインターフェースを介して受信される。
追加の開示される実施形態は、ウェブページに投入されるデータセットを含むバックエンドデータベースを更新するためにウェブページを動的に編集できるようにするためのシステムに関する。本システムは、複数のウェブページに表示するための複数のデータ要素を格納するように構成されたオンラインデータベースであって、データ要素が少なくとも１つのデータ要素のうちの１つまたは複数のグループに編成され、各グループがウェブサイトの個別のウェブページに表示するためのものであり、各個別のウェブページがオンラインデータベースを更新するための機能を持たない、オンラインデータベースと、動作を実行するように構成された少なくとも１つのプロセッサと、を備え得る。動作は、少なくとも１つのデータ要素のグループに基づいて生成された第１のウェブページの編集可能なバージョンを表示するインターフェースを提供するための命令をブラウザにリモートで提供し、インターフェースによりユーザが少なくとも１つのデータ要素を編集でき、インターフェースを介して受信した、第１のウェブページの編集可能なバージョンに対する編集を、オンラインデータベースのための更新に変換し、オンラインデータベースに更新を格納し、第１のウェブページのライブビュー中に、第１のウェブページの編集可能なバージョンに対して更新を行った状態で第１のウェブページを表示できるようにし得る。
さらなる実施形態は、ウェブページの複数の個別の編集可能なバージョンを生成する動作を含み、ウェブページの個別の編集可能バージョンはそれぞれ、インターフェースのエディタインターフェースに関連付けられたフレーム内に表示可能である。
本開示の特定の実施形態は、オンラインエディタインターフェースを介して動的ウェブページをプレビューするためのシステムに関する。本システムは、複数のウェブページに表示するための複数のデータ要素を格納するように、またデータ要素を複数のグループに編成できるようにするための第１の命令を格納するように構成されたオンラインデータベースであって、複数のグループのそれぞれが、少なくとも１つのデータ要素を含み、かつ
少なくとも１つの個別のウェブページに関連付けられ、複数のグループのそれぞれがさらに、複数のスクロール可能な仮想ウェブページを構成するために、ブラウザによって実行可能なフロントエンドコードおよびブラウザからリモートのバックエンドサーバによって実行可能なバックエンドコードのうちの少なくとも１つによって利用可能である、オンラインデータベースと、少なくとも１つのプロセッサであって、ブラウザに関連付けられたユーザが、データベースにデータ要素を追加できるように、また追加された各データ要素を複数のグループのうちの少なくとも１つに関連付けできるように、またフロントエンドコードおよびバックエンドコードのうちの少なくとも１つを修正できるようにするためのインターフェースを表示するための第２の命令をブラウザにリモートで提供し、ユーザによる追加されたデータ要素、追加されたデータ要素と複数のグループのうちの少なくとも１つとの関連付け、ならびにフロントエンドコードおよびバックエンドコードのうちの少なくとも１つの修正に基づいて、複数のスクロール可能な仮想ウェブページを生成するための第３の命令を実行し、複数のスクロール可能な仮想ウェブページが、少なくとも１つのプロセッサによって独立して生成され、かつユーザによって独立して編集されるように構成され、対応する最終的なウェブページの生成前に複数のスクロール可能な仮想ウェブページを表示するように構成されたプレビューインターフェースを表示するための第４の命令をブラウザにリモートで提供し、プレビューインターフェースは、ユーザが、少なくとも１つのデータ要素の複数のグループのそれぞれに基づいて、複数のスクロール可能な仮想ウェブページにわたって選択的にスクロールすることができるように、また対応する最終ウェブページが稼働される前に、少なくとも１つのデータ要素のグループが対応する最終ウェブページにどのように表示されるかを視覚化することができるようにする、ように構成された少なくとも１つのプロセッサと、を備え得る。
いくつかの実施形態によれば、本システムは、対応する最終ウェブページのフロントエンドを構築するためのデータ要素のうちの１つに少なくとも１つのウェブサイト構築要素を関連付けるための少なくとも１つの構築要素のうちの選択したものを、ユーザがウェブページテンプレートにドラッグアンドドロップできるようにするために、オンラインエディタインターフェースを表示するための追加の命令をブラウザにリモートで提供し得る。
さらに、いくつかの実施形態によれば、本システムは、複数のグループのそれぞれに関連付けられた対応する最終ウェブページをレンダリングするための調整可能なデータコンポーネントを含むように構成された動的ウェブページテンプレートであるウェブページテンプレートを含む。
またさらに、いくつかの実施形態によれば、本システムは、オンラインエディタインターフェースに関連付けられたフレーム内でブラウザにおいて表示されるように構成されたプレビューインターフェースを含み得る。
加えて、いくつかの実施形態によれば、本システムは、オンラインエディタインターフェースに関連付けられたフレーム内に表示可能な複数のスクロール可能な仮想ウェブページを含み得る。
さらに、いくつかの実施形態によれば、本システムは、ユーザが複数のスクロール可能な仮想ウェブページにわたってスクロールできるようにするユーザ選択可能機能を含むことができるプレビューインターフェースを含み得る。
さらに、いくつかの実施形態によれば、本システムは、それぞれの仮想ウェブページの識別子に基づいて表示するために特定の仮想ウェブページをユーザが選択できるようにするユーザ選択可能機能を含むことができるプレビューインターフェースを含む。
またさらに、いくつかの実施形態によれば、本システムは、データベースに格納されたデータ要素に基づいてそれぞれの仮想ウェブページの識別子を含み得る。
加えて、いくつかの実施形態によれば、本システムは、複数のグループのそれぞれに一意のＵＲＬを関連付けることができる。
さらに、いくつかの実施形態によれば、本システムは、各ウェブページの一意のＵＲＬを参照するサイトマップに基づいて生成され得る複数のスクロール可能な仮想ウェブページを含む。
さらに、いくつかの実施形態によれば、本システムは、複数のリモートユーザの複数のユーザ生成ウェブサイトに関連付けられたデータを格納するように構成された集中オンラインデータベースを含み得るデータベースを含む。
またさらに、いくつかの実施形態によれば、少なくとも１つの個別のウェブページは、検索エンジンによりインデックス可能である。
加えて、いくつかの実施形態によれば、本システムは、ソフトウェアベースのルータの機能を実行するように構成されたフロントエンドコードおよびバックエンドコードのうちの少なくとも１つを含み得る。
さらに、いくつかの実施形態によれば、ソフトウェアベースのルータは、ユーザにより提供される複数の異なる可能なＵＲＬセグメントに基づいて複数の異なる仕方で少なくとも１つの個別のウェブページを構成することができる。
さらに、いくつかの実施形態によれば、本システムは、少なくとも１つの個別のウェブページに関連付けられたフロントエンドコードおよびバックエンドコードのうちの少なくとも１つを含み得る。
またさらに、本システムは、特定のソフトウェアベースのルータに関連付けられたフロントエンドコードおよびバックエンドコードのうちの少なくとも１つを含み得る。
加えて、複数のグループは、複数の別個のウェブページを含むウェブサイトおよびウェブサイトの関連するグループのうちの少なくとも１つに関連付けられ得る。
さらに、いくつかの実施形態によれば、本システムは、リピータ機能によって編成された複数のデータ要素のサブセットを含むことができ、リピータ機能は、複数のデータ要素のサブセットの１つまたは複数の表示インスタンスを生成する。
さらに、いくつかの実施形態によれば、１つまたは複数のインスタンスは、複数のスクロール可能な仮想ウェブページを表示するように構成されたプレビューインターフェースの一部であり得る。
本開示の特定の実施形態は、オンラインエディタインターフェースを介して動的ウェブページをプレビューするためのコンピュータ実施方法に関する。本方法は、複数のウェブページに表示するための複数のデータ要素を格納するステップと、データ要素を複数のグループに編成できるようにするための第１の命令を格納するステップであって、複数のグループのそれぞれが、少なくとも１つのデータ要素を含み、かつ少なくとも１つの個別のウェブページに関連付けられ、複数のグループのそれぞれがさらに、複数のスクロール可能な仮想ウェブページを構成するために、ブラウザによって実行可能なフロントエンドコ
ードおよびブラウザからリモートのバックエンドサーバによって実行可能なバックエンドコードのうちの少なくとも１つによって利用可能である、ステップと、ブラウザに関連付けられたユーザが、データベースにデータ要素を追加できるように、また追加された各データ要素を複数のグループのうちの少なくとも１つに関連付けできるように、またフロントエンドコードおよびバックエンドコードのうちの少なくとも１つを修正できるようにするためのインターフェースを表示するための第２の命令をブラウザにリモートで提供するステップと、ユーザによる追加されたデータ要素、追加されたデータ要素と複数のグループのうちの少なくとも１つとの関連付け、ならびにフロントエンドコードおよびバックエンドコードのうちの少なくとも１つの修正に基づいて、複数のスクロール可能な仮想ウェブページを生成するための第３の命令を実行するステップであって、複数のスクロール可能な仮想ウェブページが、少なくとも１つのプロセッサによって独立して生成され、かつユーザによって独立して編集されるように構成される、ステップと、対応する最終的なウェブページの生成前に複数のスクロール可能な仮想ウェブページを表示するように構成されたプレビューインターフェースを表示するための第４の命令をブラウザにリモートで提供するステップであって、プレビューインターフェースは、ユーザが、少なくとも１つのデータ要素の複数のグループのそれぞれに基づいて、複数のスクロール可能な仮想ウェブページにわたって選択的にスクロールすることができるように、また対応する最終ウェブページが稼働される前に、少なくとも１つのデータ要素のグループが対応する最終ウェブページにどのように表示されるかを視覚化することができるようにする、ステップと、を含み得る。
いくつかの実施形態によれば、本方法は、ウェブページのフロントエンドを構築するためのデータ要素のうちの１つに少なくとも１つのウェブサイト構築要素を関連付けるための少なくとも１つの構築要素のうちの選択したものを、ユーザがウェブページテンプレートにドラッグアンドドロップできるようにするために、オンラインエディタインターフェースを表示するための追加の命令をブラウザにリモートで提供するステップを含む。
さらに、いくつかの実施形態によれば、ウェブページテンプレートが、複数のグループのそれぞれに関連付けられた対応する最終ウェブページをレンダリングするための調整可能なデータコンポーネントを含むように構成された動的ウェブページテンプレートである。
またさらに、いくつかの実施形態によれば、プレビューインターフェースが、オンラインエディタインターフェースに関連付けられたフレーム内でブラウザにおいて表示されるように構成される。
本開示の特定の実施形態は、動的ウェブページ間をナビゲートするためのシステムに関し、本システムは、複数の動的ウェブページ上に表示するための複数のデータ要素を格納するオンラインデータベースを備える。データベースはまた、データ要素を複数のグループに編成できるようにするための第１の命令を格納することができ、複数のグループのそれぞれが、少なくとも１つのデータ要素を含み、かつ複数の動的ウェブページのうちの少なくとも１つに関連付けられ、さらに複数のグループのそれぞれが、複数の動的ウェブページを構成するために、ブラウザにより実行可能なフロントエンドコードおよびブラウザからリモートのバックエンドサーバにより実行可能なバックエンドコードのうちの少なくとも１つによって利用可能であり、複数の動的ウェブページのそれぞれが、独立して生成され、かつ独立して編集されるように構成される。本システムはまた、複数の動的ウェブページのうちの少なくとも１つの一部としてナビゲーションインターフェースを表示するための第２の命令をブラウザにリモートで提供するように構成された少なくとも１つのプロセッサを備えることができ、ナビゲーションインターフェースが、少なくとも１つのデータ要素の複数のグループのそれぞれに基づいて自動的に生成された複数の動的ウェブペ
ージのそれぞれにわたって、ユーザが選択的にナビゲートできるように構成され、ナビゲーションインターフェースが複数の動的ウェブページのネイティブ要素ではない。
さらに、いくつかの実施形態によれば、本システムは、表示された機能を介して動的ウェブページを選択することによりナビゲートすることであり得る複数の動的ウェブページを検索することと、複数のウェブページを順次スクロールすることと、次、前、最初、最後、ブックマークされた、または他の特定のウェブページに直接移動することと、のうちの少なくとも１つを実行し得る。
またさらに、いくつかの実施形態によれば、動的ウェブページは、サイトマップに基づいて判定された順序を有する。
加えて、いくつかの実施形態によれば、本システムは、複数の動的ウェブページの他の態様から分離されたフレーム内でブラウザに表示されるように構成されたナビゲーションインターフェースを含み得る。
本開示の特定の実施形態は、サーバ環境で実施されるウェブサイトをホストするためのシステムに関する。本システムは、複数のユーザにより生成された複数のウェブサイトを共同ホストするように構成された少なくとも１つのホスティングサーバであって、ホスティングサーバが、複数のユーザのそれぞれが複数のユーザのそれぞれにより生成された特定のウェブサイトを選択的に変更できるようにするために、複数のユーザがアクセスできるホストされた共通編集ツールを含み、ホスティングサーバがさらに、複数のユーザのうちの少なくとも一部が、複数のユーザのうちの他のユーザにより生成された共同ホストされる特定のウェブサイトを変更するのを防ぐように構成される、少なくとも１つのホスティングサーバと、複数のユーザのうちの少なくとも１つのサブセットが、複数のユーザのうちの少なくとも１つのサブセットにより生成された共同ホストされた特定のウェブサイトのためのプラグインに関連付けられたプラグインコードをホスティングサーバにアップロードできるようにするための、複数のユーザのうちの少なくとも１つのサブセットによる表示のためのインターフェースを生成するように構成された少なくとも１つのプロセッサであって、少なくとも１つの特定のプラグインのプラグインコードが、クライアントにより実行可能なフロントエンドプラグイン機能コードまたはプラグインサーバで実行可能なバックエンドプラグイン機能コードのうちの少なくとも１つを含む、少なくとも１つのプロセッサと、ユーザがアップロードした格納されたプラグインコードが、複数のユーザにより生成された共同ホストされた特定のウェブサイトと共に共通ドメインで集中的にホストされるように、少なくとも１つの特定のプラグインに関連付けられた、ユーザがアップロードしたプラグインコードを格納するためのメモリであって、少なくとも１つの特定のプラグインの単一インスタンスが、複数の共同ホストされた特定のウェブサイトにより共有される、メモリと、を備えることができ、少なくとも１つのアップロードされたプラグインを共有する複数の共同ホストされた特定のウェブサイトのそれぞれについて、少なくとも１つのプロセッサが、分離メカニズムを使用して、クライアントにおけるフロントエンドプラグイン機能コードの実行またはプラグインサーバにおけるバックエンドプラグイン機能コードの実行のうちの少なくとも１つを安全に可能にするようにさらに構成され、分離メカニズムに基づいて、少なくとも１つのアップロードされたプラグインに含まれる悪意のあるコードが、ホスティングサーバ上で複数の共同ホストされた特定のウェブサイトの他のサイトに影響を及ぼすことを防ぐ。
いくつかの実施形態によれば、本システムに含まれるプラグインサーバとホスティングサーバとは同じサーバである。
さらに、いくつかの実施形態によれば、本システムは、ホスティングサーバとは別個の
プラグインサーバにおけるバックエンドプラグイン機能コードの実行を可能にする分離メカニズムを含み得る。
またさらに、いくつかの実施形態によれば、本システムは、仮想マシンにおけるバックエンドプラグイン機能コードの実行を可能にする分離メカニズムを含み得る。
加えて、いくつかの実施形態によれば、本システムは、ドッカーコンテナにおけるバックエンドプラグイン機能コードの実行を可能にする分離メカニズムを含み得る。
さらに、いくつかの実施形態によれば、本システムは、プラグインサーバにおいて分離されたプロセスを介してバックエンドプラグイン機能コードの実行を含む分離メカニズムを含み得る。
さらに、いくつかの実施形態によれば、本システム本システムは、共同ホストされた特定のウェブサイトの安全なサブ領域におけるフロントエンドプラグイン機能コードの実行を可能にする分離メカニズムを含み得る。
またさらに、いくつかの実施形態によれば、本システムは、共同ホストされた特定のウェブサイトのサブ領域と共同ホストされた特定のウェブサイトの他のサブ領域との間の通信を制御するための安全な通信チャネルを確立し得る。
加えて、いくつかの実施形態によれば、本システムは、共同ホストされた特定のウェブサイトの他の態様に対する少なくとも１つのアップロードされたプラグインのアクセスを制限するために構成される安全な通信チャネルを含み得る。
さらに、いくつかの実施形態によれば、本システムは、少なくとも１つのアップロードされたプラグインと共同ホストされた特定のウェブサイトとのやり取りを制限するように構成可能なアプリケーションプログラミングインターフェースを使用して作成される安全な通信チャネルを含み得る。
さらに、いくつかの実施形態によれば、本システムは、クライアントのブラウザにおいてｉｆｒａｍｅを介してフロントエンドプラグイン機能コードの実行を可能にする分離メカニズムを含むことができ、ｉｆｒａｍｅはフロントエンドプラグイン機能コードの実行のための安全なサンドボックスとして機能するように構成される。
またさらに、いくつかの実施形態によれば、本システムは、クライアントにより実行可能なフロントエンドプラグイン機能コードを、共同ホストされた特定のウェブサイトの別個のウェブページサブ領域に関連付けることができる。
加えて、いくつかの実施形態によれば、本システムは、２つ以上の信頼できるプラグインを共同ホストされた特定のウェブサイトに関連付けることができる。
さらに、いくつかの実施形態によれば、本システムは、少なくとも１つのアップロードされたプラグインが、フロントエンドプラグイン機能コードが実行される共同ホストされた特定のウェブページの少なくとも１つのコンポーネントと通信および制御できるようにすることができる。
さらに、いくつかの実施形態によれば、本システムは、複数のユーザがアクセス可能な共有プラットフォーム上で複数の共同ホストされた特定のウェブサイトを共同ホストし得る。
またさらに、いくつかの実施形態によれば、本システムは、共同ホストされた特定のウェブサイトのウェブページに関連付けられたクッキーから分離された少なくとも１つのアップロードされたプラグインを含み得る。
本開示の特定の実施形態は、サーバ環境に実装されたウェブサイトをホストするためのコンピュータ実施方法に関する。本方法は、ホスティングサーバ上で、複数のユーザにより生成された複数のウェブサイトを共同ホストするステップと、複数のユーザのそれぞれが複数のユーザのそれぞれにより生成された特定のウェブサイトを選択的に変更できるようにするために、共通編集ツールを複数のユーザが利用できるようにするステップと、複数のユーザのうちの少なくとも一部が、複数のユーザのうちの他のユーザにより生成された共同ホストされる特定のウェブサイトを変更することを防止するステップと、複数のユーザのうちの少なくとも１つのサブセットが、複数のユーザのうちの少なくとも１つのサブセットにより生成された共同ホストされた特定のウェブサイトのためのプラグインに関連付けられたプラグインコードをホスティングサーバにアップロードできるようにするための、複数のユーザのうちの少なくとも１つのサブセットによる表示のためのインターフェースを生成するステップであって、少なくとも１つの特定のプラグインのプラグインコードが、クライアントにより実行可能なフロントエンドプラグイン機能コードまたはプラグインサーバで実行可能なバックエンドプラグイン機能コードの少なくとも１つを含む、ステップと、ユーザがアップロードした格納されたプラグインコードが、複数のユーザにより生成された共同ホストされた特定のウェブサイトと共に共通ドメインで集中的にホストされるように、少なくとも１つの特定のプラグインに関連付けられた、ユーザがアップロードしたプラグインコードを格納するステップであって、少なくとも１つの特定のプラグインの単一インスタンスが、複数の共同ホストされた特定のウェブサイトにより共有される、ステップと、少なくとも１つのアップロードされたプラグインを共有する複数の共同ホストされた特定のウェブサイトのそれぞれについて、分離メカニズムを使用して、クライアントにおけるフロントエンドプラグイン機能コードの実行またはプラグインサーバにおけるバックエンドプラグイン機能コードの実行のうちの少なくとも１つを安全に可能にするステップであって、分離メカニズムに基づいて、少なくとも１つのアップロードされたプラグインに含まれる悪意のあるコードが、ホスティングサーバ上で複数の共同ホストされた特定のウェブサイトの他のサイトに影響を及ぼすことを防ぐ、ステップと、を含み得る。
いくつかの実施形態によれば、本方法は、共同ホストされた特定のウェブサイトのウェブページに関連付けられたクッキーから分離された少なくとも１つのアップロードされたプラグインを含み得る。
さらに、いくつかの実施形態によれば、プラグインサーバとホスティングサーバとは同じサーバである。
またさらに、いくつかの実施形態によれば、本方法は、ホスティングサーバとは別個のプラグインサーバにおけるバックエンドプラグイン機能コードの実行を可能にする分離メカニズムを含み得る。
加えて、いくつかの実施形態によれば、本方法は、仮想マシンにおけるバックエンドプラグイン機能コードの実行を可能にする分離メカニズムを含み得る。
さらに、いくつかの実施形態によれば、本方法は、ドッカーコンテナにおけるバックエンドプラグイン機能コードの実行を可能にする分離メカニズムを含み得る。
さらに、いくつかの実施形態によれば、本方法は、プラグインサーバにおいて分離されたプロセスを介してバックエンドプラグイン機能コードの実行を可能にする分離メカニズムを含み得る。
またさらに、いくつかの実施形態によれば、本方法は、クライアントにより実行可能なフロントエンドプラグイン機能コードを含むことができ、フロントエンドプラグイン機能コードがブラウザのｉｆｒａｍｅにユーザインターフェースを生成するように構成される。
上記の一般的な説明および以下の詳細な説明は、例示および説明のためのものに過ぎず、特許請求の範囲に記載される本発明を限定するものではないことを理解されたい。
本明細書に組み込まれ、本明細書の一部を構成する添付の図面は、いくつかの実施形態を例示し、説明と併せて、本開示の原理を説明する働きをする。
図１は、本開示のいくつかの実施形態による、他のシステムおよびコンポーネントとやり取りする例示的なオンラインウェブサイト構築システムを示す図である。
図２は、本開示のいくつかの実施形態による、例示的なオンラインウェブサイト構築システムを示す図である。
図３は、本開示のいくつかの実施形態による、トリガに関連付けられたバックエンドコードの実行へのパスを示す図である。
図４は、本開示のいくつかの実施形態による、バックエンド機能を更新するための例示的なオンラインエディタインターフェースを示す図である。
図５は、本開示のいくつかの実施形態による、開発モードにある例示的な動的ウェブページを示すブロック図である。
図６は、本開示のいくつかの実施形態による、バックエンド機能の開発方法 を示すフローチャートである。
図７は、本開示のいくつかの実施形態による、バックエンドコードの実行をトリガする方法を示すフローチャートである。
図８は、本開示のいくつかの実施形態による、オンデマンドウェブサーバ実行インスタンスシステムのブロック図である。
図９は、本開示のいくつかの実施形態による、様々なオンデマンドウェブサーバ実行インスタンスシステムのコンポーネント間のやり取りの概略図である。
図１０は、本開示のいくつかの実施形態による、ウェブサイトに関して送信されたウェブ要求に応答するための方法を示すフローチャートである。
図１１は、本開示のいくつかの実施形態による、ウェブサイトがホストされているか否かを判定し、ウェブサーバ実行インスタンスを生成しインスタンス化するためのオンデマンドウェブサーバ実行インスタンスシステムの図である。
図１２は、本開示のいくつかの実施形態による、ウェブサーバ実行インスタンス要素のウェブサイトでのインスタンス化を示す図である。
図１３は、本開示のいくつかの実施形態による、ホストされたウェブサイトの負荷監視および使用中のインスタンスの管理を示す図である。
図１４は、本開示のいくつかの実施形態による、ホスティングに利用可能なウェブサーバ実行インスタンスの数の監視を示す図である。
図１５は、本開示のいくつかの実施形態による、例示的なウェブサイトリアルタイムテストシステムを示す図である。
図１６ａは、本開示のいくつかの実施形態による、データ要素へのデプロイ環境アクセスの概略図である。
図１６ｂは、本開示のいくつかの実施形態による、データ要素へのテスト環境アクセスの概略図である。
図１７は、本開示のいくつかの実施形態による、テスト環境におけるライブデータおよびテストデータへのウェブサイトアクセスの図である。
図１８は、本開示のいくつかの実施形態による、ウェブサイトをテストするためのテスト環境で使用されるテストデータの生成を示す図である。
図１９は、本開示のいくつかの実施形態による、デプロイ環境でウェブサイトにアクセスする方法を示すフローチャートである。
図２０は、本開示のいくつかの実施形態による、テスト環境でウェブサイトにアクセスする方法を示すフローチャートである。
図２１は、本開示のいくつかの実施形態による、テスト環境でデータ要求を処理するための方法を示すフローチャートである。
図２２は、本開示のいくつかの実施形態による、テスト環境で読出し要求を処理するための方法を示すフローチャートである。
図２３ａは、本開示のいくつかの実施形態による、テスト環境でデータ要素を更新するための方法のフローチャートである。
図２３ｂは、本開示のいくつかの実施形態による、デプロイ環境でデータ要素を更新するための方法のフローチャートである。
図２３ｃは、本開示のいくつかの実施形態による、テスト環境でデータ要素を追加するための方法のフローチャートである。
図２４は、本開示のいくつかの実施形態による、テスト環境からデータ要素を削除するための方法を示すフローチャートである。
図２５は、本開示のいくつかの実施形態による、テストデータを問い合わせた結果を生成するためのオーバーレイプロセスを示す図である。
図２６は、本開示のいくつかの実施形態による、ウェブサイトのプレビュー中のデータベースの編集に関与するステップを示すフローチャートである。
図２７は、本開示のいくつかの実施形態による、ウェブページの開発およびプレビューのためのシステムの図である。
図２８は、本開示のいくつかの実施形態による、仮想ウェブページのブロック図である。
図２９は、本開示のいくつかの実施形態による、ウェブページの動的リフレッシュのタイムライン表示の図である。
図３０は、本開示のいくつかの実施形態による、動的プレビューシステムのブロック図である。
図３１は、本開示のいくつかの実施形態による、編集中の仮想ウェブページのプレビューを示す図である。
図３２は、本開示のいくつかの実施形態による、データグループとウェブサイトとの間の関係を示す概略図である。
図３３は、本開示のいくつかの実施形態による、仮想ウェブページの生成に関与するコンポーネントを示す概略図である。
図３４は、本開示のいくつかの実施形態による、仮想ウェブページのプレビューに関与するステップを示すフローチャートである。
図３５は、本開示のいくつかの実施形態による、ユーザとウェブサイトホスティングシステムとの対話の概略図である。
図３６は、本開示のいくつかの実施形態による、共同ホストされたウェブサイトへの制御されたアクセスを示す図である。
図３７は、本開示のいくつかの実施形態による、共通ルートの下でプラグインコードを共有する共同ホストされたウェブサイトグループを示す図である。
図３８は、本開示のいくつかの実施形態による、バックエンドプラグインコードの分離された実行環境を示す図である。
図３９は、本開示のいくつかの実施形態による、フロントエンドプラグインコードの制御されたアクセスおよび実行を示す図である。
図４０は、本開示のいくつかの実施形態による、プラグインコードのクライアントサイドの分離した実行を示す図である。
図４１は、本開示のいくつかの実施形態による、ウェブサイトおよびプラグインコードに対するアクセスおよび実行に関与するステップを示すフローチャートである。
図４２は、本開示のいくつかの実施形態による、ウェブページを編集し、データベースコレクションを作成するための例示的なユーザインターフェースを示す図である。
図４３は、本開示のいくつかの実施形態による、ウェブページを編集し、データベースコレクションのためのパーミッションを構成するための例示的なユーザインターフェースを示す図である。
図４４は、本開示のいくつかの実施形態による、ウェブページおよびデータベースコレクションにおけるエントリを編集するための例示的なユーザインターフェースを示す図である。
図４５は、本開示のいくつかの実施形態による、ウェブページを編集し、データベースコレクションからの出力を表示するための例示的なユーザインターフェースを示す図である。
図４６は、本開示のいくつかの実施形態による、ウェブページを編集し、リピータ機能を作成するための例示的なユーザインターフェースを示す図である。
図４７は、本開示のいくつかの実施形態による、ウェブページを編集し、リピータ機能の結果を示すための例示的なユーザインターフェースを示す図である。
以下の詳細な説明では、本開示の例示的な実施形態が十分に理解されるように多くの具体的な細部が説明されている。しかしながら、具体的な細部のすべてがなくとも例示的な実施形態の原理を実践できることを当業者であれば理解するはずである。例示的な実施形態の原理を不明瞭にしないために、周知の方法、手順、およびコンポーネントについては詳細には説明されていない。明示的に述べられていない限り、本明細書で説明される例示的な方法およびプロセスは、特定の順序またはシーケンスにも特定のシステム構成にも制約されない。加えて、記載された実施形態またはその要素のいくつかは、同時に、同じ時点で、または並行して発生または実行され得る。ここで、本開示の実施形態について詳細に述べ、その例を添付の図面に示す。明示的に述べられていない限り、本明細書で使用される送信および受信は、特定の要求に応答しての送信もしくは受信、またはそのような特定の要求なしでの送信もしくは受信を含む広い意味を持つと理解されたい。よって、これらの用語は、送信および受信の能動的な形式と受動的な形式との両方を包含している。
本開示と整合するシステムおよび方法は、カスタマイズされたフロントエンドおよびバックエンド機能を含むウェブサイト構築システムを対象とする。いくつかの実施形態では、ウェブサイト構築システムは、バックエンド機能開発能力のユーザ構成のためのオプションを含み得る。
図１は、本開示のいくつかの実施形態による、ネットワークを介して他のコンポーネントおよびユーザと対話する例示的なシステムを示している。図１に示すように、ウェブサイト構築システム（ＷＢＳ）１００は、ウェブサイトを作成および編集するためのツールであり得るＷＢＳエディタ１１０を含む。ＷＢＳ１００はまた、ＷＢＳコンテンツ管理システム（ＣＭＳ）１２０を含むことができ、ＷＢＳ ＣＭＳ１２０は、ウィジェットおよびウェブサイト、データベース、または類似のデータ格納構造で使用される他のツールと、構築されたウェブサイトまたは開発中のウェブサイトを表すコードまたはデータと、構築されたウェブサイトまたは開発中のウェブサイトを使用して作成、更新、および閲覧されるデータ（例えば、ｅコマースウェブサイトの基礎となっているｅショップの在庫など
）と、のリポジトリであり得る。
ＷＢＳエディタ１１０は、ウェブサイトを構築および編集するためのエディタであり得る。エディタにより、空白のキャンバスから開始して、またはＷＢＳ ＣＭＳ１２０に格納され得る（テンプレートとも総称される）事前に開発されたサイト、サイトセクション、もしくはページに基づいて、ウェブサイトおよびウェブサイトページを構築することができる。ＷＢＳエディタ１１０は、構築中のウェブサイトのページの視覚的レイアウトおよび他の属性を定義することができる。テンプレートは、構築中のウェブサイトに属するウェブページとその初期コンテンツを定義することができる。ＷＢＳエディタ１１０はまた、様々なページ間のナビゲーションを定義することによりサイトの構成を決定するためのＵＩセクションも含み得る。ＷＢＳエディタ１１０は、ユーザが実際のウェブページで表示させたいようにウェブページにコンポーネントを配置できるようにすることにより、ページのレイアウトを定義する。
いくつかの実施形態では、以下でさらに説明するように、ＷＢＳ１００は、仮想マシン、コンテナインスタンス、またはサーバレスコードを介してウェブサイトおよび個々のページをホストすることができる。これらの技法により、ロード時間が短縮され、ユーザの待ち時間が短縮され得る。例えば、ウェブサイトに、実行しなければならないバックエンドまたはフロントエンドコードが組み込まれているか、サイト固有のコンポーネントが含まれている場合、そのようなコードおよびコンポーネントは、ステートレスサーバ実行インスタンスが所与のサイトに関してブラウザ（例えば、ウェブブラウザ１３１）によりなされた要求に最初に関連付けられたときに、ステートレスサーバ実行インスタンスにロードされ得る。次いで、このようなステートレスサーバインスタンスは、同じサイトに関与するさらなるブラウザ要求に再利用され得る。さらに、ＷＢＳ１００が処理される実際の要求に基づいてサーバリソースを使用できるという利点を提供し、このことは、専用のウェブサービス実行インスタンス（サーバ、ＶＭ、またはコンテナなど）およびインフラストラクチャを使用するよりもはるかに効率的である。
構築ツール１２１は、ＷＢＳエディタにより編集されているページ上にレイアウトされたコンポーネントであるウィジェットを含むことができる。いくつかの実施形態では、ウィジェットは、ウェブページを構築するユーザ、他のユーザ、ＷＢＳベンダ自体、またはサードパーティのアプリケーションプロバイダによって開発されたアプリを含み得る。アプリは、ＷＩＸ ＡＰＰ ＭＡＲＫＥＴなどのリポジトリから取得されてもよい。ウィジェットの例としては、単純なウィジェット（テキストフィールド、図形など）または複雑なウィジェット（カレンダー、フォームジェネレータ、画像編集、ビデオ編集、訪問者カウント、ソーシャルメディアの組み込みなど）が挙げられる。
ＷＢＳ ＣＭＳ１２０は、ウェブサイトを構築するためのコンポーネントと構築されたウェブサイトとの両方を格納することができる。いくつかの実施形態では、コンポーネントおよびウェブサイトは別個のＣＭＳシステムで維持される。図１に示すように、構築ツール１２１は、ウィジェットとウェブサイトの容易な構築を支援する他のツールとを含むＷＢＳ ＣＭＳ１２０に格納される。
構築ツール１２１は、ウェブサイトを構築し、ウェブサイトにコンテンツを含めるプロセスを容易にするウェブサイトの構築ブロックである。構築ツール１２１は、タブ、検索バー、ボタン、ギャラリー、スライドデッキなどの上述のようなコンポーネントツールまたはウィジェットと、アライメントツールなどの操作ツールとの両方を含むことができる。構築ツール１２１は、単純なウィジェット（例えば、ボタン、テキストフィールドなど）と複雑なウィジェット（例えば、ギャラリー、カレンダーウィジェットなど）との両方を含むことができ、高度な機能を実行するように構成される。構築ツール１２１は、ウィ
ジェットおよび他のツールを表すコードの抽象化として表すことができる。構築ツール１２１は、システムのすべてのユーザに提供されるパブリックデフォルトツールと、特定のウェブサイトまたはユーザにのみ提供されるプライベートツールと、を含み得る。プライベートツールは、ユーザまたはウェブサイトのためにカスタマイズされたパブリックツールまたは新しいツールを含み得る。プライベートツールは、ウェブサイトを構築するシステムのユーザまたはサードパーティベンダによって作成されてもよい。構築ツール１２１は、異なるユーザグループが構築し、異なるユーザグループが所有する複数のウェブサイト間で共有されてもよい。構築ツール１２１はまた、既存の構築ツール１２１のコードを編集することによりカスタマイズされ得る（例えば、ボタンのスタイルシートを更新して、新しいボタンの新しいスタイルシートを作成する）。カスタム構築ツールは、元の構築ツール１２１と共にシステムエリアデータベース１２２に格納され得る。
ＷＢＳエディタ１１０は、ＷＢＳ ＣＭＳ１２０のシステムエリアデータベース１２２に格納された構築ツール１２１へのリモートアクセスを提供する。構築ツール１２１の選択されたウィジェットのインスタンスは、ユーザがＷＢＳエディタ１１０により編集中のページにウィジェットを配置すると作成され得る。構築ツール１２１から選択されたウィジェットのインスタンスは、ページ内のウィジェットへの参照により作成され得る。構築ツール１２１から選択されたウィジェットのインスタンスはまた、選択されたウィジェットを表すコードを構築中のウェブサイトのウェブページにコピーすることにより作成され得る。
ＷＢＳエディタ１１０は、通常サーバでホストされるソフトウェアであり、その要素の一部または全部が、実行のためにユーザのウェブサイト閲覧デバイス１３０（またはそのウェブブラウザ１３１）にロードされ得る。いくつかの実施形態では、ＷＢＳエディタ１１０は、システムエリアデータベース１２２を構築ツール１２１と共有してもよいし、共通サーバを共有してもよい。それにもかかわらず、他の実施形態では、ＷＢＳエディタ１１０およびシステムエリアデータベース１２２は別々にホストされる。
サイトエリアデータベース１２４は、ＷＢＳエディタ１１０を使用して構築されたウェブサイトを格納する。図示のように、ウェブサイト１２３は、ＷＢＳエディタ１１０を使用して構築され、サイトエリアデータベース１２４に格納されているウェブサイトである。サイトエリアデータベース１２４に格納されているウェブサイト１２３は、ウェブサイト開発デバイス１４０を使用してアクセス、更新、表示され得るコードおよびデータを表すテキストを含み得る。ウェブサイト１２３は、インデックス可能なウェブページ１２５を含む１つまたは複数のウェブページを含み得る。いくつかの実施形態では、例えば、１つまたは複数のインデックス可能なウェブページ１２５はすべて、同じ共通ドメイン（例えば、ｈｔｔｐ：／／ｗｗｗ．ｍｙ－ｓｉｔｅ．ｃｏｍ）、サブドメイン（例えば、ｈｔｔｐ：／／ｍｙ－ｓｉｔｅ．ｗｉｘ．ｃｏｍ／）、またはＵＲＬプレフィックス（例えば、ｈｔｔｐ：／／ｗｗｗ．ｗｉｘ．ｃｏｍ／ｗｉｘｓｉｔｅｓ／ｍｙ－ｓｉｔｅ／）を共有する。インデックス可能なウェブページ１２５は、フロントエンド１２６とバックエンド１２７とを含み得る。インデックス可能なウェブページ１２５は、破線で示すように、フロントエンド１２６およびバックエンド１２７を含むまたは参照する特別なファイルまたはコードを含んでもよいし、フロントエンド１２６およびバックエンド１２７のコレクションの単なる名前であってもよい。フロントエンド１２６は、インスタンス固有の情報（位置、サイズ、属性値など）を含む、構築ツール１２１のインスタンスであり得るウィジェットおよび他のＵＩ要素から構成されてもよく、そのようなインスタンス固有の情報はまた、包含情報（すなわち、どのコンポーネントがどのコンテナ内に含まれているか）を含むこともできる。フロントエンド１２６はまた、（ランタイム中にウィジェットに影響を与える可能性がある）フロントエンド１２６で実行されるコードセグメントなどのコード要素を含むこともできる。フロントエンド１２６は、ページメタデータ、タイトルな
どの他の要素からさらに構成されてもよい。
フロントエンド１２６は、ユーザに常に表示されるインスタンス、デフォルトで表示されるインスタンス、または少なくとも一部の時間に表示されるインスタンスなど、ＷＢＳエディタ１１０を使用して構築されたウェブサイト１２３のインデックス可能なウェブページ１２５に配置された構築ツール１２１のインスタンスを含む。バックエンド１２７は、ユーザがフロントエンド１２６と対話するとき、またはウェブサイト１２３に到来する通信、時間ベースのトリガ、もしくはウェブサイト１２３に接続されたデータベースへの変更などの非対話イベントを通じて、アクティブ化され得る機能を表す。バックエンド１２７は、ウェブサイト開発デバイス１４０およびＷＢＳベンダスタッフデバイス１５０のユーザには、時々しか見られなくても、決して見られなくてもよい。フロントエンド１２６およびバックエンド１２７は、コードまたは構造化データ（例えば、ＸＭＬ、ＪＳＯＮ、ＪＳＯＮ－ＬＤなど）としてサイトエリアデータベース１２４に格納されてもよい。コードは、テキスト形式またはコンパイル済みオブジェクトコードのいずれかで格納され得る。フロントエンド１２６およびバックエンド１２７を表すコードは、同じプログラミング言語または構造化データ形式であってもよい。いくつかの実施形態では、バックエンド１２７を表すコードおよびＦＥ１２６の一部であるコードが、サイトエリアデータベース１２４に保存される前に異なるプログラミング言語に変換される。
いくつかの実施形態では、ウェブサイト１２３のコードおよびデータはデータベースを共有する場合もあれば、別個のデータベースを有する場合もある。いくつかの実施形態では、フロントエンド１２６およびバックエンド１２７を表すコードは、データベーステーブルのプレーンテキストとしてサイトエリアデータベース１２４に格納されてもよい。他の実施形態では、コードはファイルオブジェクトとして格納されてもよく、サイトエリアデータベース１２４にファイルの場所を格納してもよい。いくつかの実施形態では、コードは、サイトエリアデータベース１２４またはファイルの列の単一の場所に格納される。いくつかの実施形態では、コードは複数のファイルに分割されてもよい。
いくつかの実施形態では、インデックス可能なウェブページ１２５は動的ウェブページであり、フロントエンド１２６はテンプレートであり、実際のウェブページではなくてもよい。以下でさらに説明するように、動的ウェブページは、カスタマイズされたバックエンド機能に基づいて外観またはコンテンツを変更するように構成されたウェブページであり得る。以下でさらに説明するカスタマイズされたバックエンド機能の例としては、ウェブページに表示されるデータの更新、ウェブページ上の画像のサイズ変更または変更、ウェブページ上でのビデオコンテンツのレンダリングのトリガなどが挙げられる。いくつかの実施形態では、動的ウェブページのフロントエンド１２６は、様々な動的ウェブページのコンテンツおよび外観を更新するためにデータベーステーブルからのデータに直接バインドされたテンプレートであり得る。
いくつかの実施形態では、ＷＢＳ１００は、図１に示すコンポーネントをより多くまたはより少なく含むことができる。例えば、データベース１２２および１２４は、単一のデータベースであっても別個のデータベースであってもよい。データベースは、分散された１セットのデータベースであってもよい。データベース１２２および１２４の両方は、リレーショナルデータベース、オブジェクト指向データベース、データ言語ファイルリポジトリ（ＸＭＬまたはＪＳＯＮなどの言語用）またはＮｏＳＱＬデータベースとすることができる。さらに、データベース１２２および１２４は、オンプレミスネットワーク（例えば、インターネットにアクセスできるローカルエリアネットワーク）、クラウドベースのネットワーク（例えば、パブリックまたはプライベートクラウドアーキテクチャ）、またはオンプレミスおよびクラウドベースのネットワークのハイブリッドにおいて維持されてもよい。
図１に示すように、ＷＢＳ ＣＭＳ１２０のサイトエリアデータベース１２４に格納されたウェブサイト１２３は、ウェブブラウザ１３１を介してウェブサイト閲覧デバイス１３０（例えば、デスクトップコンピュータ、タブレット、ラップトップ、スマートフォンなど）によりアクセスされ得る。ウェブサイト閲覧デバイス１３０のユーザ（図示せず）は、ネットワーク１６０（例えば、ウェブサイト閲覧デバイス１３０とＷＢＳ１００との間の中間ネットワークを含むインターネット）を介してウェブサイト１２３へのアクセスを要求することができる。ウェブ閲覧デバイス１３０のウェブブラウザ１３１（例えば、ＡＰＰＬＥのＳＡＦＡＲＩ、ＧＯＯＧＬＥのＣＨＲＯＭＥ、ＭＯＺＩＬＬＡのＦＩＲＥＦＯＸ、ＭＩＣＲＯＳＯＦＴのＥＸＰＬＯＲＥＲなど）は、ウェブサイト１２３ならびにウェブサイト１２３を使用して作成および編集されたデータを閲覧するために使用され得る。ウェブサイト開発デバイス１４０は、ＷＢＳエディタ１１０を使用してウェブサイト１２３を構築するために使用され得る。ウェブサイト開発デバイス１４０上のウェブブラウザ１４１は、ウェブサイト１２３を構築するためにＷＢＳエディタ１１０にアクセスする要求を行うために使用され得る。ＷＢＳベンダスタッフデバイス１５０は、ウェブサイト１２３を構築および維持する際にウェブサイト開発デバイス１４０のユーザ（図示せず）のためにカスタマーサポートを提供するために使用され得る。ＷＢＳベンダスタッフデバイス１５０はまた、構築ツール１２１を作成およびカスタマイズするためにサードパーティベンダにより使用され得る。ＷＢＳベンダスタッフデバイス１５０はまた、ＷＢＳ１００自体を構成するために使用されてもよく、例えば、サイト設計者およびユーザのアカウントの管理、上記のサイトまたはページテンプレートの管理（新しいテンプレートの作成または既存のテンプレートの編集）、またはＷＢＳ１００を含む様々な要素を管理するために使用されてもよい。
いくつかの実施形態では、ウェブサイト閲覧デバイス１３０、ウェブサイト開発デバイス１４０、およびＷＢＳベンダスタッフデバイス１５０は、物理的に異なるデバイスであり得る。他の実施形態では、それらは、異なるクレデンシャルおよび／または異なる役割を使用して同じデバイスからアクセスされる異なるビューであり得る。いくつかの実施形態では、ウェブブラウザ１３１、１４１、および１５１は、同じもしくは異なるデバイス上の同じブラウザもしくは異なるブラウザまたは同じブラウザ上の異なるタブであり得る。
ウェブサイト閲覧デバイス１３０、ウェブサイト開発デバイス１４０、およびＷＢＳベンダスタッフデバイス１５０は、ネットワーク１６０を介してウェブサイト１２３にアクセスすることができる。いくつかの実施形態では、ウェブサイト閲覧デバイス１３０、ウェブサイト開発デバイス１４０、およびＷＢＳベンダスタッフデバイス１５０は、モバイルデバイス、ラップトップ、デスクトップコンピュータ、タブレットなどであり得る。
図１に示すように、検索エンジン１７０（例えば、ＧＯＯＧＬＥ、ＹＡＨＯＯ、ＢＩＮＧなど）は、ＷＢＳ１００とやり取りするか否かにかかわらず、ネットワーク１６０を介してサイトエリアデータベース１２４に格納されたウェブサイト１２３のインデックス可能なウェブページ１２５にアクセスすることができる。検索エンジン１７０は、発見しやすいようにウェブサイト１２３のインデックス可能なウェブページ１２５をインデックスし、それによりウェブサイト１２３を閲覧するためにウェブサイト閲覧デバイス１３０を使用するユーザの数を増やすことができる。いくつかの実施形態では、構築ツール１２１はさらに、ユーザが検索エンジン１７０を介してインデックスおよび検索するためにウェブサイト１２３を最適化できるようにする。例えば、構築ツール１２１は、ユーザが特定のインデックス可能なウェブページ１２５のヘッダーに表示されるテキスト、インデックス可能なウェブページ１２５の特定の場所に表示されるテキスト、またはインデックス可能なウェブページ１２５に（例えば、メタデータとして）関連付けられているテキストを
選択できるようにする。
図２は、本開示のいくつかの実施形態による、ＷＢＳ１００の例示的な構造を示している。図２に示すように、ＷＢＳ１００は、図１に関連して上述したように、ウェブサイトの構築およびホスティングの両方のためのコンポーネントを含むサイトエリアデータベース１２４を含む。
いくつかの実施形態では、インデックス可能なウェブページ１２５は、フロントエンド１２６のコンポーネントにデータグループ２１０からのデータが投入され得る動的または仮想ウェブページであり得る。データグループ２１０は、複数のウェブページに関連付けられてもよい。データグループ２１０は、データ要素２１１を含むデータ要素から構成され得る。データ要素２１１は、インデックス可能なウェブページ１２５のフロントエンド１２６で使用される構築ツール１２１の１つまたは複数のコンポーネントに関連付けられ得る。一例として、データグループ２１０は従業員データベースであり、各データ要素２１１が複数のデータフィールド（名前、年齢、部門情報など）を含む従業員レコードであり得る。これらの複数のフィールドが、インデックス可能なウェブページ１２５のフロントエンド１２６における複数の表示されたコンポーネント（表示フィールド）に投入されるために使用され得る。いくつかの実施形態では、データグループ２１０はテーブルの一部としてサイトエリアデータベース１２４に格納され、データ要素２１１はそのテーブルの行である。データグループ２１０に関連付けられたウェブページは、例えば、動的ウェブページであり得る。
データ要素２１０は、ＵＲＬ関連付けＤＢ２２０に関連付けられ得る。ユーザがウェブ閲覧デバイス１３０を使用してＵＲＬを入力することによりウェブサイト１２３のインデックス可能なウェブページ１２５にアクセスすると、ＵＲＬ（またはそのセグメント）は、参照のために、ＵＲＬ関連付けＤＢ２２０に格納されたＵＲＬまたはＵＲＬセグメントと照合され得る。データグループは、ＵＲＬ関連付けＤＢ２２０のＵＲＬまたはＵＲＬセグメントに関連付けられ得る。ＵＲＬ関連付けＤＢ２２０内のＵＲＬまたはＵＲＬセグメントは、関連付けられたインデックス可能なウェブページ１２５を使用して仮想または動的ウェブページを生成する際に使用するデータグループを判定するのに役立ち得る。いくつかの実施形態では、インデックス可能なウェブページ１２５は動的または仮想ウェブページのテンプレートであり、実際のウェブページはＵＲＬ関連付けＤＢ２２０のＵＲＬを使用して判定されたデータグループ２１０のデータを使用して生成される。
データ要素２１０は、ウェブ閲覧デバイス１３０を使用してユーザが入力した、またはウェブサイト１２３のウェブページ１２５にアクセスするために他の仕方で提供されたＵＲＬ（またはＵＲＬセグメント）を分析するソフトウェアベースのルータを使用して判定され得る。ソフトウェアベースのルータによるＵＲＬの分析により、データグループ２１０のデータ要素２１１にアクセスするためのキーが生成され得る。例えば、ｈｔｔｐ：／／ｍｙｓｉｔｅ．ｗｉｘ．ｃｏｍ／ｕｓｅｒｓ／２０というＵＲＬを使用すると、ソフトウェアベースのルータがＵＲＬを分析して、「ｕｓｅｒｓ」というプレフィックスがデータグループに関連付けられ、「２０」というサフィックスがキーであることを判定することができ、その結果、キー値「２０」により識別される「ユーザ」関連データグループ内のデータ要素をルックアップする。本明細書で説明するように、ソフトウェアベースのルータは、ＵＲＬのサフィックスまたはＵＲＬ内のパラメータを分析して、表示するウェブページのバージョンまたはウェブページのコンテンツを判定するように構成され得る。上記のすべては、ユーザが直接入力するのではなく、システムがなんらかの仕方で受信するＵＲＬ（例えば、ウェブサイトの別のページまたはページ関連コードにより自動的に生成されるＵＲＬ）に適用され得る。本システムはまた、複数の並行して定義されたソフトウェアルータもサポートし、ウェブサイト構築システム１００は、受信したＵＲＬの初期分
析を実行して、定義されたソフトウェアルータのどれを使用するかを判定する。そのような分析は、受信したＵＲＬに基づいて、ＵＲＬ関連付けＤＢ２２０に含まれる定義に基づいて、または追加情報または条件（システム環境条件など）に基づいて判定を行うことができる。
第１の命令２４０は、ウェブブラウザ１４１によりアクセスされる１セットの命令であり、プロセッサ２６０を通じて構成可能であり得る。第１の命令２４０は、ウェブブラウザ１４１が、構築ツール１２１を含むツールの格納されたライブラリにリモートでアクセスするのを助ける。オンラインエディタインターフェース２４３は、ウェブブラウザ１４１上のＷＢＳエディタ１１０ソフトウェアの視覚的表現であり得る。オンラインエディタインターフェース２４３は、構築ツール１２１およびインデックス可能なウェブページ１２５の関連するフロントエンド１２６およびバックエンド１２７コードの助けを借りて、インデックス可能なウェブページ１２５のフロントエンド１２６レイアウト実装を作成および編集するために使用される。第１の命令２４０と同様に、追加の命令（例えば、他の命令の中でも第２の命令２５０および第３の命令２６０）もプロセッサ２６０およびウェブブラウザ１４１にアクセス可能であってもよい。
ウェブブラウザ１４１は、ウェブサイト１２３の異なる部分間をナビゲートするためのナビゲーションインターフェース２４２と、ウェブサイト１２３のアクセスされた部分を編集するためのオンラインエディタインターフェース２１３と、を表示することにより、ウェブサイト１２３を構築するために使用される。ＷＢＳ１００内のＷＢＳエディタ１１０を表すコードをウェブブラウザ１４１に送信して、ナビゲーションインターフェース２４２およびオンラインエディタインターフェース２４３を表示することができる。
図３は、本開示のいくつかの実施形態による、トリガに関連付けられたバックエンドコードの実行へのパスを示している。図３に示すように、トリガ３１０により、バックエンド１２７に関連付けられたコードの実行がもたらされ得る。トリガ３１０は、例えば、ウェブサイト１２３のインデックス可能なウェブページ１２５と対話するウェブ閲覧デバイス１３０のユーザが特定のアクション（例えば、マウスまたはタッチパッドのクリック、選択、カーソルのホバー、リロード要求、テキストの入力、マルチメディアコンテンツのアップロードなど）を行ったときに発生し得る。トリガ３１０はまた、非対話イベント中にも発生し得る。例えば、定期的な時間ベースのアクションまたはデータベースの更新により、バックエンド１２７および／またはフロントエンド１２７のコードのトリガおよび実行が発生するのであってもよい。トリガ３１０はカスタマイズ可能であり、多くの異なる形態を取り得る。さらに、バックエンド１２７に関連するコードの実行をもたらす必要がある対話は、プログラム可能なイベント３２０を介して行われてもよい。プログラム可能なイベント３２０は、フロントエンド１２６とバックエンド１２７とをリンクするフックを介して実行するために、バックエンド１２７に制御を渡す。プログラム可能なイベント３２０とバックエンド１２７との間で制御を渡すために使用されるフックの種類は、構成可能であってもよく、トリガ３１０を引き起こした対話の種類または他の種類のイベントに依存する場合もある。プログラム可能なイベント３２０は、他の可能な種類のフックの中でも、データフック３３０、ウェブフック３４０、またはデータバインディングルータフック３５０のうちの１つまたは複数を利用して、バックエンド１２７でコードを実行するためにバックエンド１２７に制御を渡す。
ウェブブラウザ１３１に示されるウェブサイト１２３のインデックス可能なウェブページ１２５上で、ウェブ閲覧デバイス１３０のユーザによりデータ更新が入力されると、データフック３３０が使用されて、プログラム可能なイベント３２０からバックエンド１２７に制御を渡すことができる。例えば、フォームの送信はデータ更新と見なすことができ、データフック３３０が使用されて、バックエンド１２７に制御を渡すことができ、バッ
クエンド１２７はいくつかの実施形態ではデータベースエントリを作成または更新する。同様に、別の例として、ブログまたはソーシャルメディアインターフェースへのテキストの投稿を、データフック３３０に関連付けられたデータ更新とすることができる。データフック３３０はまた、ＡＰＩ呼び出しを介してプログラムでバックエンド１２７に制御を渡すために使用され得る。例えば、定期的な時間ベースのアクショントリガ３１０は、削除または非アクティブとしてマークされる期間よりも古いデータベース内のエントリをもたらし得る。
ウェブフック３４０は、ウェブモジュール機能がインポートされ、フロントエンド１２６の一部であるコードで呼び出されたときに、プログラム可能なイベント３２０からバックエンド１２７に制御を渡すために使用され得る。いくつかの実施形態では、例えば、フロントエンド１２６の一部であるコードはフロントエンドスクリプトと呼ばれ、ウェブ閲覧デバイスのユーザが、ウェブブラウザ１２３に表示されたウェブサイト１２３のインデックス可能なウェブページ１２５のフロントエンド１２６コンポーネントと対話するときに実行される。例えば、ウェブフック３４０は、インデックス可能なウェブページ１２５のユーザが、アプリを利用すること、購入を行うこと、インデックス可能なウェブページ１２５上のコンテンツにサブスクライブすることなどに基づき得る。
データバインディングルータフック３５０は、ウェブ閲覧デバイス１３０のユーザによってウェブブラウザ１３１の特定のＵＲＬにナビゲートすることにより特定の動的ウェブページが要求されたときに、プログラム可能なイベント３２０からバックエンド１２７に制御を渡すために使用され得る。例えば、ウェブブラウザ１３１のアドレスバーにＵＲＬを入力するか、ウェブブラウザ１３１で表示されているウェブサイト１２３のインデックス可能なウェブページ１２５のハイパーリンクをクリックするか、事前に定義されたまたはプログラムで生成されたＵＲＬに自動的にナビゲートする動作を実行することにより、ナビゲートすることができる。データバインディングルータフック３５０は、判定されたデータグループ２１０のデータ要素２１１をバックエンド１２７コードの機能で定義されたウェブページのテンプレートに適用するために、データグループ２１０および実行するバックエンド１２７コード機能を判定するのを助ける。
いくつかの実施形態では、データバインディングルータフック３５０は、ソフトウェアベースのルータと共に機能してもよい。例えば、インデックス可能なウェブページ１２５にアクセスするユーザがインデックス可能なウェブページ１２５のＵＲＬを入力すると、ソフトウェアベースのルータは、インデックス可能なウェブページ１２５に表示するデータを判定することができ、表示する特定のウェブページさえも判定することができる。ルータは、ＵＲＬの最初の部分（またはＵＲＬの別のセグメント）であるプレフィックスに関連付けられ得る。例えば、ｈｔｔｐ：／／ｗｗｗ．ｗｉｘ．ｃｏｍ／ｌａｂｅｌというＵＲＬでは、「ｌａｂｅｌ」がプレフィックスであり得る。さらに、ｈｔｔｐ：／／ｗｗｗ．ｗｉｘ．ｃｏｍ／ｌａｂｅｌ／ｓｕｂ－ｌａｂｅｌというＵＲＬでは、「ｓｕｂ－ｌａｂｅｌ」がサフィックスであり得る。提供されるＵＲＬの特定のセグメント（例えば、プレフィックス、サフィックス、またはパラメータの値）に基づいて、ルータは、いずれかに関連付けられたコンテンツ、またはいずれかに関連付けられた特定のウェブページを表示すべきであることを判定できる。例えば、プレフィックスがルータに関連付けられ、サフィックスが選択されたルータに渡されて、アクセスすべきページまたはページで使用すべきデータを判定できる。ルータはまた、選択したデータおよびテンプレートに基づいて完全な仮想ページまたは動的ページを生成するために使用され得る。このようにして、ウェブサイト１２３のインデックス可能なウェブページ１２５は、このようなウェブページに対するユーザの対話の仕方に基づいて動的にされ、カスタマイズ可能にされ得る。
データバインディングルータフック３５０はまた、ウェブサイト閲覧デバイス１３０上
でのウェブサイト１２３とのユーザ対話に続く内部イベントに基づいて制御を渡すように機能し得る。例えば、データバインディングルータフック３５０は、ユーザがルーティング先のページにアクセスするパーミッションを持っているか否かを確認するために、上記のようにページへのルーティングを判定する前に機能を実行するために登録され得る。データフック３３０は、場合により、同じトリガ３１０に関してデータバインディングルータフック３５０の前または後に実行できる。例えば、ウェブサイト１２３に接続されたデータベースに対してクエリを実行した後に、アクティブではなくなったエントリを除外するためにデータフック３３０が実行される場合がある（例えば、商店のウェブサイトは、データベースクエリ検索結果から販売されなくなった製品をフィルタリングする場合がある）。よって、本システムは、フックの様々な組み合わせの動作、およびフックの相互連鎖をサポートできる。
図４は、本開示のいくつかの実施形態による、ウェブブラウザ１４１を介してウェブ開発デバイス１４０上でアクセスされる開発モードの例示的な動的ウェブページ１２５を示すブロック図である。図４に示すように、オンラインエディタインターフェース２４３は、統合インターフェース４１０およびプレビューインターフェース４２０から構成される。
統合インターフェース４１０は、ウェブサイト１２３のインデックス可能なウェブページ１２５を開発または構築するために使用され得る。上述のように、統合インターフェース４１０は、構築ツール１２１へのアクセスを提供し得る。構築ツール１２１は、ウェブサイト１２３のインデックス可能なウェブページ１２５の編集に役立つ編集ツール４１１を含み得る。いくつかの実施形態では、統合インターフェース４１０は、開発中にウェブブラウザ１４１上に表示される別個のセクションであり得る。他の実施形態では、統合インターフェース４１０は、様々なツールおよびユーザインターフェースセクションの総称であり得る。いくつかの実施形態では、統合インターフェース４１０は、表示されるウェブページの別個のセクションまたはフローティングウィンドウもしくはフレームであり得る。いくつかの実施形態では、統合インターフェース４１０のコンポーネントは、ウェブブラウザ１４１のセクション内に浮くことができる。
フロントエンド１２６およびバックエンド１２７は、編集モードで一緒に、または別々のウィンドウで表示または表現され得る。いくつかの実施形態では、それらは一度に１つだけ表示され得る。また、バックエンド１２７は表示されているウェブページ１２５またはウェブサイト１２３に固有ではない場合があり、その一部または全部がウェブサイトおよび異なるウェブサイトの開発者の間で共有される場合がある。開発者がウェブサイト１２３を保存すると、フロントエンドはフロントエンド１２６の形式で保存され得る。
プレビューインターフェース４２０は、実世界のように、すなわち仮想ウェブページ４２１を表示するウェブ閲覧デバイス１３０のウェブブラウザ１３１に表示されるようにウェブページ１２５を表示することにより、ユーザが構築されているウェブサイト１２３を視覚化するのに役立つ。各仮想ウェブページ４２１は、一意の識別子４２２に関連付けられ得る。いくつかの実施形態では、一意の識別子４２２は、他のＵＲＬ２１０と共にサイトエリアデータベース１２４に格納されたＵＲＬまたはＵＲＬセグメントである。識別子４２２の他の形式も可能である。
図５は、本開示のいくつかの実施形態による、開発モードにある例示的な動的または仮想ウェブページを示すブロック図である。例えば、図４に関連して上述したように、動的または仮想ウェブページは仮想ウェブページ４２１であり得る。
図５に示すように、統合インターフェース４１０は、構築ツール１２１およびインデッ
クス可能なウェブページ１２５を表示する。この例示的な図において、フロントエンド１２６は、ページのコンテンツ（例えば、テキスト、グラフィックス、ウィジェットなど）を視覚的に編集するためにＷＹＳＩＷＹＧエディタを使用して示されている。いくつかの実施形態では、フロントエンド１２６はコードとして直接編集され得る。いくつかの実施形態では、構築ツール１２１は、統合インターフェース４１０内のユーザインターフェースセクションである。さらなる実施形態では、構築ツール１２１は、オンラインエディタインターフェース２４３のメニュー項目によってアクセスされ得る。いくつかの実施形態では、構築ツール１２１から選択された特定のウェブサイト構築ツールは、統合インターフェース４１０のフロントエンド１２６セクションにおいてドラッグアンドドロップされ得る。インデックス可能なウェブページ１２５のフロントエンド１２６は、構築ツール１２１の視覚的な構成を示している。
いくつかの実施形態では、バックエンド１２７は、統合インターフェース４１０内のフローティングウィンドウとして示されている。他の実施形態では、バックエンド１２７は、フロントエンド１２６と同様の別個のセクションであり得る。バックエンド１２７を表すコードは非表示であってもよく、要求されない限り表示されなくてもよい。いくつかの実施形態では、すべてのバックエンド１２７コードが常に表示され、他の実施形態では、構築ツール１２１からの単一要素に関連付けられたバックエンド１２７コードのみが表示される。
ＷＢＳ１００は、構築ツール１２１から要素を選択し、フロントエンド１２６に要素を配置するとスケルトンコードを自動的に生成するように構成されてもよい。バックエンド１２７に示される生成されたスケルトンコードは、例えば、シェル関数５２１およびシェルコード５２２を含み得る。シェル関数５２１およびシェルコード５２２は共に、トリガ３１０によって実行されるコード内のプログラム可能なイベント３２０を表す。いくつかの実施形態では、図示のように、ｂｕｔｔｏｎＣｌｉｃｋというシェル関数５２１は、ボタンをクリックするイベントを表すコードである。ボタンクリックのトリガは、プログラム可能なイベントｂｕｔｔｏｎＣｌｉｃｋをもたらす。
図６は、本開示のいくつかの実施形態による、バックエンド機能１２７の開発方法６００を示すフローチャートである。いくつかの実施形態では、方法６００は、上述のように、ＷＢＳ１００のコンポーネントによって実行され得る。
図６に示すように、ステップ６１０において、ＷＢＳ１００は、ユーザがウェブブラウザ１４１を介してウェブサイト１２３開発に関する要求を行うと、ウェブ開発デバイス１４０のユーザからサイトエリアデータベース１２４の構築ツール１２１にアクセスする要求を受信する。上述のように、構築ツール１２１の例としては、ウィジェット、グラフィックス、および他のコンテンツが挙げられる。
ステップ６２０において、ＷＢＳ１００は、ウェブブラウザ１４１を介したウェブサイト開発デバイス１４０からの要求に応じて第１の命令２４０を送信する。要求は、ネットワーク１６０を介してＷＢＳ１００により受信される。要求はウェブサイトＣＭＳ１２０に転送される。ウェブサイトＣＭＳ１２０は、プロセッサ２６０により要求されると第１の命令２４０へのアクセスを提供し、第１の命令２４０がウェブサイトブラウザ１４１に送信される。第１の命令２３０は、サイトエリアデータベース１２４に格納された構築ツール１２１へのアクセスを提供し、これにより、ウェブページ１２５のフロントエンド１２６およびバックエンド１２７を構築することが可能になる。
ステップ６３０において、ＷＢＳ１００は、ネットワーク１６０を介してウェブサイト開発デバイス１４０から構築ツール１２１内のツールを使用する要求を受信すると、規則
に基づいて構築ツール１２１内の選択されたツールのスケルトンコードを自動的に生成する。例えば、図５に関連して上述したように、スケルトンコードは、マウスクリック、ホバー、コンテンツ選択などのイベントに関連付けられ得る。
ステップ６４０において、ＷＢＳ１００は、ウェブブラウザ１４１に表示するためにウェブサイト開発デバイス１４０にスケルトンコードを送信し得る。
ステップ６５０において、ＷＢＳ１００は、フロントエンド１２６が編集または作成されているウェブページ１２３に関連付けられたカスタマイズされたバックエンド機能１２７へのアクセスを提供し得る。上述のように、バックエンド機能１２７は、様々な異なる形態を取り得て、様々な定義されたイベントに基づいて発生するように構成され得る。
ステップ６６０において、ＷＢＳ１００は、ウェブブラウザ１４１を介してウェブサイト開発デバイス１４０のユーザからの仕様を受信して、カスタマイズされたバックエンド機能１２７をアクティブ化するためのプログラム可能なイベント３２０を構成することができる。
ステップ６７０において、ＷＢＳ１００は、ウェブブラウザ１４１を介してウェブサイト開発デバイス１４０のユーザから、バックエンド機能１２７を実装するユーザ編集可能コードを受信することができる。ユーザは、コードの機能を変更したり、コードを更新したりなどして、コードを編集できる。
ステップ６８０において、ＷＢＳ１００は、ネットワーク１６０を介してウェブサイト開発デバイス１４０から受信した、編集されたユーザ編集可能コードをサイトエリアデータベース１２４に格納することができる。次いで、編集されたユーザ編集可能コードは、デプロイ可能な状態になって、インデックス可能なウェブページ１２５のためにカスタマイズされたバックエンド１２７機能を提供できる。
図７は、本開示のいくつかの実施形態による、バックエンドコード１２７の実行をトリガする方法７００を示すフローチャートである。上述のように、方法７００は方法６００と併せて実行されてもよい。上記の議論と整合して、方法７００はＷＢＳ１００のシステムで実行されてもよい。
図７に示すように、ウェブサイト閲覧デバイス１３０のユーザは、ステップ７１１に示すようにインデックス可能なウェブページ１２５で遷移すること、ステップ７１２に示すようにウェブサイト閲覧デバイス１３０のユーザがインデックス可能なウェブページ１２５と対話した場合、またはステップ７１３に示すようにユーザがインデックス可能なウェブページ１２５に対する更新を入力し、トリガ３１０を引き起こす場合のいずれかにより、バックエンド１２７に関連付けられたプログラム可能なイベント３２０をトリガ３１０することができる。例えば、ステップ７１１は、ユーザが同じウェブサイト１２３の別のウェブページ部分に関連付けられているインデックス可能なウェブページ１２５のネストされたハイパーリンクをクリックすることを含み得る。同様に、ステップ７１１は、ユーザがインデックス可能なウェブページ１２５の「次」または「続行」のハイパーリンクをクリックして、後続の関連ページを閲覧することを含み得る。ステップ７１２は、例えば、ユーザが、インデックス可能なウェブページ１２５上のグラフィックまたはテキスト上にカーソルをホバーすること、所定の期間停止すること、インデックス可能なウェブページ１２５上の画像またはテキストをクリックすることなどを含み得る。ステップ７１３は、ユーザが、インデックス可能なウェブページ１２５上のテキストコンテンツを更新すること、画像またはビデオファイルをインデックス可能なウェブページ１２５にアップロードすること、インデックス可能なウェブページ１２５上のフォームに入力すること、特定
のアクションをもたらす期間タイマー、データベースの更新などを含み得る。
ステップ７２０において、ＷＢＳ１００は、プログラム可能なイベント３２０の通知を受信すると、これに応答して、プログラム可能なイベント３２０に関連付けられたトリガ３１０にアクセスする。上述のように、プログラム可能なイベント３２０は、データフック３３０、ウェブフック３４０、データバインディングルータフック３５０などの様々な種類のフックに基づき得る。プログラム可能なイベント３２０に関連付けられたフックは、サイトエリアデータベース１２４に格納されているウェブサイト１２３の内部データ（例えば、Ｗｉｘデータ）にアクセスすることを含み得る。
ステップ７３０において、ＷＢＳ１００は、場合により、オンラインサイトエリアデータベース１２４およびリモートウェブブラウザ１４１の外部のデータを（例えば、外部データベース、別のウェブサイト、リモートサービスなどから）取得することができる。いくつかの実施形態では、そのようなデータは、プログラム可能なイベント３２０の一部として使用されてもよい。
ステップ７４０において、ＷＢＳ１００は、編集されたユーザ編集可能なバックエンド１２７コードを実行するようにプロセッサ２６０に要求することができる。したがって、プログラム可能なイベント３２０では、カスタマイズされたバックエンド機能がインデックス可能なウェブページ１２５で発生する場合がある。上述のように、このカスタマイズされたバックエンド機能は、ユーザからの入力により、その機能、データソース、およびタイミングの観点から定義され得る。ユーザは、カスタマイズされたバックエンド機能のこれらの属性のそれぞれについて、コードの作成および編集に対するガイド付き制御を与えられ得る（例えば、関数全体を最初からコーディングする必要はないが、代わりにテンプレートまたはコードのサンプルが提供される）。
本開示と整合するシステムおよび方法はまた、ウェブサイトのホスティング、クライアントへのウェブサイトの提供、ウェブサイトの負荷の監視、およびウェブサイトの負荷動態への応答のための機能を含むオンデマンドウェブサイトホスティングシステムを対象としている。いくつかの実施形態では、オンデマンド実行可能インスタンスは、ウェブサイトの使用アクティビティを監視し、一部または全部の実行インスタンスを自動的にスピンアップまたは除去してもよい。さらに、以下で説明するように、ウェブサイトまたはページを提供するためにスピンアップされたウェブサーバ実行インスタンスは、汎用ウェブサイトコードとサイト固有またはページ固有コードとの組み合わせを含むことができ、その結果、高度に調整された個別のウェブサイトおよびページの提供の応答が早く、非常に効率的になる。
一般に、ユーザがウェブサイトと対話するとき、様々なＨＴＴＰ要求を行い得る。例えば、初期のＨＴＴＰ要求がウェブページをロードするために行われ得る（これにより、状況によっては、画像やスクリプトなどの追加のページ要素をロードする追加のＨＴＴＰ要求がトリガされ得る）。加えて、ユーザはセッション中にＨＴＴＰ要求を行うこともできる（例えば、フィールドの値の選択、ハイパーリンクされた画像のクリックなど）。さらに、ユーザは、フォームの送信などを通じて、データ関連のＨＴＴＰ要求を行うことができる。加えて、ユーザはバックエンドＨＴＴＰ要求を行うことができ、これにより、（例えば、本明細書で説明するバックエンドコードを介して）バックエンド機能がアクティブ化され得る。
ページのロードおよびＨＴＴＰ要求の処理のプロセスを高速化するために、本システム（例えば、ＷＢＳ１００）は、特定のウェブサイトまたはページのために構成されたドッカーコンテナまたはサーバレスコードの高速起動を利用するように構成され得る。いくつ
かの実施形態では、本明細書で説明するように、スタンバイコンテナまたは他の仮想コンピューティングリソースのプールには、すべての関連する非サイト固有コードが提供され得るが、ユーザ固有またはサイト固有コードは提供されない。次いで、本システムは、特定のウェブサイトに関するサーバへの要求をライブポートでリッスンし得る。特定のウェブサイトに関連付けられたライブコンテナまたは他の仮想コンピューティングリソースがある場合、本システムはそれに接続し得る。それ以外の場合、本システムは、プールのスタンバイコンテナを使用し、要求されたサイト固有のコンテンツをプールに投入してもよいし、そのようなコンテンツをロードするようにプールに命令してもよい。所与のサイトのサイト固有のコンテンツがロードされると、コンテナは所与のサイトに関連付けられたコンテナのプールに加わる。本明細書で説明するように、投入されたサイトレベルのコンテンツは、実際のサイトページを含んでも含まなくてもよい。そのようなサイトページ情報は、例えば、実際のブラウザ対応ページマテリアル（例えば、ＨＴＭＬ、ＣＳＳ、およびＪａｖａＳｃｒｉｐｔ（登録商標）コードのコレクション）、クライアントサイドもしくはサーバサイドのコード（ＷＢＳビューアモジュールなど）によりブラウザ対応マテリアルに変換される基礎となるサイト定義データ（例えば、ＸＭＬファイルまたはＪＳＯＮ表現を使用する）、またはフロントエンドもしくはバックエンドコード（例えば、クライアント、サーバ、またはその両方で実行するためにページによって呼び出されるＪａｖａＳｃｒｉｐｔコード）であり得る。
図８は、本開示のいくつかの実施形態による、オンデマンドウェブサーバ実行インスタンスシステム８００のブロック図を示している。図８に示すように、オンデマンドシステム８００は、プロセッサ２６０と、現在または最近提供されたウェブサイトを格納するためのメモリ８２０と、提供するために利用可能なすべてのウェブサイトを格納するための永続性記憶装置８３０と、を備える。いくつかの実施形態では、オンデマンドシステム８００はまた、新しいウェブサーバ実行インスタンスがウェブサイト要求を処理する必要があるか否かを判定するのを助けるために、プロキシサーバ８４０を備え得る、またはプロキシサーバ８４０に関連付けられ得る。
ＷＢＳシステム１００およびオンデマンドシステム８００は、ウェブサイトを編集するためにコードを格納し、ウェブ要求を処理するためにコードにアクセスする。ＷＢＳエディタ１１０は、ウェブ開発デバイス１４０から受信した編集要求に関するウェブサイトのウェブページを提示するために使用される。ウェブサーバ実行インスタンスは、ＷＢＳエディタ１１０を使用して作成および編集されたコードおよびページ定義でインスタンス化され、ウェブサイト１２３の編集中および実行時にインデックス可能なウェブページ１２５を閲覧するためにサイトエリアデータベース１２４に格納される。いくつかの実施形態では、オンデマンドシステム８００は、ＷＢＳ１００内のサブシステムであってもよい。いくつかの他の実施形態では、ＷＢＳ１００およびオンデマンドシステム８００は、ウェブサイト１２３のインデックス可能なウェブページ１２５のフロントエンド１２６およびバックエンド１２７へのアクセスを共有してもよい。いくつかの実施形態では、永続性記憶装置８３０は、ＷＢＳ１００のサイトエリアデータベース１２４と同様のデータベースであってもよい。ＷＢＳ１００は、フロントエンド１２６を構造化データ形式で格納することができるが、オンデマンドシステム８００は、フロントエンド１２６を、ウェブ閲覧デバイス１３０のウェブブラウザ１３１によって理解されるコード形式に変換する場合がある。ＷＢＳ８００とは異なり、オンデマンドシステム８００は通常、インデックス可能なウェブページ１２５の格納されたフロントエンド１２６およびバックエンド１２７への読み取り専用アクセスを持つ（ウェブサイトの実行時サービスに使用する場合）。しかし、ＷＢＳエディタ１１０と組み合わせて使用する場合、オンデマンドシステム８００は、ウェブサイト１２５のフロントエンド１２６および／またはバックエンド１２７、ならびにウェブサイト１２５の他のコンポーネントを修正できる。ＷＢＳ１００エディタは、（エディタコードが汎用ウェブサイトサーバコード８２４の一部である状態で）オンデマン
ドシステム８００と連携し得るが、エディタ自体がオンデマンドシステム８００の上位のレイヤとして機能でき、その機能および決定（例えば、到来する要求を処理するための実行インスタンスの割り当て）に直接影響しないことを明確にしておきたい。
プロセッサ２６０は、オンデマンドシステム８００の要素をホストする１つまたは複数のサーバに関連付けられ得る。例えば、プロセッサ２６０は、単一のサーバまたは協調サーバ群（例えば、サーバファーム）に関連付けられてもよい。さらに、いくつかの実施形態では、要素のそれぞれ（例えば、メモリ８２０内の各要素、永続性記憶装置８３０内の各要素、プロキシサーバ８４０など）は、独自のプロセッサ２６０を（例えば、専用サーバの一部として）持つことができる。プロセッサ２６０の数または種類に関係なく、オンデマンドシステム８００に示されている要素のそれぞれは、独立と協調方式との両方で機能することができる。
メモリ８２０は、クライアントにウェブサイトまたはページを提供するための１つまたは複数のウェブサーバ実行インスタンスを有し得る。使用中のインスタンス８２１は、現在またはアクティブにウェブサイトを提供しているウェブサーバ実行インスタンスであり得る。一方、利用可能なインスタンス８２２は、現在特定のウェブサイトをホストしていないがホスト可能である、メモリ８２０で利用可能な１セットのウェブサーバインスタンスであり得る。いくつかの実施形態では、利用可能なインスタンス８２２内のウェブサーバ実行インスタンスの数は一定の数であり得る。いくつかの他の実施形態では、利用可能なインスタンス８２２内のウェブサーバ実行インスタンスの数は変化し、使用中のインスタンス８２１のウェブサーバ実行インスタンスの数に依存し得る。例えば、合計１０，０００個の実行インスタンスがある場合、使用中のインスタンス８２１の増加は、利用可能なインスタンス８２２の減少を意味することができ、その逆も同様である。利用可能なインスタンス８２２内のウェブサーバ実行インスタンスの数はまた、使用中のインスタンス８２１のウェブサーバ実行インスタンスの数の割合とすることもできる。使用中のインスタンス８２１は、いくつかの実施形態では、ウェブサーバ実行インスタンス８２３および現在ウェブサイトを提供している他のインスタンスを識別する一意の識別子を含むデータ構造によって表され得る。いくつかの実施形態では、オンデマンドシステム８００によってホストされるウェブサイトごとに同様のデータ構造を維持することができ、そのようなデータ構造はすべて、使用中のインスタンス８２１を集合的に表す。
ウェブサーバ実行インスタンス８２３は、ウェブサーバの助けを借りてウェブサイトへの要求を処理する使用中のインスタンス８２１のうちの１つであり得る。ウェブサーバ実行インスタンス８２３は、汎用ウェブサイトサーバコード８２４とウェブサイトＮ固有コード８３３とを含み得る。例えば、汎用ウェブサイトサーバコード８２４は、すべてのウェブサーバ実行インスタンスに含まれる共通コードであり得る。例えば、このような共通コードは、基礎となるウェブサーバ実行インスタンスシステム要素（オペレーティングシステム、ウェブサーバ（例えば、Ａｐａｃｈｅ）、データベースサーバなど）を含み得る。いくつかの実施形態では、このような共通コードは、共通外部サービスおよびプラグインと共に、ＷＢＳ１００エディタまたはランタイム環境も含み得る。加えて、いくつかの実施形態では、共通コードは、ライブラリなどの共通ウェブサイトアプリケーションレベルのサーバサイド要素、およびＷＢＳ１００垂直アプリケーションなどの主要な共通項目に関連するコードを含んでもよい。共通コードはまた、特に以下で説明する共同ホストされたウェブサイトの共通コンポーネント（例えば、ギャラリー）の要素を含み得る。上記のすべてについて、汎用コードは、実際のサーバサイド要素（サーバ上で格納および実行され得る）と、クライアントサイド要素（サーバに格納され、ウェブページ要求に応じて実行するＷＢＳ１００ランタイムクライアントにロードされる）と、を含み得る。いくつかの実施形態では、ウェブサイトの異なるグループは、異なる汎用ウェブサイトサーバコード８２４を含み得る。よって、例えば、ウェブサイトの共通所有グループは、共通の汎
用ウェブサイトサーバコード８２４を有し得る。これはまた、例えば、同じ垂直マーケットアプリケーションフレームワーク（例えば、レストランやホテル）に基づいた複数のサイトにも適用され得る。あるいは、異なるウェブサイトが独自の汎用ウェブサイトサーバコード８２４を持っていてもよく、これは、各ウェブサイト内のすべてのウェブページに関連し得る。
ウェブサイトＮ固有コード８３４は、ウェブサーバ実行インスタンス８２３が提供するウェブサイトまたはページに固有のコード（特定のサイトのためにウェブサイト１２６の開発者／設計者１５４０が作成したフロントエンド１２６またはバックエンド１２７コードなど）を含み得る。ウェブサーバ実行インスタンス８２３は、ウェブサーバ（例えば、Ａｐａｃｈｅ、Ｔｏｍｃａｔ、Ｎｇｉｎｘなど）またはＷＢＳ固有サーバを使用して、ウェブサイトＮ固有コード８３４を含むウェブサイトまたはページを提供できる。ウェブサイトＮ固有コード８３４は、例えば、ショッピングカート機能、支払い処理、データベースアクセス、アプリの組み込みまたは実行、ソフトウェアベースのルータ機能など、特定のウェブサイトまたはページに一意の機能を実行するためのコードを含み得る。上記およびここでの説明は、所与のウェブサイトまたはページに関連するウェブサイト固有コード８３４、およびこれに対応して、所与のウェブサイトまたはページを使用するクライアントから到来する要求を処理できるウェブサーバ実行インスタンス８２３に言及する。ただし、オンデマンドシステム８００は、異なるレベルの特定のコード粒度で実装され得る。典型的な粒度レベルは、サイトレベル、すなわち、ウェブサイト固有コード８３４がサイト全体をカバーするレベルとすることができ、これは、ウェブサーバ実行インスタンス８２３の再利用に通常最適なレベルである。しかしながら、本システムは、サイトグループ（よく類似しているサイトのグループ）、サイト全体、サイトセクション（すなわち、１セットのページ）、および単一ページの粒度レベルを使用して実装され得る。サイトグループの場合、上記のように、多数のサイトの共通部分を汎用ウェブサイトサーバコード８２４に含めることもできる。
利用可能なインスタンス８２２のウェブサーバ実行インスタンス８２６は、ウェブサーバ実行インスタンス８２６にウェブサイトＮ固有コード８３３を投入することにより、使用中のインスタンス８２１のウェブサーバ実行インスタンス８２３が提供する同じウェブサイトを提供するために使用され得る。このようにして、ウェブサーバ実行インスタンス８２３は、各ウェブサイトまたはページに関連付けられた一意のウェブサイトＮ固有コード８３４に基づいて、個別のウェブサイトおよびページを生成（および提供）することができる。
永続性記憶装置８３０は、それぞれ第１の記憶場所８３１および第２の記憶場所８３２でオンデマンドシステム８００によってホストされるすべてのウェブサイトに汎用および固有のコードを含み得る。汎用ウェブサイトサーバコード８２４は、例えば、第１の記憶場所８３１において永続性記憶装置８３０に格納され得る。ウェブサイト固有コード８３３および８３４は、第２の記憶場所８３２に格納されてもよく、それぞれウェブサイト１およびＮに固有のコードであってもよい。永続性記憶装置８３０は、様々な実施形態において、分散ファイルシステム、データベース、または他の格納システムであってもよく、クラウドベース（例えば、サービスとしてのストレージ）であってもよい。第１の記憶場所８３１および第２の記憶場所８３２は、同じ格納システムの異なる場所にあってもよいし、永続性記憶装置８３０を一緒に形成する異なる格納システムにあってもよい。いくつかの実施形態では、ウェブサイト固有コード８３３および８３４はそれぞれ、異なる二次記憶場所にあってもよいし、同じ場所にあるが別々にラベル付けされていてもよい。
永続性記憶装置８３０の第１の記憶場所８３１にある汎用ウェブサイトサーバコード８２４は、インスタンスをスピンアップした後、ウェブサーバ実行インスタンス８２３と同
様のウェブサーバ実行インスタンスにコピーされ得る。このようにして、汎用ウェブサイトサーバコード８２４ならびに任意のウェブサイト固有コード８３３～８３４は、共通システム、ウェブフレームワーク、ライブラリ、コンポーネントおよびプラグイン、ならびに個別化された要素を含むウェブサイトまたはページを提供するために組み込まれ得る。
様々な実施形態において、メモリ８２０、永続性記憶装置８３０、およびプロキシサーバ８４０のコンポーネントのそれぞれは、オンプレミスコンピュータネットワーク、クラウドコンピュータネットワーク、または両方のアーキテクチャを含むハイブリッドネットワークを通じて実装されてもよい。クラウドホスティング環境の例としては、ＡＭＡＺＯＮ ＷＥＢ ＳＥＲＶＩＣＥＳ、ＭＩＣＲＯＳＯＦＴ ＡＺＵＲＥ、ＩＢＭ ＣＬＯＵＤなど、およびウェブサイトホスティング会社により維持される独自のクラウドネットワークが挙げることができる。
プロキシサーバ８４０は、１セットの使用中のインスタンス８２１が、ウェブ閲覧デバイス１３０のウェブブラウザ１３１から生成されたウェブサイトに関する要求を処理するために利用可能なウェブサーバ実行インスタンスを含むか否かを判定するのに役立つ。プロキシサーバ８４０は、例えば、メモリ８２０とやり取りすることにより、ウェブサーバ実行インスタンスの可用性を判定する。例えば、メモリ８２０は、利用可能なインスタンス８２２および使用中のインスタンス８２１のリストを維持してもよいし、それらの現在のステータスを判定するためにウェブサーバ実行インスタンス８２３および８２６をポーリングしてもよいし、ウェブサーバ実行インスタンスの可用性に関する他のレポート情報を受信してもよい。いくつかの実施形態では、プロキシサーバ８４０は、特定のウェブサイトまたはページにアクセスする（例えば、クライアントからの）ＨＴＴＰ要求を処理し、特定のウェブサイトまたはページがウェブサーバ実行インスタンス８２３によって既にホストされているか否かを判定してもよい。さらに、いくつかの実施形態では、プロキシサーバ８４０は、利用可能なインスタンス８２２および使用中のインスタンス８２１のステータスを判定する際に使用するための状態テーブル９４１を維持してもよい。そのような状態テーブルは、そのようなリソースと、それらが既にホストしているウェブサイトまたはページとを識別し得る。
図９は、本開示のいくつかの実施形態による、オンデマンドシステム８００のコンポーネント間のやり取りの概略図を示している。図２に示すように、オンデマンドシステム８００のウェブサーバ実行インスタンスマネージャ９５０は、ウェブサーバ実行インスタンス８２３および８２６ならびにプロキシサーバ８４０と通信することによりウェブサーバ実行インスタンスを管理する。いくつかの実施形態では、ウェブサーバ実行インスタンスマネージャ９５０は、新しいウェブサーバ実行インスタンスを利用可能なインスタンス８２２に追加する必要があるか否かを判定し得る。このことは、例えば、ホストされている特定のウェブサイトまたはページに関連するトラフィックが増加した場合に発生し得る。いくつかの実施形態では、増加したトラフィック負荷は、過去にサイトに関して収集された定期的なトラフィック情報から推測される事前知識に基づいて予測され得る。過去のトラフィック情報には、季節的な傾向およびサイトの使用状況が最もアクティブな他の時期を把握し、特定のウェブサイトを提供するウェブサーバ実行インスタンスをより多く自動的に追加できるように収集された、毎月、毎週、毎日、および毎時のトラフィックデータが含まれ得る。いくつかの他の実施形態では、ウェブサーバ実行インスタンスマネージャ９５０は、使用中のインスタンス８２１のインスタンスが非アクティブであるか否かを判定し得る。この状況では、クライアントからウェブサイトまたはページで応答する要求がないにもかかわらず、使用中のインスタンス８２１が動作している、または動作可能であるため、リソースが浪費され得る。よって、以下でさらに説明するように、あらゆる非アクティブな使用中のインスタンス８２１は、非アクティブ化またはシャットダウンされ得る。ウェブサイトのために新しいウェブサーバ実行インスタンスを追加するプロセスと同
様に、以前の使用情報に基づいた上述のような予測を使用して、予想されるトラフィックが少ない場合にインスタンスをシャットダウンできる。ウェブサーバ実行インスタンスマネージャ９５０は、プロキシサーバ８４０に判定を委譲することにより、利用可能なインスタンス８２２セットにより多くのインスタンスを追加する、および／または使用中のインスタンス８２１のインスタンスを非アクティブとしてマークする判定を行うことができる。プロキシサーバ８４０は、上記のように、使用中のインスタンス８２１および利用可能なインスタンス８２２からウェブサーバ実行インスタンスを追加するか除去するかを判定するのに役立つ状態テーブル９４１を含むことができる。状態テーブル９４１は、特定の使用中のインスタンス８２１および利用可能なインスタンス８２２をそれらの現在のステータス、履歴ステータス、または予測される将来のステータスに関連付ける情報を維持し得る。このようなステータス情報は、ホストしている、将来ホストする可能性がある、または過去にホストした特定のウェブサイトまたはページを識別し得る。さらに、状態テーブル８４１は、さらなる情報（例えば、使用中のインスタンス８２１および利用可能なインスタンス８２２がウェブサイトまたはページをホストしている時間、使用中のインスタンス８２１および利用可能なインスタンス８２２が非アクティブである時間など）を含み得る。
図１０は、本開示のいくつかの実施形態による、ウェブサイトに関して送信されたウェブ要求に応答するための方法１０００を示すフローチャートである。図１０の方法１０００は、ウェブ閲覧デバイス１３０のウェブブラウザ１３１から到来し、オンデマンドシステム８００により受信されたウェブ要求を処理するための２つの経路を特定する。要求を処理するためのセットアップ要件により、要求されたウェブサイト固有コードが、特定のウェブサイトにアクセスする要求を処理するウェブサーバ実行インスタンスにコピーされることになり得る。
図１０に示すように、ステップ１０１０において、オンデマンドシステム８００は、永続性記憶装置８３０の第１の記憶場所８３１に汎用ウェブサイトサーバコード８２４を格納する。上述のように、これは、ウェブサイトのグループに共通のコード（例えば、共通の所有者が所有するものすべて、または共通の垂直サイトフレームワークに基づくもの）またはウェブサイト内のページのグループに共通のコードを格納することを含み得る。さらに、汎用ウェブサイトサーバコード８２４は、ウェブサイトまたはページの定義された任意のグループに関連付けられ得る。上述のように、汎用ウェブサイトサーバコード８２４は、オペレーティングシステム、ウェブフレームワーク、ソフトウェアライブラリ、ならびにウェブサイトコンポーネントおよびプラグインと、ＷＢＳ１００独自のエディタおよびビューアコードと、を含む、異なるソフトウェアレイヤの共通部分を指定するコードを含み得る。
ステップ１０２０において、オンデマンドシステム８００は、永続性記憶装置８３０の第２の記憶場所８３２にウェブサイトＮ固有コード８３４を格納し得る。上述のように、ウェブサイトＮ固有コード８３４は特定のウェブサイトまたはウェブページに固有のものであり得る。ウェブサイトＮ固有コード８３４は、例えば、ウィジェット、アプリ、またはカスタムバックエンドもしくはフロントエンド機能を含み得る。さらに、ウェブサイトＮ固有コード８３３は、上述のように特定のウェブサイトまたはページのルータなどとして機能することができ、ユーザにより入力された、または他の仕方で提供されたＵＲＬからの１つまたは複数のセグメントが、ウェブサイトまたはページでのそのコンテンツの組み立て方を判定する（例えば、カスタムイメージ、テキスト、ハイパーリンク、フォーム、ｅコマース機能、パーソナル化されたコンテンツなど）。
ステップ１０３０において、オンデマンドシステム８００は、ウェブ閲覧デバイス１３０上のウェブブラウザ１３１から受信した、ウェブサイトにアクセスする要求を受信し得
る。オンデマンドシステム８００は、要求されているウェブサイトまたはページが、使用中のインスタンス８２１の１つまたは複数のウェブサーバ実行インスタンスによって現在処理されているか否かを確認することにより、要求を処理する。上述のように、これは、使用中のインスタンス８２１自体の問い合わせ、プロキシサーバ８４０の問い合わせ、または使用中のインスタンス８２１を監視する別のサービスからのレポートの取得を含み得る。ルックアップテーブルまたは状態テーブルを参照することにより、使用中のインスタンス８２１の現在の動作（またはその欠如）を確認することもできる。いくつかの実施形態では、単一のサーバが複数のウェブサイトまたは同じサイトの複数のクライアントにサービスを提供し、特定のサーバへのトラフィック負荷およびアクティビティが追跡され、追加の要求に応答するために使用するサーバを判定する際に考慮される。
ステップ１０４０において、オンデマンドシステム８００は、ウェブサーバ実行インスタンス８２３または使用中のインスタンス８２１内の他のウェブサーバ実行インスタンスが、要求されたウェブサイトを提供するか否かを確認する。「はい」である場合、プロセス１０００は、いくつかの実施形態では、以下で説明するステップ１０７０にジャンプし得る。
ステップ１０４０の答えが「いいえ」である場合、プロセス１０００はステップ１０５０に進むことができる。使用中のインスタンス８２１のウェブサーバ実行インスタンスのいずれも要求されたウェブサイトを提供しない場合、要求は利用可能なインスタンス８２２の利用可能なウェブサーバ実行インスタンスに転送され得る。いくつかの実施形態では、利用可能なインスタンス８２２内のウェブサーバ実行インスタンスのうちの１つが、要求されたウェブサイトを提供するために選択され得る。他の実施形態では、図１０に示すように、利用可能なインスタンス８２２のウェブサーバ実行インスタンス８２６は、サービス提供の要求を受信する。
ステップ１０６０において、要求は、要求されたウェブサイトに整合する二次記憶場所８３２内のウェブサイト固有コード８３３をルックアップするために送信され得る。例えば、図示のように、ウェブサイト１に関する要求を受信した場合、ウェブサイト１２３固有コード８３３は整合するコードである。いくつかの実施形態では、要求されたウェブサイトに整合するウェブサイト固有コード８３３が識別され、ウェブサーバ実行インスタンス８２６にコピーされる。ウェブサーバ実行インスタンス８２６は、（例えば、状態テーブルまたはプロキシサーバ８４０において）使用中のインスタンス８２１のリストに追加され、利用可能なインスタンス８２２のリストから除去される。要求は、ウェブサーバ実行インスタンス８２６によって（例えば、クライアントに対して）応答される。次いで、プロセス１０００は繰り返すことができる（例えば、ステップ１０１０、１０２０、または１０３０まで繰り返す）。さらに、ステップ１０６０において、ウェブサイト固有コード８３３は、上述のように、ユーザにより要求された特定のウェブサイトまたはページの構築へ組み込むために、ウェブサーバ実行インスタンス８２６に投入され得る。
図１１は、本開示のいくつかの実施形態による、ウェブサイトがホストされているか否かを判定するように、また実行インスタンスを生成またはインスタンス化するように構成されたオンデマンドシステム８００の図である。図１１に示すように、プロキシサーバ８４０は、ウェブ閲覧デバイス１３０のウェブブラウザ１３１からネットワーク１６０を介して受信されたウェブサイト１２３にアクセスする要求を処理するステップを判定するために使用される。そのような判定は、要求を処理する前に、要求されたウェブサイト固有コードを使用して、ウェブサーバ実行インスタンスマネージャ９５０による要求の即時処理、または利用可能なインスタンス８２２内のウェブサーバ実行インスタンスのインスタンス化をもたらし得る。
図１１に示すように、ステップ１１１０において、オンデマンドシステム８００は、ネットワーク１６０を介してウェブサイト１２３に関する要求を受信することができる。上述のように、要求はクライアントコンピュータまたはアプリケーションから到来し得る。要求は、ＨＴＴＰ要求、ＨＴＴＰＳ要求、または別の種類のネットワーク要求であり得る。
ステップ１１２０において、オンデマンドシステム８００は、要求されたウェブサイト１２３の最適な提供の仕方を判定する。上述のように、判定は、現在の１セットの使用中のインスタンス８２１によって要求を処理できるか、または追加のウェブサーバ実行インスタンスが必要かを識別することを含み得る。例えば、オンデマンドシステム８００は、使用中のインスタンス８２１の現在の負荷が使用量の閾値（例えば、インスタンス数の閾値、使用帯域幅の量、使用帯域幅の割合、メモリやプロセッサの電力などのサーバリソースの使用レベルなど）を過ぎたと判定し得る。その場合、特定のウェブサイトまたはページの需要を満たすために、１つまたは複数の利用可能なインスタンス８２２をスピンアップまたは利用する必要があると判定され得る。さらに、上述のように、オンデマンドシステム８００は、使用中のインスタンス８２１の将来の負荷状態の予測を試みることができる。そのような予測は、例えば、以前の負荷レベルに基づいて行うことができる。使用中のインスタンス８２１の予測負荷レベルに基づいて、オンデマンドシステム８００は、同様に、特定のウェブサイトグループ、ウェブサイト、ページセット、またはページの予測された需要を満たすために、１つまたは複数の利用可能なインスタンス８２２をスピンアップまたは利用する必要があると判定し得る。オンデマンドシステム８００はまた、（応答時間を最適にするために）そのような到来する要求を使用中のインスタンス８２１のうちの１つに差し向け、また並行して、１つまたは複数の利用可能なインスタンス８２２が所与のウェブサイトまたはページに関連する将来の要求で利用され得るようにするために、１つまたは複数の利用可能なインスタンス８２２をスピンアップするように決定し得る。
ステップ１１２１において、判定プロセスの一部として、オンデマンドシステム８００は、ウェブサイト１２３に関する要求（例えば、要求のコピー、または要求に関する情報）と共に、ウェブサーバ実行インスタンスマネージャ９５０に制御を渡すことができる。要求は、ウェブサイト１２３のインデックス可能なウェブページにアクセスする要求、フォームの送信、または他の様々な種類の要求であり得る。
ステップ１１２２において、ウェブサーバ実行インスタンスマネージャ９５０は、ウェブサイト１２３を提供する要求をどのように処理するかを判定するのを助けるために、プロキシサーバ８４０に判定を委譲することができる。これには、ウェブサイト１２３に関連付けられた現在の負荷ステータスの判定、ウェブサイトの将来の負荷の予測などを含む、上記の種類の意思決定が含まれ得る。
ステップ１１２３において、プロキシサーバ８４０は、要求されたウェブサイトを提供し得る使用中のインスタンス８２１のインスタンスについて、プロキシサーバ８４０の状態テーブル９４１を参照することができる。いくつかの実施形態では、状態テーブル９４１のルックアップは、整合するウェブサイトＵＲＬについてテーブル内の「ウェブサイト」１１４３と呼ばれる列を調べることを含み得る。他の識別子（例えば、ＵＲＬ、アカウント名、任意の名前など）も可能である。いくつかの実施形態では、オンデマンドシステム８００はウェブサイトのトラフィック傾向履歴に基づいて負荷レベルを定期的に監視することができ、現在のトラフィック傾向が別段を示唆する場合を除き、ウェブサーバ実行インスタンスを自動的にスピンアップまたはシャットダウンすることができるため、オンデマンドシステム８００がウェブサイトの提供要求を受信しなかった場合でも、ステップ１１２２が定期的に発生する。いくつかの実施形態では、ウェブサーバ実行インスタンス
マネージャ９５０は、要求の処理に失敗した後、ウェブサイト１２３に関する要求を転送して、ウェブサイト１２３に関する要求を処理するウェブサーバ実行インスタンスが利用可能でないことを指示する。
ステップ１１２３において、プロキシサーバ８４０は、利用可能なインスタンス８２２のウェブサーバ実行インスタンスに要求を送信して、ウェブサイト１２３に関する要求を処理するためにマークされる第１の利用可能なウェブサーバ実行インスタンス８２６を選択することができる。他の実施形態において、ウェブサーバ実行インスタンス８２６は、ウェブサーバ実行インスタンス８２６間の差異を考慮したポリシーに基づいて選択されてもよく、これにより、要求を処理するのに適切またはより最適になる（例えば、地理的位置、実行中のアプリケーション、利用可能なメモリ、処理能力、ディスク／メモリの断片化レベルなど）。
ステップ１１２４において、オンデマンドシステム８００は、ウェブサイト１２３に関する要求を処理するために、利用可能なインスタンス８２２内のウェブサーバ実行インスタンスを選択する。いくつかの実施形態では、ウェブサーバ実行インスタンス８２６が選択されて、ウェブサイト１２３に関する要求を処理する。
ステップ１１２５において、ウェブサーバ実行インスタンス８２６は、ウェブサーバ実行インスタンス８２６にウェブサイト１２３固有コード８３３を投入することにより、１セットの使用中のインスタンス１２１に追加され得る。いくつかの実施形態では、オンデマンドシステム８００は、ウェブサーバ実行インスタンス８２６に関するエントリにより状態テーブル９４１を更新するようにプロキシサーバ８４０に要求することができる。よって、状態テーブルにインスタンス１１４２およびウェブサイト１１４３の識別子を持つ行を追加することを含み、状態テーブル８４１が変更され得る。いくつかの実施形態では、第１の利用可能なインスタンス、例えばウェブサーバ実行インスタンス８２６は、サイト固有コード８３３が投入されるように選択されてもよい。この投入の後、ウェブサーバ実行インスタンス８２６は、１セットの利用可能なインスタンス８２２から除去される。
他の実施形態では、選択は、ウェブサイト１２３の要求場所への地理的な近さ、または特定の地理的場所から発信され得る潜在的なウェブ要求の数に基づいてもよい。いくつかの実施形態では、複数のウェブサーバ実行インスタンスは、ウェブサイト１２３固有コード８３３を投入され、１セットの使用中のインスタンス８２１に追加され得る。
要求されたウェブサイト１２３を処理する判定１１２０は、タイムアウト閾値（例えば、１０または１００ミリ秒）をさらに有し得る。タイムアウト期間は、ウェブページ要求を処理するための一般的なウェブ標準と整合し得る。利用可能なインスタンス８２２の一部であるウェブサーバ実行インスタンスは、新しいウェブサイト要求が出されたときにインスタンスをスピンアップする時間を短縮するのに役立つ。よって、先行する従来のウェブサイト構築システムのコールドスタートの問題は軽減される。
ステップ１１３０において、ウェブサーバ実行インスタンス８２６は、ウェブサイト１２３固有コード８３３を使用してウェブサイト１２３に関する要求を処理することができる。上述のように、ウェブサイト１２３固有コード８３３を使用して生成されたウェブサイトまたはページを提供することにより、ウェブサイトのコンテンツをユーザまたはユーザがサイトに到達した仕方に合わせて調整できる（例えば、ソフトウェアベースのルータを使用するなど）。いくつかの実施形態では、投入ステップ自体が、投入されたマテリアルを修正することができ、例えば、投入されたマテリアルを、要求を行っている特定のユーザ／プラットフォーム／デバイスまたは他の「環境」条件（国、言語、アクセスしたデータベース、ユーザアクセス履歴など）に合わせて調整することができる。ネットワーク
要求を開始するクライアントコードは、追加のパラメータまたは情報をネットワーク要求に追加して、投入モジュールがそのような適応を実行できるようにする。追加情報は、直接（例えば、追加されたＵＲＬまたは他の要求パラメータとして）または間接的に（例えば、追加要求、データベースへの事前の格納、または他の方法を介して利用可能）追加され得る。
図１２は、本開示のいくつかの実施形態による、ウェブサイトでのサーバインフラストラクチャ要素のインスタンス化を示している。図１２の技法は、上記で開示され、本開示を通して説明されるシステムで実施され得る。
図１２に示すように、ウェブサイト１２３は、ウェブサイト１２３固有コード８３３をコンテナ１２２１または仮想マシン１２２２にコピーすることにより、ウェブサーバ実行インスタンスを通じて提供され得る。いくつかの実施形態では、ウェブサイト１２３は、別個のオペレーティングシステムプロセス１２２３によって（例えば、サーバレスコードを介して）提供されてもよい。ウェブサイト１２３固有コード８３３は、ウェブサイトで提供され得るカスタマイズされたバックエンド機能に関連して上述したような、フロントエンド１２６、バックエンド１２７、およびプラグイン参照コード１２２６を含み得る。いくつかの実施形態では、フロントエンド１２６、バックエンド１２７、およびプラグイン参照コード１２２６は、コンテナ１２２１、仮想マシン１２２２、またはプロセス１２２３に個別にコピーされ得る。いくつかの実施形態では、汎用ウェブサイトサーバコード８２４は、ウェブサーバ実行インスタンス８２６のインスタンス化の一部としてコンテナ１２２１または仮想マシン１２２２（後にウェブサイト１２３固有コード８３３を含む）にコピーされ得る。
いくつかの実施形態では、サーバレスコードの実装などを介したオンデマンドシステム８００の使用は、処理時間およびサーバ利用率を改善する一方で、ユーザの待ち時間を短縮することができる。サーバレスコードの実施形態では、管理する専用サーバはない。代わりに、コード（例えば、フロントエンド１２６、バックエンド１２６、およびプラグイン参照コード１２２６）がクラウドでコードとして提供され、オンデマンドで実行され得る。ユーザがコードの実行に対して課金される範囲で、ユーザはコードの実際の実行に比例して課金され得る（専用のインフラストラクチャコストや、到来する要求を待つ間、所与のサイトに割り当てられたままにする必要のあるサーバに基づくものではない）。あるいは、これにより、オンラインＷＢＳベンダのコストを大幅に削減できると同時に、オンラインＷＢＳベンダがユーザにより良いサービスを提供できる。いくつかの実施形態では、オンデマンドシステム８００は、サーバレスコードを処理するためにサポートする１セットのプログラミング言語またはウェブフレームワークを定義し得る。オンデマンドシステム８００はまた、ＷｅｂＳｏｃｋｅｔ、ストリーミングまたはチャンク通信、追加プロトコル（例えば、ＴＣＰおよびＵＤＰなど）、サービスとしてのメモリの機能（例えば、ステートレスで、副作用のないコード機能のため）、およびネイティブサーバレスオプション（例えば、Ｇｏ、Ｒｕｓｔ、Ｃなど）をサポートし得る。サーバレスコードをオンデマンドで処理できることにより、従来のウェブサイトホスティングシステムの問題（例えば、マシンまたはウェブサイトのインスタンスをロードするための「コールドスタート」を経る）を軽減できる。ウェブサイトまたはページ（実行中のコードを含む）の開始時間は１００ミリ秒未満とすることができ、これにより、待ち時間が短縮され、ユーザエクスペリエンスが向上する。対照的に、一部の従来のシステムでは、オーバーヘッドのスケジューリング、インスタンスの起動、プロセスの起動（例えば、コードの実行）、および要求ハンドラーの機能の機能を含む、ウェブサイトまたはページの開始時間が約６００ミリ秒～２秒になる。
ウェブサイト実行インスタンス８２６は、コンテナ１２２１、仮想マシン１２２２、ま
たはプロセス１２２３を介して複数のウェブサイトを提供できる。いくつかの実施形態では、ウェブサーバ実行インスタンス８２６は、それに専用のまたは利用可能な１セットのコンテナ１２２１、仮想マシン１２２２、およびプロセス１２２３のリソースを有することができる。複数のコンテナ１２２１、仮想マシン１２２２、およびプロセス１２２３は、複数のウェブサイトを提供できる。いくつかの実施形態では、複数のウェブサイトを提供するウェブサイト実行インスタンス８２６の変形は、複数のウェブサイトを提供し得る単一のコンテナ１２２１、仮想マシン１２２２、またはプロセス１２２３を含むことができる。複数のウェブサイトを提供するコンテナ１２２１、仮想マシン１２２２、およびプロセス１２２３は、複数のウェブサイトのサイト固有コードをコピーして、様々なウェブサイト要求を処理する必要がある。
図１３は、本開示のいくつかの実施形態による、ホストされたウェブサイトの負荷監視の技法および使用中のインスタンス８２１の管理の技法を示している。これらの技法は、上記のようにシステムで実行され得る。
図１３に示すように、（図１１に関連して上述したような）ウェブサーバ実行インスタンスマネージャ９５０は、負荷監視部１３１０を監視またはこれと通信して、オンデマンドシステム８００により提供されるウェブサイトのいずれかの負荷が所望または予定された負荷よりも大きいか否かを判定する。上述のように、これは現在、以前、または将来の負荷特性に基づいて判定され得る。いくつかの実施形態では、過去のウェブサイト／複数のウェブサイトをホストしているウェブサーバの収集された定期的な負荷に基づく事前知識に基づいて、将来の負荷を予測することができる。過去の負荷には、季節的な傾向およびサイトの使用状況が最もアクティブな他の時期を把握し、ウェブサーバにより提供される特定のウェブサイトまたはウェブサイトのグループを提供するウェブサーバ実行インスタンスをより多く自動的に追加できるように、毎月、毎週、毎日、および毎時のものが含まれ得る。
ウェブサイトの負荷が比較的軽い場合、一部のインスタンスが、特定のウェブサイトの１セットの使用中のインスタンス８２１から除去され、利用可能なインスタンス８２２に戻される。いくつかの実施形態では、負荷監視部１３１０は、オンデマンドシステム８００によってホストされるすべてのウェブサイト１３１１およびそれらの負荷１３１２を表形式でリストする。いくつかの実施形態では、ウェブサイトの負荷をリストする負荷監視部１３１０テーブルは、プロキシサーバ８４０によって管理されるか、アクセス可能な状態テーブル９４１の一部であり得る。いくつかの他の実施形態では、負荷監視部１３１０は、プロキシサーバ８４０内の別個のテーブルであってもよい。他の実施形態では、負荷監視部１３１０は、オンデマンドシステム８００のメモリ８２０内にあってもよい。
いくつかの実施形態では、使用中のインスタンス８２１は、オンデマンドシステム８００の一部または全部のウェブサイトをホストする別個のインスタンスセットの集まりであってもよい。いくつかの実施形態では、図示のように、ウェブサイト１２３および２は、オンデマンドシステム８００によってホストされるウェブサイトである。様々な実施形態において、ウェブサイト１２３割り当てインスタンス１３２０およびウェブサイト２割り当てインスタンス１３３０は、ウェブサイト１２３およびウェブサイト２の１セットのウェブサーバ実行インスタンスである。いくつかの実施形態では、ウェブサイト１２３割り当てインスタンス１３２０およびウェブサイト２割り当てインスタンス１３３０は共に、使用中のインスタンス８２２と見なされる。
負荷監視部１３１０の負荷テーブルは、ウェブサーバ実行インスタンスマネージャ９５０によって直接更新されてもよいし、プロキシサーバ８４０に更新を要求してもよい。いくつかの実施形態では、負荷監視部１３１０の負荷テーブルは、オンデマンドシステム８
００によりホストされるウェブサイト１３１１へのアクセス要求の数に基づいてプロキシサーバ８４０により定期的に更新される。負荷監視部１３１０の負荷テーブルは、他のウェブサイトの使用統計に基づいて更新され得る。例えば、マルチメディアが多いウェブサイトの場合、使用統計情報には、ユーザにより使用されるデバイスの環境に基づいてビデオおよびオーディオを異なる形式に変換することを含むウェブサイト要求を処理するメモリおよびプロセッササイクルの使用量が含まれ得る。使用中のインスタンス８２１のウェブサーバ実行インスタンスは、ホストしているウェブサイトの負荷が軽くなると、利用可能なインスタンス８２２に移動される。同様に、ウェブサイトの負荷が大きくなると、利用可能なインスタンス８２２のウェブサーバ実行インスタンスは使用中のインスタンス８２１とマークされ、負荷の大きいウェブサイトのウェブサイト固有コードがこれらのウェブサーバ実行インスタンスに投入される。
いくつかの実施形態では、ウェブサイト１２３の負荷が軽いことをプロキシサーバ８４０が観測したことに基づいて、オンデマンドシステム８００は、ウェブサーバ実行インスタンス８２６をウェブサイト１２３割り当てインスタンス１３２０セットから利用可能なインスタンス８２２セットに移動させてもよい。いくつかの実施形態では、ウェブサーバ実行インスタンス１３２３は利用可能なインスタンス８２２に移動される。いくつかの実施形態では、複数のウェブサーバ実行インスタンスが同時に利用可能なインスタンス８２２に移動される。プロキシサーバ８４０は、ウェブサイト２の負荷が大きいことを負荷監視部１３１０において観測すると、ウェブサーバ実行インスタンス１１２７を利用可能なインスタンス８２２セットからウェブサイト２割り当てインスタンス１３３０セットに移動し得る。ステップ１３４２の一部として、ウェブサイト２は、ウェブサイト２割り当てインスタンス１３３０に移動する前に、ウェブサーバ実行インスタンスＭ １１２７に投入されるサイト固有またはページ固有コードを有し得る。当然のことながら、ステップ１３４１とステップ６４２とは独立であり、一緒にまたは特定の順序で発生する必要はない。
図１４は、本開示のいくつかの実施形態による、ホスティングに利用可能なウェブサーバ実行インスタンスの監視を示している。図１４に示すように、ウェブサーバ実行インスタンスマネージャ９５０は、利用可能なインスタンス８２２の数を監視する。ウェブサーバ実行インスタンスマネージャ９５０は、上述のように、１セットの利用可能なインスタンス８２２のセット内のウェブサーバ実行インスタンスの数が閾値未満である場合、新しいインスタンスをスピンアップし、１セットの利用可能なインスタンス８２２のプールに追加することができる。ウェブサーバ実行インスタンスマネージャ９５０は、ウェブサーバ実行インスタンスの数が閾値よりも大きい場合、１セットの利用可能なインスタンス８２２内のインスタンスを逆にシャットダウンし得る。実行インスタンスをスピンアップおよびシャットダウンするこれらの技法は、上述のように、特定のウェブサイトまたはページに関する現在の、以前の、または予想される将来の需要を考慮し得る。
いくつかの実施形態では、ウェブサーバ実行インスタンスマネージャ９５０は、新しいインスタンスをスピンアップする前に一定時間待機して、状態テーブル８４１を通じて識別された非アクティブなインスタンスがプールに再び追加されないことを確実にし得る。同様に、いくつかの実施形態では、ウェブサーバ実行インスタンスマネージャ９５０は、利用可能なインスタンスをシャットダウンする前に一定時間待機して、新しいウェブサイト要求を処理するためにウェブサイト固有コードをインスタンスに投入する必要がないことを確実にしてもよい。インスタンスのシャットダウンおよびスピンアップは時間のかかるプロセスである場合があり、ウェブサイト実行インスタンスマネージャ１５０は、利用可能なインスタンスの数が閾値数から逸脱していることを発見した後に待機することで、頻繁に行われることを回避する。
いくつかの実施形態において、ウェブサーバ実行インスタンスマネージャ９５０は、利用可能なインスタンス８２２セット内のインスタンスの現在の数が指定された数または割合だけ閾値と異なる場合、ウェブサーバ実行インスタンスをスピンアップおよびシャットダウンする。これにより、利用可能なインスタンス８２２の数に関してある範囲の値をいつでも存在させることができる。他の実施形態では、ウェブサーバ実行インスタンスマネージャ８５０は、閾値からの逸脱に即座に反応して、インスタンスをスピンアップおよびシャットダウンすることができる。
図１５は、本開示のいくつかの実施形態による、例示的なウェブサイトリアルタイムテストシステムを示している。図１５に示すように、ウェブサイトリアルタイムテストシステム１５００は、プロセッサ２６０と、メモリ８２０と、ウェブサイトで使用されるデータを格納するためのサイトエリアデータベース１２４と、アクセスされるウェブサイトに関連するデータへのアクセスを提供するデプロイ環境１５１０と、を備える。いくつかの実施形態では、ウェブサイトリアルタイムテストシステム１５００はまた、テスト目的でアクセスされるウェブサイトに関連するデータへのアクセスを提供するテスト環境１５２０も備え得る。テスト／デプロイという用語には、開発／実行時、ステージング／プロダクション、およびテスト／ライブなどの代替的な用語が使用されてもよい。
いくつかの実施形態では、オンデマンドシステム８００は、ウェブサイトリアルタイムテストシステム１５００に全体として含まれるサブシステムであってもよい。いくつかの実施形態では、ウェブサイトリアルタイムテストシステム１５００は、オンデマンドシステム８００から部分的に構成されてもよいし、オンデマンドシステム８００を含んでもよい。
デプロイ環境１５１０は、オンデマンドシステム８００のウェブサーバ実行インスタンスで実行される１セットのソフトウェアコンポーネントであり得る。
テスト環境１５２０は、オンデマンドシステム８００のウェブサーバ実行インスタンスで実行される１セットのソフトウェアコンポーネントである。いくつかの実施形態では、ウェブサイトにアクセスするために使用されるデバイスの種類に基づいて、テスト環境１５２０が生成される。例えば、ウェブ閲覧デバイス１４０上のウェブブラウザ１４１を介してアクセスされるウェブサイト１２３は、ウェブ閲覧デバイス１４０がデスクトップコンピュータまたは携帯電話である場合、外観およびレイアウトが異なる場合があるテスト環境１５２０を作り出し得る。いくつかの他の実施形態では、テスト環境１５２０は、どのユーザがウェブサイトにアクセスしているかに基づいて生成され得る。例えば、ウェブサイト１２３へのアクセスを要求する開発者／設計者１５４０は、テスト環境１５２０を作成することになり得る。いくつかの実施形態では、テスト環境１５２０はユーザ間で共有されてもよい。テスト環境１５２０は、ユーザごとに異なり得る。いくつかの実施形態では、テスト環境１５２０は、サイトエリアデータベース１２４に格納された複数のウェブサイトにわたって共有され得る。いくつかの実施形態では、テスト環境１５２０のインスタンスは常に利用可能であり、開発者／設計者１５４０は、所与のウェブサイトにアクセスするのにテスト環境１５２０を介するかデプロイ環境１５１０を介するかを選択することができる。
エンドユーザ１５３０は、ネットワーク１６０を介してデプロイ環境１５１０におけるウェブサイトおよびそのデータにアクセスできる。いくつかの実施形態では、エンドユーザ１５３０は、上記の実施形態と整合して、ウェブサイト閲覧デバイス１３０上のウェブブラウザ１３１を介してウェブサイト１２３にアクセスし得る。
開発者／設計者１５４０は、ネットワーク１６０を介してテスト環境１５２０において
ウェブサイトおよびそのデータにアクセスできる。開発者／設計者１５４０は、ウェブサイト開発デバイス１４０上のウェブブラウザ１４１を介してウェブサイト１２３にアクセスできる。いくつかの実施形態では、開発者／設計者１５４０は、ウェブ閲覧デバイス１３０上のウェブブラウザ１３１を使用することにより、デプロイ環境１５１０内のウェブサイト１２３にアクセスすることができる。ウェブ閲覧デバイス１３０と開発デバイス１４０とは同じデバイスであってもよいことに留意されたい。
エンドユーザ１５３０および開発者／設計者１５４０は、ウェブサイト１２３にアクセスする同一ユーザの異なる役割であってもよい。いくつかの実施形態では、ユーザは、異なるデバイスを使用してウェブサイト１２３にアクセスすることにより役割を変更することができる。例えば、ＷＢＳベンダスタッフデバイス１５０またはウェブサイト開発デバイス１４０を使用してウェブサイト１２３にアクセスするユーザは、開発者／設計者１５４０と見なされ得る。ウェブサイト閲覧デバイス１３０を使用してウェブサイト１２３にアクセスするユーザは、エンドユーザ１５３０と見なされ得る。ウェブサイトは、ユーザがエンドユーザ１５３０であるか開発者／設計者１５４０であるかに基づいて、それぞれデプロイ環境１５１０またはテスト環境１５２０を使用してアクセスされ得る。また、ウェブサイトは、要求がウェブサイト閲覧デバイス１３０からのものかウェブサイト開発デバイス１４０からのものかに基づいて、デプロイ環境１５１０またはテスト環境１５２０を使用してアクセスされ得る。いくつかの実施形態では、ウェブサイトは、ユーザとデバイス種別との組み合わせに基づいて、デプロイ環境１５１０またはテスト環境１５２０を使用してアクセスされ得る。
図１６ａは、本開示のいくつかの実施形態による、データ要素にアクセスするための開発環境１５１０の概略図を示している。図１６ａに示すように、デプロイ環境１５１０は、ライブデータ１６１０へのアクセスを支援するようにプロセッサ２６０に要求してもよい。デプロイ環境１５１０は、破線で示されているテストデータ１６２０にアクセスできない。図１６ｂは、本開示のいくつかの実施形態による、データ要素にアクセスするためのテスト環境１５２０の概略図を示している。図１６ｂに示すように、テスト環境１５２０は、ライブデータ１６１０およびテストデータ１６２０へのアクセスを支援するようにプロセッサ２６０に要求することができる。テスト環境１５２０を使用してウェブサイト１２３にアクセスする開発者／設計者１５４０は、ウェブサイト１２３のインデックス可能なウェブページ１２５に関連付けられたデータ要素を要求できる。テスト環境１５２０は、ユーザからのデータ要素に関する要求を受信するように構成でき、テストデータ１６２０に要求を転送できる。いくつかの実施形態では、テストデータ１６２０は、要求されたデータ要素がテストデータ１６２０に存在するか否かを判定してもよいし、ライブデータ１６１０に要求を転送してもよい。いくつかの実施形態では、テスト環境１５２０自体が、特定のデータ要素に関してライブデータ１６１０を要求かテストデータ１６２０を要求するかを判定し得る。いくつかの実施形態では、テスト環境１５２０は、ライブデータ１６１０およびテストデータ１６２０をメモリ８２０にコピーした後にライブデータ１６１０およびテストデータ１６２０にアクセスすることができる。
図１７は、本開示のいくつかの実施形態による、テスト環境１５２０におけるライブデータおよびテストデータへのウェブサイトアクセスの図である。図１７に示すように、ウェブサイト１２３のインデックス可能なウェブページ１２５は、ウェブ開発デバイス１４０上のウェブブラウザ１４１を使用してアクセスされる。インデックス可能なウェブページ１２５および関連するデータ要素は、テスト環境１５２０を介してアクセスされる。
インデックス可能なウェブページ１２３は、インデックス可能なウェブページ１２５に関連付けられたデータ要素へのアクセスの一部として、ライブデータ１６１０とテストデータ１６２０との両方にアクセスできる。いくつかの実施形態では、データ要素にアクセ
スするすべての要求は、最初にテストデータ１６２０に送信され得る。テストデータ１６２０は、ライブデータ１６１０に要求を転送する前に、テストデータ１６２０自体で処理され得るデータ要素アクセス要求を除外することができる。
図１８は、本開示のいくつかの実施形態による、ウェブサイトをテストするためのテスト環境１５２０で使用されるテストデータの生成を示している。図１８に示すように、ライブデータ１６１０はテストデータ１６２０の一部を形成する。いくつかの実施形態では、挿入済みとしてマークされたデータ１７３０および削除済みとしてマークされたデータ１７４０を追加する順序は異なっていてもよい。挿入済みとしてマークされたデータ１７３０および削除済みとしてマークされたデータ１７４０は、テストデータ１６２０にあるデータを追加した後で削除済みとしてマークされたこのデータを削除済みとしてマークされたデータ１７４０において削除するのを避けるために並行してトラバーサルされ得る。
挿入済みとしてマークされたデータ１７３０および削除済みとしてマークされたデータ１７４０は、サイトエリアデータベース１２４に保持され得る。いくつかの実施形態では、テスト環境１５２０でウェブサイト１２３にアクセスするセッションがアクティブになるまで、挿入済みとしてマークされたデータ１７３０および削除済みとしてマークされたデータ１７４０がメモリ９２０に置かれ得る。セッションが非アクティブになると、挿入済みとしてマークされたデータ１７３０および削除済みとしてマークされたデータ１７４０は、サイトエリアデータベース１２４に保持され得る。例えば、開発者／設計者１５４０は、挿入済みとしてマークされたデータ１７３０および削除済みとしてマークされたデータ１７４０がサイトエリアデータベース１２４に保持されるように明示的に要求できる。いくつかの実施形態では、挿入済みとしてマークされたデータ１７３０および削除済みとしてマークされたデータ１７４０は、サイトエリアデータベース１２４内の同じ場所を共有してもよい。挿入済みとしてマークされたデータ１７３０および削除済みとしてマークされたデータ１７４０は、読み出し要求の数に基づいて保持され得る。挿入済みとしてマークされたデータ１７３０内のデータ要素は、サイトエリアデータベース１２４に選択的に保持されてもよい。データ要素は、データ要素の読み出しが要求された回数、またはデータ要素のうちのあるデータ要素が変更されなかった時間、またはデータがアクセスされたセッションの数など、追加の基準に基づいて選択的に保持され得る。
図１９は、本開示のいくつかの実施形態による、デプロイ環境でウェブサイトにアクセスする方法１９００を示すフローチャートである。
ステップ１９１０に示すように、デプロイ環境１５１０でウェブサイトにアクセスするときに更新および追加されるデータ要素は、サイトエリアデータベース１２４のライブデータ１６１０に格納される。
ステップ１９２０において、デプロイ環境１５１０でアクセスされるウェブサイトのインデックス可能なウェブページに関連付けられたサイトエリアデータベース１２４に格納されたライブデータ１６１０は、ウェブサイトリアルタイムテストシステム１５００によって、ユーザにより要求されたウェブページを提供することの一部としてアクセスされる。
ステップ１９３０において、ステップ１９２０でアクセスされたデータ要素は、エンドユーザ１５３０によって使用されるウェブ閲覧デバイス１３０のウェブブラウザ１３１でウェブページをレンダリングするために関連付けられているインデックス可能なウェブページに適用される。
図２０は、本開示のいくつかの実施形態による、テスト環境でウェブサイトにアクセス
する方法２０００を示すフローチャートである。
ステップ２０１０において、ウェブサイトリアルタイムテストシステム１５００は、共通データベース（例えば、サイトエリアデータベース１２４）に格納されたウェブサイト（例えば、ウェブサイト１２３）でテストを実行する要求を受信し得る。ステップ２０２０において、ウェブサイトリアルタイムテストシステム１５００は、テスト環境１５２０を使用してウェブサイトをテストするプロセスの一部として行われたデータ要求を処理する。例えば、ウェブサイト１２３は、ウェブサイト開発デバイス１４０のウェブブラウザ１４１を使用してウェブサイト１２３にアクセスすることにより、開発者／設計者１５４０によってテストされてもよい。例えば、開発者／設計者１５４０は、ＵＲＬを入力して、ウェブサイト１２３のインデックス可能なウェブページ１２５を要求できる。さらに、いくつかの実施形態では、ＵＲＬはアプリケーションによって指定されてもよい。要求は、フロントエンド１２６への要求と、ウェブサイト１２３のインデックス可能なウェブページ１２５に関連付けられたデータグループ２１０のデータ要素への要求と、の両方を含む。データの読み出し要求は、ウェブページにアクセスするプロセスの一部として行われ得る。
図２０に示すように、ステップ２０３０において、ウェブサイトリアルタイムテストシステム１５００は、テストが完了したか否かを確認する。いくつかの実施形態では、ウェブサイトが一定期間テスト環境１５２０を介してアクセスされる場合、ウェブサイトのテストは完了したと見なされる。テストは、一定数のデータ要求後に完了したと見なされ得る。テストはまた、ウェブサイト開発デバイス１４０のウェブブラウザ１４１を介してウェブサイトにアクセスする開発者／設計者１５４０が、ウェブサイトへのアクセスに使用したブラウザタブまたはウィンドウを閉じると、完了したと見なされ得る。テストはまた、開発者／設計者１５４０がウェブサイトリアルタイムテストシステム１５００から明示的にテストの完了を要求した場合、完了したと見なされ得る。ステップ２０３０に対する答えが「いいえ」である場合、方法２０００はステップ２０１０に戻り、次のデータ要求を受信する準備をし得る。ステップ２０３０に対する答えが「はい」である場合、方法２０００はステップ２０４０に進むことができる。ステップ２０４０において、方法２０００は、データ要素に加えられ、テストデータ１６２０に保存された変更を、ライブデータ１６１０の対応するデータ要素に適用することができる。開発者／設計者１５４０は、例えば、テストデータ１６２０に組み込まれたデータ変更をドロップすることを要求し得るため、ステップ２０４０はオプションであってもよい。
ステップ２０５０において、テスト環境１５２０でウェブサイト１２３のテスト中に行われたデータ要素への更新に関連付けられたすべてのマーカが削除されてもよい。
図２１は、本開示のいくつかの実施形態による、テスト環境１５２０でデータ要求を処理するための方法２１００を示すフローチャートである。図２１の方法２１００は、開発者／設計者１５４０によってアクセスされているウェブサイトに関連付けられたデータ要素に関して到来する要求を処理するための５つの例示的な経路のうちの１つを特定する。
図２１に示すように、ステップ２１１０において、ウェブサイトリアルタイムテストシステム１５００は、テスト環境１５２０でデータ要求を受信する。データ要求は、テスト環境１５２０でテストするためのウェブサイトへのアクセスの一部である。例えば、ウェブサイト開発デバイス１４０を介してウェブサイト１２３にアクセスする開発者／設計者１５４０は、ウェブサイト１２３に関連付けられたデータグループ２１０のデータ要素２１１に関する要求をもたらし得る。
ステップ２１２０において、ウェブサイトリアルタイムテストシステム１５００は、テ
ストされているウェブサイトに関連付けられたデータ要素にアクセスする要求の種類を判定する。この判定により、様々な種類の要求が処理される。データ要求は、開発者／設計者１５４０がＵＲＬを入力してインデックス可能なウェブページを要求した場合に、開発者／設計者１５４０によりテストされているウェブサイトに関連付けられたデータ要素にアクセスする読み出し要求であり得る。いくつかの実施形態では、データ要求は、データ要素を追加するための書き込み要求であり得る。例えば、ウェブサイト１２３をテストする開発者／設計者１５４０は、データグループ２１０に追加する新しいデータ要素の作成を要求するインデックス可能なウェブページ１２５上でフォームを送信できる。データ要求は、開発者／設計者１５４０によってテストされているウェブサイトに関連付けられたデータ要素のコンテンツを変更する更新要求であり得る。データ要求は、開発者／設計者１５４０によってテストされているウェブサイトに関連付けられたデータ要素を除去する削除要求であり得る。
ステップ２１２１では、データ要求が、開発者／設計者１５４０によってテストされているウェブサイトに関連付けられたデータ要素を検索すること、またはそのような検索動作の結果を閲覧することであるとウェブサイトリアルタイムテストシステム１５００によってステップ２１２０で判定されている。
ステップ２１２２では、データ要求が、開発者／設計者１５４０によってテストされているウェブサイトに関連付けられたデータ要素を読み出すことであるとウェブサイトリアルタイムテストシステム１５００によってステップ２１２０で判定されている。
ステップ２１２３では、データ要求が、開発者／設計者１５４０によってテストされているウェブサイトに関連付けられたデータ要素を追加することであるとウェブサイトリアルタイムテストシステム１５００によってステップ２１２０で判定されている。
ステップ２１２４では、データ要求が、開発者／設計者１５４０によってテストされているウェブサイトに関連付けられたデータ要素を更新することであるとウェブサイトリアルタイムテストシステム１５００によってステップ２１２０で判定されている。
ステップ２１２５では、データ要求が、開発者／設計者１５４０によってテストされているウェブサイトに関連付けられたデータ要素を削除することであるとウェブサイトリアルタイムテストシステム１５００によってステップ２１２０で判定されている。
図２２は、本開示のいくつかの実施形態による、テスト環境で読み出し要求を処理するための方法２２００を示すフローチャートである。図２２の方法２２００は、３つの経路を特定して、データ要求に応答する必要があるか否か、応答する必要がある場合、テストデータ１６２０とライブデータ１６１０とのいずれのデータ要素を使用するかを判定する。
図２２に示すように、ステップ２１２２において、受信されたデータ要求は、方法２１００において、サイトエリアデータベース１２４およびメモリ８２０内のデータ要素に関する読み出し要求であると判定されている。
ステップ２２１０において、ウェブサイトリアルタイムテストシステム１５００は、要求されたデータ要素をテストデータ１６２０においてルックアップし、一致が見つかった場合に、削除済みとマークされているか否かを確認する。ステップ２２１０の答えが「はい」である場合、方法２２００はステップ２１２０に進み、方法２２００が完了したと見なすことができる。ステップ２において、「データ要素が見つかりません」というメッセージは返されない。例えば、ウェブサイト１２３のインデックス可能なウェブページ１２
５にアクセスする開発者／設計者１５４０は、テストデータ１６２０の削除済みとしてマークされたデータ１７４０のデータ要素１７４１に関する要求を送信して、「データ要素が見つかりません」というメッセージを返すことができる。
ステップ２２１０の答えが「いいえ」である場合、方法２１００はステップ２１３０に進むことができる。図２２に示すように、ステップ２２３０において、ウェブサイトリアルタイムテストシステム１５００は、テストデータ１６２０の挿入済みとしてマークされたデータ１７３０において、要求されたデータ要素をルックアップする。
ステップ２２３０の答えが「はい」である場合、方法２２００はステップ２２４０に進むことができる。ステップ２２４０において、要求されたデータ要素がテストデータ１６２０で見つかり、返される。要求されたデータ要素は、以前に新しいデータ要素として追加されたため、テストデータ１６２０の挿入済みとしてマークされたデータ１７３０にあり得る。さらに、要求されたデータ要素は、以前にウェブサイトのテスト中に更新されたため、挿入済みとしてマークされたデータに１７３０にあり得る。例えば、テスト環境１５２０で連絡先２ １７６０のデータ要素にアクセスする開発者／設計者１５４０の要求により、方法２２００がステップ２２４０を実行した後、テストデータ１６２０の挿入済みとしてマークされたデータ１７３０のデータ要素１７３２が返される。デプロイ環境１５１０で同じデータ要素を要求すると、データ要素１７５２が返され得る。
ステップ２２３０の答えが「いいえ」である場合、方法２２００はステップ２２５０に進むことができる。ステップ２２５０において、要求されたデータ要素がライブデータ１６１０から返される。
図２３ａは、本開示のいくつかの実施形態による、テスト環境でデータ要素を更新するための方法２３００を示すフローチャートである。図２３ａの方法２３００は、ウェブサイトのテスト中に要求された更新されたデータ要素を格納する場所を定義する。
図２３ａに示すように、ステップ２１２４において、受信されたデータ要求が、方法２１００において、ライブデータ１６１０またはウェブサイトのテスト中にテストデータ１６２０の挿入済みとしてマークされたデータ１７３０に存在するデータ要素を更新する要求であると判定されている。
ステップ２３１０において、ウェブサイトリアルタイムテストシステム１５００は、テストデータ１６２０の挿入済みとしてマークされたデータ１７３０を最初にチェックインすることにより、更新が要求されているデータ要素の場所を判定する。
ステップ２３１０に対する答えが「はい」である場合、方法２２００はステップ２３２０に進む。ステップ２３２０において、更新が要求されているものに対応するデータ要素が更新される。
ステップ２３１０に対する答えが「いいえ」である場合、方法２２００はステップ２３３０に進み、更新が要求されたデータ要素は過去に更新されておらず、ライブデータ１６１０のみに存在することを指示する。テスト環境１５２０でのデータへの将来のアクセスを避けるために、ライブデータ１６１０のデータ要素は削除済みとしてマークされたデータ１７４０にコピーされる。
ステップ２３４０において、ウェブサイトリアルタイムテストシステム１５００は、更新されたデータ要素をテストデータ１６２０に挿入する。いくつかの実施形態では、データ要素を追加することは、データベースエントリを追加し、テスト環境を介して追加され
たと追加の列にマークを付けることを含む。テスト環境１６２０からテストデータ１６２０の挿入済みとしてマークされたデータ１７３０に挿入されたデータ要素には、デプロイ環境１６１０での要求ではアクセスできない。例えば、開発者／設計者１５４０によるウェブサイト１２３を介してのデータ要素１７５２を更新する要求により、データ要素１７３２がテストデータ１６２０の挿入済みとしてマークされたデータ１７３０に挿入される。
図２３ｂは、本開示のいくつかの実施形態による、デプロイ環境１５１０でデータ要素を更新するための別の方法２３００を示すフローチャートである。本方法は、テスト環境１５２０を使用してウェブサイトをテストする開発者／設計者１５４０が確実にライブデータ１６１０をリアルタイムで利用できるようにする。
ステップ２３５０において、デプロイ環境１５１０でデータ要素を更新する要求が受信される。
ステップ２３６０において、ライブデータ１６１０内のデータ要素が要求に従って更新される。
ステップ２３７０において、ステップ２３６０でライブデータ１６１０において更新されたデータ要素を識別するためのルックアップ要求が、削除済みとしてマークされたデータ１７４０に対して行われる。削除済みとしてマークされたデータ１７４０で見つかった対応するデータ要素は、テスト環境１５２０で更新または削除されている。
ステップ２３７０の答えが「いいえ」である場合、方法２３００はステップ２３８０に進み、そこでタスクは完了したと見なされ、方法２３００は終了する。
ステップ２３７０での答えが「はい」である場合、方法２３００はステップ２３９０に進む。ステップ２３９０において、デプロイ環境１５１０を介して更新するように要求されたデータ要素が、削除済みとしてマークされたデータ１７４０において更新される。これにより、以下のプロセス２５００で説明するように、ライブデータ１６１０で更新されるデータ要素がクエリ結果に含まれなくなる。
図２３ｃは、本開示のいくつかの実施形態による、テスト環境でデータ要素を追加するための別の方法２３００を示すフローチャートである。図２３ｃの方法２３００は、ウェブサイトのテスト中に追加が要求された新しいデータを格納する場所を定義する。
図２３ｃに示すように、ステップ２１２３において、受信されたデータ要求が、方法２１００において、ウェブサイトのテスト中にライブデータ１６１０に存在していない新しいデータ要素をテストデータ１６２０に追加する要求であると判定されている。
ステップ２３９２において、ウェブサイトリアルタイムテストシステム１５００は、データ要素をテストデータ１６２０に挿入する。いくつかの実施形態では、データを追加することは、データベースエントリを追加し、テスト環境を介して追加されたと追加の列にマークを付けることを含む。テスト環境１６２０からテストデータ１６２０の挿入済みとしてマークされたデータ１７３０に挿入されたデータ要素には、デプロイ環境１６１０での要求ではアクセスできない。例えば、開発者／設計者１５４０がウェブサイト１２３を介してデータ要素１７３１を追加するよう要求すると、データ要素１７３１がテストデータ１６２０の挿入済みとしてマークされたデータ１７３０に挿入され得る。
図２４は、本開示のいくつかの実施形態による、テスト環境からデータ要素を削除する
ための方法２４００を示すフローチャートである。図２４に示すように、削除が要求されたデータ要素は、ライブデータ１６１０に提示されてもよいし、テスト環境を介して以前に追加されていてもよく、挿入済みとしてマークされたデータ１７３０に存在する。
図２４に示すように、ステップ２１２５において、受信されたデータ要求は、方法２１００において、サイトエリアデータベース１２４またはメモリ８２０内のデータ要素に関する削除要求であると判定されている。
ステップ２４１０において、ウェブサイトリアルタイムテストシステム１５００は、削除するよう要求されたデータ要素を、テストデータ１６２０の削除済みとしてマークされたデータ１７４０に挿入することができる。テスト環境で追加されたか更新されたかを問わずあらゆるデータ要素は、テストされるウェブサイトに関連付けられたデータ要素に関する要求が行われたときに削除済みとしてマークされたデータ１７４０のすべてのデータ要素がスキップされ得るため、削除済みとしてマークされたデータ１７４０に追加され得る。
ステップ２４２０において、削除が要求されたデータ要素のルックアップが、テストデータ１６２０の挿入済みとしてマークされたデータ１７３０で検索される。テストデータ１６２０にそのようなデータ要素が見つからない場合、プロセス２３００は完了したと見なされる。例えば、ウェブブラウザ１４１でウェブサイト１２３をテストする開発者／設計者１５４０は、データ要素１７４１を削除する要求を行い、これにより、データ要素１７４１が削除済みとしてマークされたデータ１７４０に挿入される。データ要素１７４１が挿入済みとしてマークされたデータ１７３０に存在しないことは、データを除去する必要がないことを示し、プロセス２４００は完了したと見なされる。ステップ２４２０での答えが「いいえ」である場合、方法２４００は、挿入済みとしてマークされたデータ１７３０において、削除が要求されたデータ要素１７３０を見つけておらず、方法２４００はステップ２４３０に進み、そこでタスクは完了し、方法２４００は終了する。
ステップ２４２０の答えが「はい」である場合、方法２４００は、挿入済みとしてマークされたデータ１７３０で、削除が要求されたデータ要素を見つけている。ステップ２４４０において、テストデータ１６２０のデータ要素が挿入済みとしてマークされたデータ１７３０から除去される。
図２５は、本開示のいくつかの実施形態による、テストデータを問い合わせた結果を生成するためのオーバーレイプロセスを示している。図２５に示すように、方法２５００は、ライブデータ１６１０、テストデータ１６２０の挿入済みとしてマークされたデータ１７３０および削除済みとしてマークされたデータ１７４０に並行してアクセスする４ステップのプロセスである。
図２５に示すように、ステップ１において、クエリに整合するデータ要素は、ライブデータ１６１０、挿入済みとしてマークされたデータ１７３０、および削除済みとしてマークされたデータ１７４０からアクセスされる。いくつかの実施形態では、データ要素は、ライブデータ１６１０、ならびにテストデータ１６２０の挿入済みとしてマークされたデータ１７３０および削除済みとしてマークされたデータ１７４０に対してサイトエリアデータベース１２４でクエリを実行することによりアクセスされる。いくつかの実施形態では、クエリの結果は、１つの融合テーブル２５１０として構成されてもよい。
データ要素は、クエリで要求されたとおりに並べ替えされる。いくつかの実施形態では、データ要素は、２５１０の列「Ｂ」によって降順で並べ替えされる。いくつかの実施形態では、順序は複数の列を含み得る。いくつかの実施形態では、要求された順序がない場
合、ランダムな列が選択され、昇順または降順で並べ替えされる。いくつかの実施形態では、並べ替えに使用される列に主キーが追加される。
ステップ２において、システムは、ライブデータ１６１０、挿入済みとしてマークされたデータ１７３０、および削除済みとしてマークされたデータ１７４０のデータ要素を同時にトラバーサルして、テストデータ１６２０に含めるデータ要素を選択する。
テスト１７２０に含めるデータ要素を判定するために、ライブデータ１６１０、挿入済みとしてマークされたデータ１７３０、および削除済みとしてマークされたデータ１７４０の最初の要素にポインタを設定する。いくつかの実施形態では、ポインタは、列「Ｂ」に基づいて最も若いデータ要素に配置される。ライブデータ１６１０、挿入済みとしてマークされたデータ１７３０、および削除済みとしてマークされたデータ１７４０の現在の最も若いレコードを比較して、最も若いデータ要素を識別する。発見され得る最も若いものは複数の場所に存在する場合がある。例えば、データ要素２５２０および２５３０は、ライブデータ１６１０および削除済みとしてマークされたデータ１７４０の最も若いデータ要素であり、同じコンテンツを有する。
最も若いデータ要素が識別されると、次の規則に基づいて、データ要素をテストデータ１６２０に含めるか否かが判定される。データ要素がライブデータ１６１０と削除済みとしてマークされたデータ１７４０との両方に存在する場合、データ要素はテストデータ１６２０に含めることからスキップされる。例えば、データ要素２５２０および２５３０は同じコンテンツを有し、ライブデータ１６１０および削除済みとしてマークされたデータ１７４０に存在し、以前にウェブサイトのテスト中にテスト環境１５２０でデータ要素の削除が要求されたことを指示する。また更新されていてもよく、データ要素２５６０が結果として得られた更新された要素であった。
データ要素がライブデータ１６１０にのみ存在する場合、データ要素はテストデータ１６２０に含まれる。例えば、データ要素２５４０はライブデータ１６１０にのみ存在し、データ要素２５４０に関連付けられているウェブサイトをテストするときにテスト環境で変更または削除されなかったことを指示する。
データ要素が挿入済みとしてマークされたデータ１７３０にのみ存在する場合、テストデータ１６２０に含まれる。例えば、データ要素２５４０は、削除済みとしてマークされたデータ１７４０にのみ存在し、新しいデータ要素として挿入されたか、ウェブサイトのテスト中にデータ要素２５２０の更新の一部として挿入されたことを指示する。
データ要素が含められる、またはスキップされると、最も若いデータ要素を持つデータ要素のソースのみが、次のデータ要素に移動するためのポインタを持つ。いくつかの実施形態において、ライブデータ１６１０および削除済みとしてマークされたデータ１７４０のポインタは、トラバーサルの最初の反復後に次のレコードに移動される。
データ要素の３つのソースすべての最後のデータ要素に到達すると、方法２５００は終了し、テストデータ１６２０が取得される。融合テーブル２５６０は、上述のステップ２の各反復で識別された最も若いデータ要素を示している。最も若いデータ要素を持つソースのみが記入されて表示され、残りは空のままになる。例えば、ステップ２の最初の反復では、同じコンテンツを持つ最も若いデータ要素２５２０および２５３０がそれぞれのソース、すなわちライブデータ１６１０および削除済みとしてマークされたデータ１７４０の一部として表示され、削除済みとしてマークされたデータ１７４０は空になり、最も若いデータ要素を持っていなかったことを指示する。同様に、最後の反復では、挿入済みとしてマークされたデータ１７３０のみが、融合テーブル２５６０の最後の行に示されてい
る最も若いデータ要素２５５０を持つ。
図２６は、本開示のいくつかの実施形態による、ウェブサイトのプレビュー中にデータベースを編集するための方法２６００のステップを示すフローチャートを示している。方法２６００は、図１、図２、図１５など、本開示を通して説明されるシステム環境で実施され得る。
図２６に示すように、ステップ２６０２は、（例えば、ウェブサイト構築システムのユーザから）データ要素の１つまたは複数のグループを受信することを含み得る。データ要素は、上述したように、テキスト、画像、ビデオ、広告、データベース出力表示など、ウェブサイトに組み込まれ得る様々な異なる種類のコンテンツまたはコンテンツのレコードを含み得る。いくつかの実施形態では、データ要素は、１セットのデータオブジェクト（例えば、テキストの２つのインスタンスおよび１つの画像）をさらに含み得る。各グループは、１つまたは複数のデータ要素を有し得る。よって、グループは、関連する１セットの１つまたは複数の要素を定義できる。例えば、第１のウェブサイトまたはページ（例えば、ウェブページの識別子）がテキストのみを含むグループに関連付けられてもよく、第２のウェブサイトまたはページがデータ要素（それぞれが１つのテキストおよび３つの画像を含む）を含むグループに関連付けられてもよく、第３のウェブサイトまたはページがテキストおよびビデオなどのデータ要素を含むグループに関連付けられてもよい。上述したように、ユーザは、ウェブサイト編集インターフェースを介して、ウェブサイトの個々のウェブページまたは所与の仮想ページテンプレートに表示されるべき、または関連付けられるべき、データ要素のグループを識別することができる。
データグループは、いくつかの実施形態では、ウェブサイトの複数のページで使用および再利用され得るサイトレベルのエンティティとすることもできるし、特定のウェブサイト所有者により使用および再利用され得る所有者レベルのエンティティとすることもできる。さらに、データグループはまた、システムレベルのエンティティ（例えば、郵便番号、地理的領域の説明などのデータベース）またはページレベルのエンティティとすることもできる。
方法２６００はまた、上記の実施形態と整合する、サイトエリアデータベース１２４に１つまたは複数のデータ要素のグループを格納するステップ２６０４を含み得る。そのようなデータベースの例は（例えば、図１、図２、図１５などに関連して）上で説明されている。データベースは、各グループを維持するように、またグループとウェブサイトもしくはページまたは仮想ページテンプレートとの間の関連付けを維持するように、また他のコンテンツおよび情報を格納するように構成され得る。以下でさらに説明するように、ユーザがプレビューモード中に仮想ウェブページを編集する場合、そのような編集はリアルタイムでデータベースに対する編集に変換されるため、各ウェブページの最新のデータベースが維持される。
加えて、方法２６００は、１つまたは複数の仮想ウェブページを生成するステップ２６０６を含み得る。仮想ウェブページのそれぞれは、実際のウェブサイトまたはその更新された部分が稼働する（すなわち、インターネットを通じて他のユーザに閲覧可能となる）前に（開発中の）プレビューモードで表示され得る（１つまたは複数のオブジェクトから構成される）データ要素を表し得る。その後、ライブモードで仮想ウェブページコレクションを公開するために、ユーザは「公開」、「投稿」などのタイトルのオプションを選択でき、これにより、（公開は通常、単一ページではなくサイトレベルで行われるため）ウェブサイトがインターネットを通じて閲覧可能になる。公開されると、仮想ページ（すなわち、ウェブページテンプレート２７０４から導出されたインスタンス）は、動的に生成されているにもかかわらず、普通の（実際の）ページと同様の挙動をし得る。いくつかの
実施形態では、実際のウェブページのそれぞれは、データベースを更新する機能を備えて設計されていないが、仮想ウェブページはその機能を備えて設計されていてもよい。例として、ホテル予約サイトは、特定のホテルで利用可能な５つの異なるタイプの部屋（シングルベッド、ダブルベッドなど）のための５つの異なる仮想ページテンプレートを維持することができる。仮想ページテンプレートのそれぞれを、独自のデータ要素グループ（すなわち、所与のタイプの部屋のためのレコード）に関連付けることができ、よって、各部屋は、プレビューモード中に仮想ウェブページとして表示可能および編集可能であり得る仮想ウェブページを有し得る。
さらに、方法２６００は、仮想ウェブページセットのうちの別個の１つに少なくとも１つのデータ要素の各グループを表示するステップ２６０８を含み得る。例えば、上記のホテルウェブサイトの仮説では、プレビューモード中に、ホテルの異なるタイプの部屋に対応する５つの仮想ウェブページテンプレートのそれぞれが、データ要素の関連付けられたグループ（例えば、部屋を説明する異なるテキスト、部屋の画像、部屋の動画など）を有し得る。生成された仮想ウェブページセット（すなわち、インスタンス）は、他の技法に関連して上述したように、ブラウザまたは他のクライアントを介してユーザに表示され得る。
方法２６００はまた、ユーザが仮想ウェブページテンプレートおよびインスタンスのうちの１つまたは複数を編集できるようにする編集ツールを表示することを含むステップ２６１０も含み得る。テンプレートは、通常のページであるかのように編集され得る。インスタンスは、通常のエディタページの閲覧および編集プロセスの一部として表示されない場合があるため、プレビューモードでのみ編集可能であり得る。代替的な実施形態では、本システムにより、通常のサイト編集プロセスの一部としてインスタンスを編集することができる。様々な編集ツールを使用することができ、編集ツールとしては、ルーラーおよびグリッド（例えば、データ要素のアライメントのため）、ドラッグアンドドロップセレクタ（例えば、カーソルによりデータ要素を移動するため）、ハイパーリンクの挿入および編集、ウィジェットまたはアプリの組み込み（例えば、アプリストアから）、ボタンの挿入および編集、テキストの作成および編集、画像の挿入および編集、ビデオの挿入および編集、スライドショーの作成および編集、カーソルのホバー機能、背景スタイル、リピータ（例えば、特定のデータ要素またはグループの複数のバージョンを作成する）、ソフトウェアベースのルータ（例えば、アクセスに使用されるＵＲＬの要素に基づいてウェブページの異なるバージョンを作成する）などが挙げられる。システムは、テンプレートおよびインスタンスに関して利用可能な編集ツールの異なるサブセットを表示する（および動作させる）ことができ、また、ユーザ、仮想ページテンプレート、特定のインスタンス、基礎となる接続されたデータグループまたは要素などに応じて、表示された編集ツールサブセットをカスタマイズすることができる。以下でさらに説明するように、ユーザは、編集ツールを介して仮想ウェブページテンプレートおよびインスタンスを編集することができ、その編集は、ウェブページのためのコンポーネント情報および／またはコンテンツを維持するデータベースに対する編集に変換され得る。
方法２６００はまた、各仮想ウェブページに一意のＵＲＬを関連付けるステップ２６１２も含むことができる。例えば、ウェブサイトは、ドメイン名（例えば、ｗｉｘ．ｃｏｍ）を有し、ウェブサイト内の各ページは異なるサフィックス（例えば、ｗｉｘ．ｃｏｍ／ｐａｇｅ１、ｗｉｘ．ｃｏｍ／ｐａｇｅ２、ｗｉｘ．ｃｏｍ／ｐａｇｅ３など）を有し得る。さらに、場合によっては、仮想ウェブページに関連付けられたＵＲＬは、異なる（ファイルまたはディレクトリを参照する）パスまたはパラメータ値を有し得る。いくつかの実施形態では、ソフトウェアベースのルータは、ウェブサイトまたは個々のウェブページのために構成され得る。ソフトウェアベースのルータは、例えば、特定のＵＲＬプレフィックス、パス、セグメント、またはパラメータを特定のウェブページに関連付けるように
構成可能である。ウェブページのそれぞれは、データ要素を格納するデータベースから異なるデータをプルするように構成され得る。例えば、ＪａｖａＳｃｒｉｐｔの実装では、ウェブページに関する到来する要求が、要求に関する情報（例えば、ＵＲＬ、どこから到来したか、誰から到来したかなど）を含むオブジェクトに関連付けられ得る。ソフトウェアベースのルータは、この情報を処理し、表示するウェブページ（場合により仮想ウェブページ）とそれに含めるデータ要素を決定できる。
加えて、方法２６００は、仮想ウェブページのそれぞれを個別かつ動的に表示するために、ユーザが仮想ウェブページにわたってナビゲートできるようにするユーザ選択可能機能（例えば、ボタン、スクロールバー、リンクなど）を表示するステップ２６１４を含み得る。したがって、上記の例では、ユーザ選択可能機能により、ユーザはホテルの異なる部屋タイプに対応する５つのウェブページセットのそれぞれを閲覧できる。各ページは動的に選択され、仮想ウェブページとして閲覧される。
方法２６００は、ユーザからの１つまたは複数の仮想ウェブページ属性に対する編集を受信するステップ２６１６をさらに含み得る。例えば、上述の編集ツールを使用して、ユーザは、ページの背景、ページのレイアウトもしくはテンプレート、ページに組み込まれたアプリもしくはウィジェット、ページに関連付けられたＵＲＬプレフィックスもしくはサフィックス、ページ内のリピータ機能、またはページのソフトウェアベースのルータ機能を変更することもできるし、他の様々な種類の編集を実行することもできる。ウェブページテンプレート２７０４に加えられた変更は、サイトエリアデータベース１２４のテンプレートページ定義に直接書き込まれ得る。仮想ページインスタンスに加えられた変更は別のデータベースに格納されてよく、このデータベースは仮想ページインスタンスへの適応を含むものとする。このようなスキームでは、適応は特定の仮想ページインスタンスの一意のインデックスでインデックスされるものとする（例えば、上記のホテルの例では、「シングルベッドルーム＃１２３４」）。この仮想ページインスタンスが表示のために生成されるたびに（例えば、プレビュー中またはライブ表示中に）、適応が取得および再適用される。
いくつかの実施形態では、ユーザは、仮想ページインスタンスを編集することが許可されるが、それはフィールド情報（例えば、テキスト、グラフィックス、ビデオなど）に関してのみである。例えば、そのような実施形態では、ユーザは、レイアウト、属性などを含む仮想ページインスタンスの他の要素（すなわち、コンテンツ以外）を編集することを禁止され得る。
方法２６００はまた、データ要素自体への編集を受信するステップ２６１８も含み得る。そのような編集は、データグループの表示（すなわち、基礎となるデータグループおよび要素の閲覧および編集を可能にする表示ユーザインターフェース要素）に対して直接行われ得る。あるいは、そのような編集は、項目に関連する生成された仮想ページインスタンスのフィールドコンテンツの編集を通じて実行されてもよい。システムは、（プレビューモードで）表示される仮想ページインスタンスに追加の編集コントロールを追加することにより、そのような編集を可能にし得る（データグループに由来する各表示画像に追加される「別の画像を選択する」ボタンなど）。上述のように、データ要素はデータベースに格納されてもよい。編集には、テキストの編集、画像の置換または修正、ビデオの置換または修正、カーソルを要素上にホバーさせる機能の変更、および他の様々な種類の編集が含まれ得る。
加えて、方法２６００は、１つまたは複数の仮想ウェブページに関連付けられたコードへの編集を受信するステップ２６２０を含み得る。コードの例は、図１～図７に関連して上述したフロントエンドコードおよびバックエンドコードであり得る。例えば、コードは
、データベースにおけるデータおよびコンテンツの収集および格納、動的ページの作成、ユーザに相対するウィジェットおよびアプリの実装、データ要素のレイアウトの繰り返し、ソフトウェアベースのルータの構成などに関連し得る。いくつかの実施形態では、ステップ２６２２において、スケルトンコードセグメントが生成されて、ウェブページに関連付けられたコードに対するユーザ編集を容易にし得る。例えば、スケルトンコードは、より粒度の細かいソースコードに関連付けられた機能の高レベルの抽象化であってもよく、これは、ウェブページに上記の様々な種類のフロントエンドおよびバックエンド機能を実装できる。スケルトンコードは、編集インターフェースを介してユーザに表示されてもよく、ユーザがこれを編集することができる。次いで、スケルトンコードに対するユーザ編集は、個々のウェブページに関連付けられたより粒度の細かい実際のコードの編集に変換され得る。上記のページ属性およびページデータ／フィールドコンテンツの編集に関しては、システムは、ウェブページテンプレート２７０４（サイトエリアデータベース１２４に格納され、公開前の開発変更のサンドボックス化の対象となり得る）または仮想ページインスタンス（仮想ページインスタンス適応データベースに格納され得る）に対する編集をサポートし得る。これについては、以下のステップ２６３０および２６３４の説明でさらに詳しく説明する。
方法２６００では、ステップ２６２４は、ユーザが特定の仮想ウェブページを選択できるようにし、ステップ２６２６は、ユーザが仮想ウェブページにわたってナビゲートできるようにする。例えば、ユーザは、ハイパーリンクまたはページの画像もしくは視覚的表現に関連付けられた他のリンクをクリックすることによりページを個別に選択することもできるし、ページにわたって視覚的にナビゲートしたりすることもできる（例えば、左／右もしくは上／下のトグルボタン、または他の選択の視覚化）。
方法２６００によれば、仮想ウェブページに対するあらゆる編集（例えば、ステップ２６１６または２６１８によるインスタンスの編集）が、ステップ２８２８において、ウェブページのためのデータ要素を維持するデータベースに対する更新に変換され得る。例えば、ユーザが仮想ウェブページの画像を別の画像（例えば、ユーザがアップロードした画像など）に置き換える場合、新しい画像はデータベースに格納され得る。さらに、ユーザが仮想ウェブページ上のテキスト（例えば、特定のホテルの部屋の説明）を置き換える場合、更新されたテキストもデータベースに格納され得る。いくつかの実施形態では、データベースに対する更新は、仮想ウェブページに対するユーザの編集に基づいて自動的に実行され得る。データベースは仮想ウェブページの構築に使用され、仮想ウェブページのコンテンツに関連付けられるため、仮想ウェブページの編集は、それらの構築に使用されたデータベースに戻って関連付けられ得る。いくつかの実施形態では、データベースの複数のバージョンが少なくとも一時的に格納されるため、ユーザは、行った仮想ウェブページへの変更を無効にして以前のバージョンに戻したい場合に、元に戻す動作または取り消す操作を実行できる。例えば、ユーザは元に戻すまたは取り消すオプションを選択することもできるし、編集を戻したり再開したりできる仮想ウェブページの以前のバージョンに関連付けられたタイムスタンプまたはバージョン識別子を提示することもできる。そのようなバージョン管理システムはまた、公開操作が実行されるまで、公開されたバージョンの一部ではない開発データベースのバージョンへの変更をサポートし得る。これは、開発データベースの「サンドボックス化」としても知られている。
方法２６００はまた、ステップ２６３０を含むことができ、ユーザによって行われたスケルトンコードへの編集が受信される。さらに、ステップ２６３４において、実際のコード（例えば、ステップ２６２０を介して）またはスケルトンコード（例えば、ステップ２６３０を介して）に対する編集は、ウェブページの実際のコードへの編集に変換され得る。上述のように、例えば、ユーザは仮想ウェブページの様々なバックエンドまたはフロントエンド機能に関連付けられた実際のコードまたはスケルトンコードを編集できる。コー
ドに対するこのような編集は、仮想ウェブページのデータ要素をホストする同じデータベースまたは別のコードデータベースに格納され得る。
さらに、ステップ２６３２では、方法２６００は、仮想ウェブページに関連付けられた実際のウェブページのライブビュー中に、通常のウェブページと仮想ウェブページのインスタンスとの両方を含む、プレビューモード中に仮想ウェブページに加えられた更新と共にウェブページの表示を可能にするステップを含み得る。上述のように、例えば、ユーザはテンプレートとインスタンスとの両方のプレビューモード中に仮想ウェブページの多数の機能（例えば、ページ構造、データ要素、フロントエンドコード、バックエンドコードなど）を編集可能であり得る。このような編集は、ページ定義またはデータ要素の変更に対する対応する更新に変換され、これは、サイトエリアデータベース１２４および／または別個のデータベース（例えば、データ要素データベース、インスタンス適合データベース、および／または仮想ウェブページのベースとなる別個のコードデータベース）に格納され得る。そのような別個のデータベースはまた、例えば、メモリ８２０または永続性記憶装置８３０の一部として、ＷＢＳ１００によってホストされてもよい。さらに、そのような編集は、実際のライブウェブページの対応する更新にも変換され得る。様々な実施形態において、仮想ウェブページおよび実際のウェブページは、同じデータベース（複数可）に基づいていても異なる（例えば、リンクされた）データベース（複数可）に基づいていてもよい。これらのデータベース（例えば、サイトエリアデータベース１２４、およびデータ要素データベース、インスタンス適応データベース、または個別のフロントエンド／バックエンドコードデータベースなどの他のデータベース）は、単一のデータベース、１セットのデータベース、または（それぞれが必要な機能のサブセットをサポートし得る）データベースの組み合わせとして実装され得ることに留意されたい。
図２７は、本開示のいくつかの実施形態による、ウェブページの開発およびプレビューのためのシステム２７００である。上述のように、システム２７００は、図１、図２、図１５などに関連して説明したシステムと同様であっても、その中で動作するのであってもよい。いくつかの実施形態では、システム２７００は、１つまたは複数のウェブページ２７０４のためのデータ要素および／またはコードを格納するサイトエリアデータベース１２４を備えることができる。図示のように、多数のウェブページ２７０４が維持されてもよく、それらのそれぞれがそれ自体の対応するデータ要素を有し得る。上述のように、データ要素は、１つまたは複数のデータ要素のデータグループ２１０に編成されてもよい。上述のように、そのようなデータグループ２７１０は、システム全体、サイトグループ固有、サイト固有またはページ固有（通常、所与のウェブページテンプレート２７０４のため）であり得る。
図２７に示すように、サイトエリアデータベース１２４は、ネットワークを介してウェブブラウザ１３１または他のクライアントアプリケーションと通信することができ、これらはユーザによって操作され得る。ウェブブラウザ１３１は、データグループ２１０内のデータ要素を使用して、サイトエリアデータベース１２４内の各ウェブページテンプレート２７０４に対応する仮想ウェブページ２７１２を表示することができる。さらに、各仮想ウェブページ２７１２は、データ要素２１１に関連付けられ得る。さらに、ユーザは、データ要素グループ２７１４の一部として、データ要素（例えば、データ要素１ ２１１およびデータ要素２ ２７１８）の個別の表示を有することができる。上述のように、ユーザは、その要素２７１０、２７１４、２１１、２７１８を含む表示された仮想ウェブページ２７１２と対話して、仮想ウェブページ２７１２の様々な機能を編集することができる。編集は、特定のデータ要素、ページ構造機能、フロントエンドコード、バックエンドコードなどを含み得る。上述のように、そのような編集は、サイトエリアデータベース１２４および／または他のデータベースにより受信され得る。
図２８は、本開示のいくつかの実施形態による、仮想ウェブページのブロック図２８００である。上記の例と整合して、仮想ウェブページ２７１２は、表示機能２８０４、検索要素２８０６、ブックマーク２８１０、スクロール機能２８１０、および他の機能を含む様々なユーザ選択可能機能２８０２を含むことができる。仮想ウェブページ２７１２は、上述のように、データ要素２７１４およびフロントエンドコード２８１２をさらに含み得る。さらに、仮想ウェブページ２７１２は、動的ウェブページコードなどのバックエンドコード（図示せず）に関連付けられ得る。上述のように、ユーザは仮想ウェブページ２７１２に対して、これを閲覧し、これと対話し、これを編集できる。このような編集は、サイトエリアデータベース１２４などのウェブサイト構築システムの１つまたは複数のコンポーネントで受信され得る。仮想ウェブページ２７１２の表示により、ユーザは、対応するウェブページが稼働する前にユーザが行っている編集を視覚化できる。仮想ウェブページ２７１２をライブモードで公開するには、上述のように、ユーザは「公開」または「レンダリング」リンクを選択できる。
図２９は、本開示のいくつかの実施形態による、ウェブページの動的リフレッシュのタイムライン表示２９００である。特に、ユーザが仮想ウェブページ２７１２を編集すると、編集はサイトエリアデータベース１２４で、したがってユーザのブラウザでもリフレッシュされ得る。図２９に示すように、データグループ２７１０は、他のデータ要素の中でも、データ要素１ ２１１およびデータ要素２ ２７１８を含むことができる。データ要素１ ２１１内に、タブ１ ２９０２が表示されてもよく、データ要素２ ２７１８内に、テストタブ２ ２９０４が表示されてもよい。タブ１ ２９０２およびテストタブ２ ２９０４は、図示のように、他の要素（例えば、検索バー、ドロップダウンメニューなど）と共に仮想ウェブページ２７１２上に表示されてもよい。
タイムライン表示２９００において時間が進むと、ユーザは仮想ウェブページ２７１２を編集できる。例えば、図示のように、ユーザはテストタブ２ ２９０４を編集して、編集されたタブ２を作成できる。さらに、データグループ２７１０の一部として、新しいデータ要素３ ２９０６を仮想ウェブページ２７１２に追加することができる。仮想ウェブページ２７１２に対する編集が行われると、ライブ環境２９０８で対応する編集が行われ得る。例えば、ユーザが「公開」または「レンダリング」機能を選択すると、ライブ環境２９０８が更新されて、データグループ２７１０および仮想ウェブページ２７１２の他の態様への更新が表示され得る。例えば、実際のウェブページ２９１０の最初のバージョンには、編集されたタブ２またはタブ３が含まれない場合があるが、実際のウェブページ２９１２の後続のバージョンには、これらの更新が含まれる場合がある。様々な実施形態において、仮想ウェブページ２７１２への更新は、自動的に行われるのであっても、ユーザがリフレッシュまたは更新機能を選択すると行われるのであってもよい。さらに、ライブ環境２９０８における実際のウェブページ２９１０および２９１２への更新は、ユーザがライブ環境２９０８への遷移を（例えば、「公開」または「レンダリング」リンクを選択することにより）確認すると行われ得る。
図３０は、本開示のいくつかの実施形態による、動的プレビューシステム３０００のブロック図を示している。図３０に示すように、動的プレビューシステム３０００は、例えばデプロイ環境１５１０にウェブページが現れるときにウェブページを表示するのに役立つ。プレビューインターフェース３０１０は、ウェブページを表示するオンラインエディタインターフェース２４３内のフレームまたは他のグラフィカルインターフェースであり得る。いくつかの実施形態では、プレビューインターフェース３０１０は、オンラインエディタインターフェース２４３を示すために使用されているウェブブラウザ上で開かれた別個のタブであり得る。
プレビューインターフェース３０１０は、静的ウェブページと仮想ウェブページ（すな
わち、所与のウェブページテンプレート２７０４のインスタンス）との両方を表示するために使用され得る。プレビューインターフェース３０１０で閲覧するために生成された仮想ウェブページには、ナビゲーションインターフェース２４２が付随してもよい。プレビューインターフェース３０１０により、ナビゲーションインターフェース２４２がスクロール可能な機能を含むことができて、ユーザが、プレビューインターフェース３０１０で表示するために生成された複数の仮想ウェブページにわたってスクロールできる。ナビゲーションインターフェース２４２は、シーケンシャルナビゲーションおよび特定の仮想ウェブページへの直接アクセスの両方、ならびに検索による（例えば、特定の仮想ページを識別するために使用されるキーデータ項目の値を使用することによる）仮想ページ間のナビゲーションを可能にし得る。ナビゲーションインターフェース２４２は、特定の仮想ウェブページに直接アクセスすることができ、選択的に閲覧するためにブックマークされた仮想ウェブページをサポートすることができる。例えば、プレビューインターフェース３０１０に表示されている仮想ウェブページは、最初、最後、前または次の仮想ウェブページへのリンクを伴う場合がある。ＷＢＳ１００はまた、単なる直線的な構成だけでなく、仮想ページの他の構成もサポートしてもよい。例えば、ＷＢＳ１００は、「ツリーの上のレベルに移動する」または「現在のページより下のレベルを展開する」などの追加オプションを使用してナビゲートされ得る仮想ページの階層構成をサポートすることができる。
図３１は、本開示のいくつかの実施形態による、編集中の仮想ウェブページ３１１０のプレビューを示している。図３１に示すように、フロントエンド１２６はデータグループ２１０に関連付けられている。フロントエンド１２６に含まれる構築ツール１２１は、データグループ２１０の特定のデータ要素に関連付けられ得る。仮想ウェブページ３１１０は、フロントエンド１２６を含むインデックス可能なウェブページ１２５を表示でき、プレビューインターフェース３０１０でプレビューされ得る。いくつかの実施形態では、プレビューインターフェース３０１０は、オンラインエディタインターフェース２４３内のフレームまたは他のグラフィック表現であり得る。プレビューインターフェース３０１０では、様々な言語を使用する、アクセシビリティ要件に適合された、または特定の対象者向けになんらかの仕方で修正された、様々なモバイルおよびデスクトップデバイスに表示されるように、仮想ウェブページ３１１０をプレビューできる。
図３２は、本開示のいくつかの実施形態による、データグループとウェブサイトとの間の関係を示す概略図である。図３２に示すように、ウェブサイトの仮想ウェブページのグループ３２２０は、同じデータグループ２１０に関連付けられ得る。いくつかの実施形態では、仮想ウェブページのグループ３２２０は、１セットのデータグループ３２３０に関連付けられ得る。いくつかの実施形態では、ウェブサイトのグループ３２４０は、同じ１セットのデータグループ３２３０を共有してもよい。１セットのデータグループ３２３０を共有するウェブサイトのグループ３２４０は、同じ所有者またはオペレータを有していてもよいし、そうでなければ特定のデータグループ２１０にアクセスするための（アクセス制御メカニズムを介した）適切なパーミッションを付与されていてもよい。いくつかの実施形態では、１セットのデータグループ３２３０を共有するウェブサイトのグループ３２４０は、上述のように、同じ開発者／設計者１５４０によって構築されている場合がある。
図３２に示すように、リピータ３２１３は、ウェブページのフロントエンドに表示される構築ツールであり、デザインまたはレイアウトが繰り返される異なるセクションに異なるコンテンツ項目またはグループを表示する。いくつかの実施形態では、リピータ３２１３は、本明細書でさらに説明するように、ソフトウェアベースのルータを使用して生成された仮想ウェブページ３１１１の一部であっても、通常の（静的）インデックス可能なウェブページ１２５の一部であってもよい。リピータ３２１３は、データグループ２１０のデータ要素１ ２１１およびデータ要素Ｍ ３２１２に基づいて異なるコンテンツを表示
する。リピータは、データグループ２１０のデータグループサブセット３２１３に直接関連付けられ得る。例えば、リピータを使用して、テキストおよび画像の５つの異なるグループを作成できる。各グループは、同じ比率およびレイアウトでテキストおよび画像を自動的に配置できる。それにもかかわらず、いくつかの実施形態では、テキストおよび画像の実際のコンテンツは、各グループで異なり得る。
図３３は、本開示のいくつかの実施形態による、仮想ウェブページの生成に関与するコンポーネントを示す概略図である。図３３に示すように、ウェブページテンプレート２７０４は、インデックス可能なウェブページと同様に、データグループ２１０および他のデータグループに関連付けられ得る。上述のように、ソフトウェアベースのルータ３３１０を使用してデータグループ２１０内のデータ要素をバインドすることができ、ウェブページテンプレート２７０４に適用して仮想ウェブページ３１１１、３３１３、および３３１２を生成することができる。ソフトウェアベースのルータ３３１０は、データグループ２１０内のデータ要素を選択／フィルタリング／並べ替えして、ユーザによって送信されたＵＲＬに基づいてウェブページテンプレート２７０４および仮想ウェブページグループに適用することができる。ソフトウェアベースのルータ３３１０は、ＵＲＬプレフィックスに基づいてウェブページテンプレート２７０４を識別する。ソフトウェアベースのルータ３３１０は、ＵＲＬプレフィックスに続くＵＲＬ要素（例えば、サフィックスコンポーネント、テキストセグメント、またはパラメータ値）に基づいて仮想ウェブページを生成するために、ウェブページテンプレート２７０４に適用されるデータグループ２１０のデータ要素を識別してもよい。いくつかの実施形態では、ＵＲＬプレフィックス「ｐｒｅｆｉｘ１」は、ウェブページテンプレート２７０４のソフトウェアベースのルータ３３１０を識別する。ソフトウェアベースのルータ３３１０は、サフィックス値「ｌａｂｅｌ１」および「ｌａｂｅｌ２」に基づいて、それぞれ仮想ウェブページ３１１１および３３１２を生成できる。ソフトウェアベースのルータ３３１０は、ウェブページテンプレート２７０４と関連データグループ２１０、および他のデータグループを使用して生成され得るすべての仮想ウェブページの可能なＵＲＬをリストするサイトマッププレフィックス１サイトマップ３３１３を生成できる。プレフィックス１サイトマップ３３１３は、検索エンジン１７０により仮想ウェブページ３１１１および３３１２をインデックスするのに役立ち得る。
図３４は、本開示のいくつかの実施形態による、仮想ウェブページの生成およびプレビューに関与するステップを示すフローチャート３４００である。フローチャート３４００は、上述のシステム実施形態で実行され得るステップを表す。
図３４に示すように、ステップ３４１０において、動的プレビューシステム３０００は、サイトエリアデータベース１２４にデータ要素を格納することができる。上述のように、データ要素は、テキスト、画像、ビデオ、背景、およびこれらのオブジェクトタイプのいずれかを組み合わせから構成されるレコードなど、様々な異なる形式を取ることができる。
ステップ３４２０において、動的プレビューシステム３０００は、格納されたデータ要素をデータグループに編成することを可能にする命令を格納することができる。例えば、グループはデータベースで定義され得る。さらに、グループは、グループ内の要素間の関係、または値が他のフィールドに依存するデータ要素のフィールドによって定義され得る。上記の実施形態と整合して、視覚要素、フィールド、または特定のウェブページが定義される前に、データグループが定義され得る。
ステップ３４３０において、動的プレビューシステム３０００は、サイトエリアデータベース１２４で以前に作成されたデータグループに追加のデータ要素を追加するために、
オンラインエディタインターフェース２４３を表示するウェブブラウザにさらなる命令を提供することができる。このようにして、既存のグループを補足または編集して、異なるまたは追加の要素を含めることができる。ユーザはステップ３４２０を繰り返すことができ、いつでも戻ってデータ要素をさらに追加できる。同様に、このステップは、削除や更新など、データ要素に対して追加の操作を実行するための命令を含み得る。例えば、ユーザはステップ３４１０、３４２０、および３４３０の間を循環することもできるし、ステップ３４３０に進むこともできる。
ステップ３４４０において、動的プレビューシステム３０００は、サイトエリアデータベース１２４に格納されたデータグループの以前に挿入されたデータ要素を、オンラインエディタインターフェース２４３で編集されているウェブサイトに関連付けるのを支援する命令を実行し得る。ユーザは、ステップ３４２０を繰り返すことができ、いつでも戻って、構築中のウェブサイトのウェブページと、サイトエリアデータベース１２４に格納されたデータグループとして編成されたデータ要素との関連付けをさらに作成できる。
ステップ３４５０において、動的プレビューシステム３０００は、データ要素グループをウェブサイトのウェブページに関連付けるのを支援するための命令を提供する。これは、上述のように、フォームのフィールドを相互にリンクして、フィールドで許可されている潜在的な値をアクティブ化／非アクティブ化およびフィルタリングの両方を行うことを含み得る（例えば、住所を入力するフォームは、状態フィールドにおける選択に応じて「市」フィールド値にリストされ得る）。
ステップ３４６０において、動的プレビューシステム３０００は、オンラインエディタインターフェース３０００に命令を提供して、オンラインエディタインターフェース２４３で構築中のウェブサイトのウェブページのプレビューを可能にする。上述のように、プレビューは、ユーザがリアルタイムで編集できるようにし得る。
ユーザは、ステップ３４３０、３４４０、３４５０、３４６０を何度でも任意の順序で繰り返すことができる。
図３５は、本開示のいくつかの実施形態による、ウェブサイトホスティングシステム３５００と対話するユーザの概略図である。図３５に示すように、ウェブサイトホスティングシステム３５００は、ウェブサイトを構築および表示する１つまたは複数のシステムを含むホスティングサーバ３５１０と、プラグインコードを実行するプラグインサーバ３５２０と、プロセッサ２６０と、プラグインコンポーネントおよびコードを格納するメモリ８２０と、プラグインコードおよび他のコンポーネントを開発しアップロードするインターフェース３５７０と、を備える。
ホスティングサーバ３５１０は、共同ホストされたウェブサイト３５１１、３５１２、および３５１３をホストする１つまたは複数のサーバであり得る。ホスティングサーバ３５１０は、例えば、オンデマンドシステム８００、または別の種類のウェブサイトホスティングシステムにおけるウェブサーバ実行インスタンスであり得る。いくつかの実施形態では、ホスティングサーバ３５１０は、オンデマンドシステム８００の複数のウェブサーバ実行インスタンスであってもよい。ホスティングサーバ３５１０はまた、上述のように、開発者／設計者１５４０およびエンドユーザ１５３０によって編集およびアクセスされたウェブサイトを格納しているＷＢＳ１００であってもよい。
編集ツール４１１は、上述のように、ホスティングサーバ３５１０でホストされているウェブサイトで共有されているウェブサイトを編集するための共通ツールである。いくつかの実施形態では、編集ツール４１１は、共同ホストされたウェブサイト３５１１～３５
１３をホストする複数のホスティングサーバ３５１０にわたって共有されてもよい。
プラグインサーバ３５２０は、分離環境３５２１でプラグインコードを実行する１つまたは複数のサーバであり得る。いくつかの実施形態では、プラグインサーバ３５２０は、ホスティングサーバ３５１０と同じインフラストラクチャを使用する（これは、上述の物理サーバまたはウェブサーバ実行インスタンスであってもよい）。プラグイン３５３０はメモリ８２０に存在し、ユーザインターフェース３５３１、フロントエンドプラグインコード３５３２、およびバックエンドプラグインコード３５３３を介して表示またはアクセスできる。
ユーザ３５４０～３５６０は、ホスティングサーバ３５１０から編集ツール４１１にアクセスして、それぞれウェブサイト３５１１～３５１３を編集できる。いくつかの実施形態では、例えば、ユーザ３５４０により編集されているウェブサイト３５１１はプラグイン３５３０を含むことができる。例えば、ウェブサイト３５１１は、ウェブ閲覧デバイス１３０のウェブブラウザ１３１を使用してウェブサイト３５１１にアクセスすると、ビデオプレーヤープラグイン３５３０を介してビデオを再生できる。ユーザ３５４０がウェブサイト３５１１を変更することは、インターフェース３５７０を介したプラグインコードの編集およびアップロードを含み得る。いくつかの実施形態では、インターフェース３５７０は編集ツール４１１の一部であってもよい。
ユーザ３５４０～３５６０は、共有プラットフォーム３５８０を介してホスティングサーバ３５１０上のウェブサイト３５１１～１３と対話する。共有プラットフォーム３５８０により、ユーザのグループがウェブサイトのグループを編集できる。共有プラットフォーム３５８０は、ユーザ３５４０～３５６０のどのグループがどのウェブサイト３５１１～１３を編集するためのアクセスを有するかを判定するように構成されたソフトウェアであり得る。いくつかの実施形態では、複数のウェブサイト３５１１～１３をホストするホスティングサーバ３５１０自体が共有プラットフォーム３５８０として機能する場合がある。
エンドユーザ１５３０がウェブ閲覧デバイス１３０上のウェブブラウザ１３１を使用してウェブサイト３５１１を閲覧することには、プラグイン３５３０のユーザインターフェース３５３１が含まれ得る。例えば、プラグイン３５３０はビデオプレーヤーであり、ユーザインターフェース３５３１はビデオプレーヤープラグイン３５３０に合わせた様式にされた再生コントロールボタンを含むことができる。フロントエンドプラグインコード３５３２はまた、エンドユーザ３５４０がウェブサイトにアクセスするときにユーザインターフェース３５３１を介して渡される場合もある。エンドユーザ１５３０がプラグイン３５３０のユーザインターフェース３５３１と対話すると、プラグイン３５３０のフロントエンドプラグインコード３５３２がウェブブラウザ１３１で実行されことになり得る。いくつかの実施形態において、ウェブサイト３５１１とのエンドユーザ１５３０の対話はまた、バックエンドプラグインコード３５３３をプラグインサーバ３５２０で実行させ得る。例えば、エンドユーザ３５４０がビデオプレーヤープラグインの再生コントロールをクリックすると、フロントエンドプラグインコード３５３２が実行されて、ビデオのストリーミング要求が行われ、さらにバックエンドプラグインコード３５３３がネットワーク帯域幅の可用性に基づいてビデオを圧縮し得る。
図３６は、本開示のいくつかの実施形態による、共同ホストされたウェブサイトへの制御されたアクセスの技法を示している。図３６に示すように、ユーザ３５４０、３５５０は一緒にグループ化され、共同ホスト１ウェブサイト３５１１および３５１２へのアクセスが可能になる。ユーザ３６２１および３６２２は、共同ホスト２ウェブサイト３６１１および３６１２へのアクセスを有し得る。ユーザは、１つまたは複数の共同ホストされた
ウェブサイトにアクセスできるが、許可されたグループの一部ではないウェブサイトへのアクセスは許可されていない。ユーザは、例えば、特定のウェブサイトの所有者であるか、登録ユーザであるか、認証されているかなどに基づいて、アクセス権が定義され得る。
図３７は、本開示のいくつかの実施形態による、共通ルートの下でプラグインコードを共有する共同ホストされたウェブサイトグループを示している。図３７に示すように、ウェブホスティングシステム３５００は、２セットの共同ホストされたウェブサイトを有し、各セットはＵＲＬルートにより互いに異なる。例えば、共通ルート１の共同ホストされたウェブサイト３７１１はドメインｗｗｗ．ａ．ｃｏｍを共有でき、共通ルート２の共同ホストされたウェブサイト３７３１は、ドメインｗｗｗ．ｂ．ｃｏｍを共有できる。あるいは、共通ルート１の共同ホストされたウェブサイト３７１１は、共通サブドメインａ．ｗｉｘｓｉｔｅ．ｃｏｍを有することができ、共通ルート２の共同ホストされたウェブサイト３７３１は、共通サブドメインｂ．ｗｉｘｓｉｔｅ．ｃｏｍを有することができる。共通ルートを持つウェブサイトをホスティングサーバまたはホスティング環境で共同ホストして、分離環境を作成し、他の共同ホストされたウェブサイトのセットとのやり取りを排除することができる。共同ホストされたウェブサイトはまた、プラグインコードを実行するための分離環境を作成するための異なるプラグインサーバを有し得る。共通ルート１の共同ホストされたウェブサイト３７１１および共通ルート２の共同ホストされたウェブサイト３７３１は、同じプロセッサ２６０およびメモリ８２０をさらに共有してもよいし、異なるプロセッサおよびメモリを有してもよい。図３８は、本開示のいくつかの実施形態による、バックエンドプラグインコード３５３３の分離された実行環境を示している。図３８に示すように、プラグイン３５３０分離環境のバックエンドプラグインコード３５３３は、コンテナ（例えば、ドッカー）３８１０または仮想マシン３８２０またはオペレーティングシステムプロセス３８３０に基づいてもよい。いくつかの実施形態では、分離環境３５２１は、１つまたは複数のコンテナ３８１０、仮想マシン３８２０、およびオペレーティングシステムプロセス３８３０（例えば、サーバレスコード）を含むことができ、それぞれ別個のプラグインバックエンドコード３５３３を実行する。いくつかの実施形態では、プラグイン３５３０をホストするプラグインサーバは、複数の分離環境を含み得る。
図３９は、本開示のいくつかの実施形態による、フロントエンドプラグインコード３５３２の制御されたアクセスおよび実行を示している。図３９に示すように、ウェブサイト３５１１にアクセスすると、プラグイン３５３０のフロントエンドプラグイン１コード３５３２および別のプラグインのフロントエンドプラグイン２コード３９３１にアクセスできる。ウェブサイト３５１１は、それぞれの別個のサブ領域３９１０および３９３０でプラグインのそれぞれを確実に実行し得る。ウェブサイトホスティングシステム３５００はまた、ウェブサイトの他の特定のサブ領域にのみアクセスできるようにするために、安全な通信チャネル（例えば、ＳＳＬ、セキュアトンネルなど）を作成することもできる。安全な通信チャネルにより、フロントエンドプラグインのウェブサイトの他のサブ領域へのアクセスが制限され得る。例えば、サブ領域３９１０で実行されるフロントエンドプラグイン１コード３５３２は、別のサブ領域３９２０と通信できるが、サブ領域３９４０へのアクセスが拒否され得る。プラグインのアクセス可能なサブ領域は、表形式、信頼できるレジストリ、構成ファイル、または安全なデータベースでリストされ得る。例えば、クラウドコンピューティングベースの構成では、クラウドオーケストレータプラットフォームが、仮想コンピューティングリソース（例えば、サブ領域３９１０、サブ領域３９２０、サブ領域３９４０など）のリストまたはマッピングを維持することができ、それらの接続パーミッションを定義することができる。そのようなリストまたはマッピングは、サブ領域３９１０、サブ領域３９２０、およびサブ領域３９４０による特定の接続またはアクションを許可し、他の接続またはアクションを拒否し得る。いくつかの実施形態では、すべての通信が１つまたは複数のハブ（例えば、認証または認可確認を実行するハブ）を通過
できるようにすることにより、安全な通信チャネルが提供される。このようなハブは、例えば、システムクライアント、システムサーバ、またはその両方に常駐することができる。通信を開始するサブ領域の一意の識別子を確認することによっても、安全な通信を確立することもできる。例えば、ｇｅｔＩｄ（）メソッド呼び出しを使用して、通信メッセージの発信元サブ領域ＩＤを識別し、許可リストまたはマッピングに含まれているか否かを判定できる。
図４０は、本開示のいくつかの実施形態による、プラグインコードのクライアントサイドの分離した実行を示している。図４０に示すように、エンドユーザ１５３０によってウェブブラウザ１３１を使用してアクセスされるウェブサイト３５１１は、プラグイン３５３０のフロントエンドプラグインコード３５３２へのアクセスをもたらし得る。エンドユーザ１５３０アクセスにより、フロントエンドプラグインコード３５３２を単独で実行するためのｉｆｒａｍｅが作成され得る。いくつかの実施形態では、フロントエンドプラグインコード３５３２は、単独で実行するためにウェブサイト３５１１の異なるサブ領域３７１２～３７１３にコピーされ得る。例えば、ウェブサイト３５１１には、それぞれ異なるビデオストリームをストリーミングしているが同じプラグインコードを使用している、複数のビデオプレーヤーが表示され得る。いくつかの実施形態では、Ｉｆｒａｍｅで実行されるプラグインコード３５３２～３５３３は、クライアントサイドのクッキー（例えば、ＨＴＴＰクッキー）へのアクセスを持たない場合がある。
図４１は、本開示のいくつかの実施形態による、ウェブサイトおよびプラグインコードへのアクセスおよび実行に関与するステップを示すフローチャートである。図４１に示すように、ステップ４１１０において、ウェブサイトホスティングシステム３５００は、共通のホストサーバまたはサーバのセット内で１つまたは複数の共通データ要素、テンプレート、コードの一部、ルート、または他の機能を共有するウェブサイトをホストする。サーバはまた、複数のユーザの所有権または管理特権および編集特権に基づいて共同ホストされ得る。例えば、ウェブサイトホスティングシステム３５００は、複数の独立した提携なしのエンティティまたは個人によって作成および管理されるウェブサイトをホストし得る。
ステップ４１２０において、ウェブサイトホスティングシステム３５００は、編集ツール４１１へのアクセスを提供して、システムにより共同ホストされるウェブサイトをさらに編集する。上述のように、編集ツール４１１により、ユーザはウェブサイトの様々な態様を編集できる。
ステップ４１３０において、編集目的でウェブサイトにアクセスするためのユーザの取り組みにより、ウェブホスティングシステム３５００は、要求を行うユーザがウェブサイトを編集するためのアクセス権または特権を持っているか否かを評価する。評価は、特定のウェブサイトの所有権に依存し得る。いくつかの実施形態では、ウェブサイトの所有者または管理者は、編集ツール４１１を使用して他のユーザに管理者および／または編集アクセスを提供することができる。さらに、いくつかの実施形態では、編集権は、ユーザが登録ユーザであるか、ウェブホスティングシステム３５００にアクセスするために認証されているか否かに依存し得る。
ステップ４１３０の答えが「いいえ」の場合、ウェブサイトへの要求されたアクセスは拒否され、ユーザはウェブサイトの管理者に編集権限を要求する必要があり得る。プロセス４１００は、ウェブサイトを編集するためのアクセスを取得できなかった場合に完了したと見なされる。あるいは、プロセス４１００は、ステップ４１２０または４１３０に戻って循環してもよい。
ステップ４１３０に対する答えが「はい」である場合、プロセス４１１０はステップ４１５０に進む。ステップ４１５０において、プラグインをアップロードするためのインターフェースが、ウェブサイトを編集するためのアクセスを要求するユーザに提示される。インターフェースは、ユーザがフロントエンドまたはバックエンドコードを編集するための上で説明したインターフェースと同様であってもよい。
ステップ４１６０において、ウェブサイトホスティングシステム３５００はプラグインの変更を受信して格納する。ユーザがアップロードしたプラグインは、例えば、プラグイン３５３０のバックエンドプラグインコード３５３３への編集を含み得る。いくつかの実施形態では、ユーザ編集は、プラグイン３５３０のフロントエンドプラグインコード３５３２への編集を含み得る。あるいは、ユーザはまた、プラグイン３５３０のユーザインターフェース３５３１を編集することもできる。いくつかの実施形態では、ユーザは、ユーザインターフェース３５３１、フロントエンドプラグインコード３５３２、およびバックエンドプラグインコード３５３３のすべてを編集することができる。
ユーザ編集プラグインコード（例えば、フロントエンドプラグインコード３５３２またはバックエンドプラグインコード３５３３）は、複数のセッションにわたってプラグインコードを編集して、ステップ４１２０～４１６０ならびにそれよりも少ないまたは多いステップの繰り返しを可能にし得る。
ステップ４１７０において、ウェブホスティングシステム３５００は、ウェブサイト３５１１がユーザ（例えば、エンドユーザ１５３０、３５４０、３５５０、３５６０）によってアクセスされたときにプラグイン３５３０を実行する。プラグインコードの実行は、コードを実行するための分離環境３５２１の作成を含む。分離環境３５２１は、フロントエンド３５３２およびバックエンド３５３３プラグインコード３５３０をそれぞれ実行するために、ウェブブラウザのクライアントサイドとサーバサイドとの分離を含み得る。
図４２は、本開示のいくつかの実施形態による、ウェブページを編集し、データベースコレクションを作成するための例示的なユーザインターフェースである。例えば、ウェブページは、ＷＩＸ．ＣＯＭが提供するようなウェブサイト開発システムを介して生成され得る。図示のように、１つまたは複数の動的ウェブページをサポートするデータベースを作成できる。
サイト構造サイドバー４２０２は、様々なページ（例えば、ホーム、大学、イベント、奨学金、学生エリア、学位別コース、およびニュース）のリストなど、ウェブサイトを編集および構成するための様々なオプションと、パブリック機能、バックエンド機能、およびデータベース機能のためのオプションと、を含み得る。さらに、ツールバー４２０４は、ウェブページ上でコンテンツを追加および編集するための様々なオプションを含むことができる。
図示のように、インターフェース４２０６により、ユーザはデータベースを構成できる。インターフェース４２０６は、例えば、ユーザがサイト構造サイドバー４２０２から「データベース」オプションを選択した場合に生成され得る。ユーザは、フィールド４２０８において一意の名前を付けてデータベースをカスタマイズできる。この例では、データベースは「コース」データベースと呼ばれ得る。
図４３は、本開示のいくつかの実施形態による、ウェブページを編集し、データベースコレクションのためのパーミッションを構成するための例示的なユーザインターフェースである。例えば、上記の例を続けると、「コース」データベースを作成するユーザは、データベースおよびそれに基づき得る対応する動的ページの様々な異なるパーミッション４
３１０オプションにアクセスできる。パーミッション４３１０は、ウェブページのコンテンツ、フォームへのデータ入力、ページのユーザにより生成されたコンテンツ、登録メンバーに限られるコンテンツ、登録メンバーのみが完了できるフォーム、および特定のユーザ（例えば、管理者）のみがアクセスできる特定のプライベートデータに対処し得る。
図４４は、本開示のいくつかの実施形態による、ウェブページおよびデータベースコレクションにおけるエントリを編集するための例示的なユーザインターフェースである。例えば、「コース」データベースは、フィールド４４１２（タイトル）、４４１４（説明）、４４１６（画像）、４４１８（講義担当者）などから構成され得る。これらのフィールドは、データベースから抽出され、特定の動的ウェブページに含めることができるコースに関する情報を含み得る。特に、フィールドは、テキストコンテンツ（例えば、フィールド４４１２、４４１４、および４４１８）と、画像やビデオなどの他のコンテンツ（例えば、フィールド４３１６）と、を含み得る。図示のように、フィールド４４１６は、ＴＩＮＧというタイトルのコースに対応する画像を含む。いくつかの実施形態では、ユーザは、各動的ウェブページの種類またはレイアウトをさらに定義し、各動的ページにＵＲＬを指定することができる。例えば、ＵＲＬのサフィックスは、データベースの列（例えば、タイトル）に対応し得る。
図４５は、本開示のいくつかの実施形態による、ウェブページを編集し、データベースコレクションからの出力を表示するための例示的なユーザインターフェースである。例えば、作成された動的ウェブページには、データベースからのコンテンツが含まれ得る。図示のように、コンテンツ４５２０は、データベースからのコースの説明を含む。コンテンツ４５２０は、ユーザが手動でウェブページにコピーすることを必要とすることなく、データベースから自動的に抽出される。この技法を使用して多数の動的ページを作成でき、それぞれがデータベースの異なる部分にリンクし、データベースへのリンクに基づいてコンテンツの一意の構成を有することができる。
図４６は、本開示のいくつかの実施形態による、ウェブページを編集し、リピータ機能を作成するための例示的なユーザインターフェースである。上記のように、リピータ機能をウェブサイトまたはページに追加して、構造またはレイアウトが類似した要素の２つ以上のインスタンス（例えば、テキストと画像との組み合わせ）を作成できる。リピータを使用すると、少なくとも１つの点で異なる（例えば、異なるテキスト、画像などを持つ）要素の２つ以上のインスタンスを作成できる。
図示のように、ユーザはリピータを構成するためにリピータメニュー４６２２にアクセスできる。例えば、ツールバー４２０４を使用して、ユーザはリスト＆グリッドオプションを選択でき、これにより、リピータおよび複数のオブジェクトを表示する他の様々な要素を作成できる。リピータインスタンスにコンテンツを投入するために、ユーザはリピータまたは個々のインスタンスをデータベースに格納されているデータなどのデータセットにリンクできる。いくつかの実施形態では、ユーザは、インスタンスのそれぞれに同様に要素を１つ追加することを決定してもよい。１つのインスタンスに要素を追加すると、各インスタンスに要素が自動的に追加される。あるいは、ユーザは、リピータによって作成された各インスタンスが異なるコンテンツを持つように指定しようとしてもよい（例えば、バックエンドまたはフロントエンドコードを通じて）。
図４７は、本開示のいくつかの実施形態による、ウェブページを編集し、リピータ機能の結果を示すための例示的なユーザインターフェースである。図示のように、ユーザは、リピータを介して要素４７２４の３つの組み合わせを作成している。各組み合わせ４２４７は、画像、テキスト（地名）、テキスト（説明）、および「続きを読む」ハイパーリンクアイコンという同様の構造を持つ。編集モードでは、ユーザは、例えば、テキスト要素
に対する画像の位置を変更したり、ハイパーリンクを変更したり、フィールドのサイズを変更したりすることにより、これらのインスタンスのレイアウトおよび外観をさらに編集できる。さらに、上述のように、インスタンスの各要素はデータベースの異なる部分に接続できる。例えば、要素４７２４の３つの組み合わせは、データベースからそれぞれ抽出すべきコンテンツに対応するデータベース内の異なる列にそれぞれリンクすることができる。このようにして、要素４７２４の３つの組み合わせは共通のレイアウトを有するが、それぞれが異なるテキストまたはグラフィックコンテンツを有する。
本明細書では、ソフトウェアコードまたは命令として実装または定義され得る様々な動作または機能が説明されている。このようなコンテンツは、直接実行可能（「オブジェクト」または「実行可能」形式）、ソースコード、または差分コード（「デルタ」または「パッチ」コード）とすることができる。本明細書で説明される実施形態のソフトウェア実装は、コードまたは命令が格納された製品を介して、または通信インターフェースを介してデータを送信する通信インターフェースを動作させる方法を介して提供され得る。機械またはコンピュータ可読記憶媒体は、説明された機能または動作を機械に実行させ、記録可能な／記録不可能な媒体（例えば、読み取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスク記憶媒体、光学記憶媒体、フラッシュメモリデバイスなど）など、機械（例えば、コンピューティングデバイス、電子システムなど）によってアクセス可能な形式で情報を格納する任意のメカニズムを含む。通信インターフェースは、メモリバスインターフェース、プロセッサバスインターフェース、インターネット接続、ディスクコントローラなど、別のデバイスと通信するための有線、無線、光学などの媒体のいずれかとインターフェースする任意のメカニズムを含む。通信インターフェースは、構成パラメータを提供すること、および／またはソフトウェアの内容を記述するデータ信号を提供するように通信インターフェースを準備するように信号を送信することによって構成され得る。通信インターフェースは、通信インターフェースに送信される１つまたは複数のコマンドまたは信号を介してアクセスされ得る。
本開示はまた、本明細書の動作を実行するためのシステムに関する。本システムは、必要とされる目的のために特別に構築されてもよいし、コンピュータに格納されたコンピュータプログラムによって選択的に起動または再構成される汎用コンピュータを備えてもよい。そのようなコンピュータプログラムは、限定されないが、フロッピーディスク、光ディスク、ＣＤＲＯＭ、および磁気光学ディスク、読み取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気カードもしくは光カード、またはコンピュータシステムバスにそれぞれ接続される電子命令を格納するのに適した任意の種類の媒体を含む任意のタイプのディスクなどのコンピュータ可読記憶媒体に格納されてもよい。
本開示の実施形態は、コンピュータ実行可能命令で実装されてもよい。コンピュータ実行可能命令は、１つまたは複数のコンピュータ実行可能コンポーネントまたはモジュールに編成されてもよい。本開示の態様は、そのようなコンポーネントまたはモジュールの任意の数および編成で実装されてもよい。例えば、本開示の態様は、特定のコンピュータ実行可能命令、または図示され、かつ本明細書で説明される特定のコンポーネントもしくはモジュールに限定されない。他の実施形態は、本明細書で図示および説明されるよりも多いまたは少ない機能を有する異なるコンピュータ実行可能命令またはコンポーネントを含むことができる。
本明細書の書面による説明および方法に基づくコンピュータプログラムは、ソフトウェア開発者のスキルの範囲内にある。様々なプログラミング技法を使用して、様々なプログラムまたはプログラムモジュールを作成できる。例えば、プログラムセクションまたはプログラムモジュールは、ＪａｖａＳｃｒｉｐｔ、Ｓｃａｌａ、Ｐｙｔｈｏｎ、Ｊａｖａ（
登録商標）、Ｃ、Ｃ＋＋、アセンブリ言語、または任意のそのようなプログラミング言語、ならびにデータ符号化言語（ＸＭＬ、ＪＳＯＮなど）、クエリ言語（ＳＱＬなど）、プレゼンテーション関連言語（ＨＴＭＬ、ＣＳＳなど）およびデータ変換言語（ＸＳＬなど）を使用して設計され得る。そのようなソフトウェアセクションまたはモジュールのうちの１つまたは複数を、コンピュータシステム、非一時的なコンピュータ可読媒体、または既存の通信ソフトウェアに組み込むことができる。
「含む（ｃｏｍｐｒｉｓｉｎｇ）」、「持つ（ｈａｖｉｎｇ）」、「含む（ｃｏｎｔａｉｎｉｎｇ）」、「含む（ｉｎｃｌｕｄｉｎｇ）」、および他の同様の形の単語は、これらの単語のいずれか１つに続く１つまたは複数の項目が、このような１つまたは複数の項目の限定的な列挙を意味していない、または列挙された１つまたは複数の項目にのみ限定されることを意味していないという点で、意味において均等であり、非限定的であるとして解釈されることが意図されている。加えて、単数形「ａ」、「ａｎ」、および「ｔｈｅ」は、文脈上明らかな別段の指示のない限り、複数の指示対象を含むことが意図されている。
実施形態の態様を詳細に説明してきたが、添付の特許請求の範囲で定義される本発明の態様の範囲から逸脱することなく修正および変形が可能であることは明らかである。本発明の態様の範囲から逸脱することなく、上記の構造、製品、および方法に様々な変更を加えることができるため、上記の説明に含まれ、添付の図面に示されているすべての事項は、限定的な意味ではなく例示的な意味で解釈されるものとすることが意図されている。
技術的背景
ウェブサイトホスティングおよびウェブサイト構築システムのためのオンデマンドウェブサーバ実行インスタンス
もくじ
ウェブサイトおよびステートレスサービングアーキテクチャ １
本発明のシステム ２
従来のシステムおよび本発明のシステムのユースシナリオ ３
ＷＢＳコンテキストにおける本発明のシステムの使用 ５
使用されている頭字語 ６
ウェブサイトおよびステートレスサービングアーキテクチャ
１．ユーザがウェブサイトと対話する場合、ユーザは、通常、ＢＥコードやウェブサーバとやり取りするのではなく、クライアントサイドページ、ウェブアプリケーション、およびクライアントマシン／ブラウザで実行されるＦＥコードと多くの時間対話する。しかしながら、このクライアントサイドのウェブサイト／アプリケーションは、依然として複数のＨＴＴＰ（または他の）サーバ要求を行う。これらには、例えば次のものが含まれ得る。
１．１．ページをロードするために行われた最初のＨＴＴＰ要求。これは、さらなるＨＴＴＰ要求をトリガして、さらなるページ要素（含まれている画像やスクリプトなど）をロードし得る。
１．２．セッション中のＨＴＴＰ要求。例えば、フィールドのための値を選択するとき、ページはＨＴＴＰ要求を行って、所与のフィールドのための１セットの可能な値を取得する。
１．３．ユーザが入力したフォームの送信など、データ関連のＨＴＴＰ要求。
１．４．ＢＥ機能をアクティブ化するＢＥ関連のＨＴＴＰ要求。これは、ウェブサイトを提供するシステムまたは外部（サードパーティ）ウェブサービスを使用して実行され得る。
２．このコンテキストにおける「サーバ」は、実際の物理サーバを指す場合もあるが、
ＶＭやコンテナ（ドッカーとしても知られる）などの他のウェブサイトサーバ実行インスタンスを指す場合もある。本文書を通して説明されているＨＴＴＰ要求はまた、ＨＴＴＰＳ要求または任意の他のネットワーク要求を指す場合もある。
３．ユーザは、要求を行ってから最初の応答を受信するまでのシステム（クライアント＋サーバ＋通信媒体）の応答が非常に迅速であることを期待している。応答時間は、多くの場合、「要求を受信してから最初の応答バイトを送信するまでのサーバサイドの時間」として測定される（通常は１００ミリ秒以下と期待される）。サーバサイドの時間の測定を用いるのは、変動しやすいネットワーク転送時間を考慮から外すためである。
４．実際に応答を完了するには、かなりのさらなる時間がかかる場合がある。例えば、新しいページをロードするとき、ユーザはブラウザにページがすぐに表示され始めることを期待するが、ページのロードにはかなりのさらなる時間がかかる場合があり、ユーザはページが完全にロードされていなくてもページの操作を開始する場合もある。
５．これらに対してサーバシステム（通常は複数のサーバまたはサーバファームで構成される）は、ステートレスまたはステートフルシステム／プロトコルを使用して応答し得る。ＨＴＴＰプロトコルは本質的にステートレスであるが、ステートフルサーバの使用はプロトコル外の技法（ＵＲＬの書き換えや非表示のフォームフィールドなど）を使用して実装され得ることに留意されたい。
６．ステートフルシステムは、通常、クライアントが事前に割り当てられたサーバとやり取りするときに使用される。このようなサーバは連続的なセッションコンテキストを提供できるが、この構成をスケールアップするのは非常に困難である。なぜなら、サーバが（１人または複数の）ユーザに連続的に関連付けられている必要があり、次のＨＴＴＰ要求の到着を待機してアイドル状態または部分的にアイドル状態になり得るためである。
７．ステートレスシステムでは、各ＨＴＴＰ要求は、単一のページからのものでさえも、異なるサーバ（またはサーバ実行インスタンス）によって処理され得る。異なるＨＴＴＰ要求に対する異なるサーバ間での「ジャンプ」はユーザに気づかれることはなく、これらの異なるサーバは、応答に必要な外部リソース（データベースサーバなど）に透過的にアクセスできる。
８．ステートレスシステム、すなわちステートレスサーバを使用するシステムには多くの利点がある。特に、到来する要求はシステム内の任意の（ステートレス）サーバに差し向けられるために、システムは高度にスケーラブルであり、切れた接続に対して特別な処理を行う必要はない。
９．既存のシステムの（複数の）ステートレスサーバは完全に交換可能である必要があるため、特定のウェブサイトまたは関連するページに適合させることはできない。よって、このような構成は、単純で静的なウェブサイトに適している。サイト固有のＢＥコード（場合によりユーザ提供コードを含む）、サイト固有のコンポーネント、またはサイト固有のプラグインを必要とする複雑なウェブサイトを提供する場合、この構成はうまく機能しない。
本発明のシステム
１０．本明細書で説明されるように、本発明のシステムは、（サイトのための特定のプラグインおよびサーバサイドのユーザ提供コードを含む）特定のサイトのために構成されたウェブサーバインスタンスを実行し、かつこの実行を、タイムアウトなしで、またユーザが許容できる合計時間枠内でＨＴＴＰ要求に応答するのに十分な速さで行う、ドッカーコンテナ（またはウェブサイトサーバ実行インスタンス）の高速ブートを含む。
１１．通常、新しい仮想マシンの起動には数分かかる。新しいドッカーコンテナの起動には依然として２～３秒かかる。これらの時間は両方とも許容可能ではない。
１２．本開示のシステムでは、すべての関連するサイト固有ではないコードを含むがユーザ／サイト固有のコードを含まないスタンバイコンテナのプールが提供され得る。
１３．本システムは、特定のウェブサイトのためのサーバに接続する要求をライブポートでリッスンし得る。特定のウェブサイトに関連付けられているライブコンテナがある場
合、本システムはそれに接続し得る。それ以外の場合は、上記プールからのスタンバイコンテナを使用し、要求されたサイト固有のコンテンツをプールに投入するか、そのようなコンテンツをロードするように命令することができる。所与のサイトのためのサイト固有のコンテンツがロードされると、コンテナは所与のサイトに関連付けられたコンテナのプールに加わる。
１４．このようなステートレスコンテナインスタンスは、ＨＴＴＰ要求をロードしている元のページを処理したインスタンスとなることなく、特定のＨＴＴＰ要求（例えば、データ確認を含む）を処理することができることに留意されたい。
１５．投入されたサイトレベルのコンテンツは、実際のサイトページを含んでいても含んでいなくてもよい。このようなサイトページ情報は、例えば次のとおりであり得る。
１５．１．実際のブラウザ対応のページマテリアル（例えば、ＨＴＭＬ、ＣＳＳ、およびＪＳコードのコレクション）。
１５．２．クライアントサイドまたはサーバサイドのコード（ＷＢＳビューアモジュールなど）によってブラウザ対応マテリアルに変換される基礎となるサイト定義データ（例えば、ＸＭＬファイルまたはＪＳＯＮ表現）。
１５．３．フロントエンド／バックエンドコード、例えば、クライアント、サーバ、またはその両方で実行するためにページによって呼び出されるＪａｖａＳｃｒｉｐｔコード。
１６．サイトが所与の期間（１５分など）アクティブでない場合、本システムはスタンバイコンテナをドロップし得る。
１７．ユーザの状態を保持し、ユーザが（連続的なコンテキストを有する）単一のセッション内で作業しているというユーザの感覚を保つために、クライアントサイドストレージ（例えば、ブラウザのローカルストレージ、クッキーなど）とサーバサイドのストレージ（例えば、サーバＤＢへの保存）との組み合わせを使用して永続的コンテキストが保持される。
従来のシステムおよび本発明のシステムのユースシナリオ
１８．次の典型的なユースシナリオを仮定する。
１８．１．ユーザがブラウザにＵＲＬページを入力し、ページのロードを要求する。ロードされたページは、データ入力フォームを含み、かなりの量の関連する（サイトレベル固有の）ＦＥおよびＢＥコードを有する。ページおよびそのサイトレベルで関連付けられたＦＥコードを取得するために、ＨＴＴＰ要求がサーバに対して行われる一方で、ＢＥコードはサーバにロードされるが、クライアントには送信されない。サイトはまた、独自のＵＩ、ＦＥコード、およびＢＥコードを持ついくつかのコンポーネント（ディスプレイウィジェットなど）を使用する。
１８．２．ユーザは１０分間にわたってフォームに入力し、通常、＜ｆｏｒｍ＞ＨＴＭＬタグを有するローカルページを実行するブラウザでローカルに作業する。これはまた、Ａｊａｘ呼び出しまたはＦｅｔｃｈ呼び出し、またはＨＴＴＰ要求を開始できるＪａｖａＳｃｒｉｐｔもしくはＨＴＭＬセットアップを使用して行うこともできる。
１８．３．フォームは、サーバに送信されるいくつかの要求をこの間に行い得る（例えば、所与のフィールドに関するＤＢからの許可された値のリストを取得する）。これらの要求のそれぞれが、実際のＤＢアクセスおよび情報収集を行うサーバサイドＢＥスクリプトをアクティブにする（例えば、コード内のＤＢアクセスクレデンシャルをクライアントに送信することを回避するため）。このような要求は、ＨＴＴＰ要求として実装されてもよいし、異なるメカニズムを使用して実装されてもよい。
１８．４．ユーザがフォームを送信すると、フォームはＦＥスクリプトによって確認される。次いで、フォームはサーバに送信され、関連するＢＥコードを実行するサーバプロセスをアクティブにし、これにより（例えば）フォームがデータベースに保存され得る。
１９．上記のシナリオでは、ユーザのアクティビティは、ＨＴＴＰ要求または他のメカ
ニズムを使用して、１０分間にわたる間に（例えば）２０個の要求を生成し得る。これらの要求の多くは、サイト固有のＢＥスクリプトまたはコンポーネント固有のＢＥスクリプト（サイトで使用されるコンポーネント用）をアクティブにする。
２０．従来のステートレス／ステートフル技術は、このシナリオを次のように処理する。
２０．１．ステートフルサーバを使用する場合、場合により中間要求（上記の「フィールドＸのための値のリストを取得する」など）を処理することを除いて、何もしていなくても、１０分後になる場合がある記入を終えたフォームの送信まで、フォームを含むページを最初に提供したサーバは実行し続けなければならない。
２０．２．従来のステートレスサーバ技術は、（所与のサイトに固有のコードを含む）特定のＨＴＴＰ要求ごとにサーバを、またはＶＭやコンテナでさえも適時にコールドスタートすることはできなかった。よって、特定のＢＥ機能を持たないサイトをサポートするか、フォーム入力セッション中ずっと特定のサーバインスタンスを実行し続けなければならなかった（よって、実際にはステートレスではない）。
２１．本発明の技術を使用すると、ステートレスサーバインスタンス（例えば、コンテナ）が割り当てられて、特定のＨＴＴＰ要求のそれぞれ（ページのロード、フィールドＸのための値のリストの取得、記入されたフォームのＤＢへの保存）を処理する。これにより、サーバ時間の使用量が、１０分間のフォーム入力セッションの間中である代わりに、（例えば）２０個の要求処理時間（例えば、２０×２００ミリ秒＝４秒）になる。割り当てられたサーバは、（サイト固有の要素が投入された）新しいコンテナまたは既存の利用可能なサイト適応コンテナであり得る。
２２．よって、同じユースシナリオにおいて、本発明のシステムでは、使用するサーバリソースを従来のシステムよりも大幅に少なくでき、サーバを必要とするのは１０分ではなく（１０分のほとんどの時間、サーバインスタンスはアイドル状態であるが、特定のユーザからの要求を依然として待機している）４秒だけである。
２３．これにより、ウェブサイトホスティングプロバイダは、非常に少量のリソース（サーバ、コンテナなど）を使用して同じレベルのサービスを提供できる。
２４．ちなみに、ユーザはフォームに対してローカルで作業しているため、ユーザがブラウザウィンドウを閉じて再び開くと、通常は（部分的に入力されたフォームではなく）空のフォームが表示される。本発明のシステムは、フォームのコンテンツをブラウザのローカルストレージに保持できるＡＰＩを提供し得る。よって、ユーザが部分的に入力されたフォームウィンドウを閉じて再び開くと、再び開かれたフォームには以前に入力された値が含まれる。これはまた、ブラウザが完全に閉じている場合にも機能する。
２５．同様に、ＢＥタスクは、例えば、（サーバサイドの）サーバＤＢにコンテキスト情報を保存することにより、またはクライアントにより維持され、かつ後続のＢＥ呼び出しに渡される情報を提供することにより、相互にコンテキスト情報を依然として提供できる。このような情報は、セッション期間のみであっても、（例えば、ブラウザのローカルストレージを使用して）必要に応じて存在し続けるのであってもよい。
２６．また、特定のコンポーネントコードおよび関連するＦＥ／ＢＥスクリプトの投入は、通常、特定のページレベルの粒度ではなくサイト全体（すなわち、サイト内のすべてのページで使用されるすべての特別なコンポーネントおよびスクリプト）に対して行われることにも留意されたい。このように、このサイトに関する新しいＨＴＴＰ要求が（同じユーザまたは他のユーザから）到着するたびに、投入されたコンテナがサイト内のあらゆるページで再利用され得る。
２７．しかしながら、本システムは、一方では投入される「マテリアル」の量に応じて、他方ではその使用パターンに応じて、異なるレベルの粒度を実装し得る。よって、本システムは、（例えば）ページ、ページグループ（すなわち、サイトセクション）、サイト、またはサイトグループの投入粒度レベルを実装し得る。例えば、多数のサイトが非常に類似しており、共通の関連コンポーネントおよびスクリプトを使用する場合、サイトグループのケースが関連し得る。このように、サイトグループに固有のコンテンツが投入され
たコンテナを再利用して、１つのサイトだけでなく、グループ内の任意のサイトへの要求を処理できる。
ＷＢＳコンテキストにおける本発明のシステムの使用
２８．オンラインＷＢＳは２つの使用モードを有することを特徴とする。
２８．１．サイトの編集－サイト定義（例えば、ＸＭＬ／ＪＳＯＮデータ、またはＤＢレコード、または実際のＨＴＭＬページマテリアル）は、通常、サーバサポートのあるブラウザで実行される視覚的エディタアプリケーションによって編集される。このようなサイトは、ＦＥコードおよびＢＥコード（エディタで編集可能でもあり得る）、ならびにサイトに必要な特定のコンポーネント（例えば、サードパーティアプリケーション）を含み得る。エディタはまた、プレビューモードでサイトを呼び出すこともできる。エディタはまた、外部ユーザが使用するためにあるバージョンのサイトを公開する公開操作もサポートし得る。
２８．２．ＲＴ（ランタイム）モード－必要に応じてＦＥまたはＢＥコードをアクティブにしながら、システムがユーザに公開されたサイトを提供する。
２９．上述の本発明のシステムは、システムの編集モードおよびＲＴモードの両方で使用され得る。
３０．編集モードで動作する場合。
３０．１．編集されたサイトコンテキストは以下を含む。
３０．１．１．完全なサイト定義（ページ、コンポーネント、および関連データ）は、通常、エディタクライアントによってクライアントサイドのメモリ内構造として保持される（例えば、ＪＳＯＮ表現として）。
３０．１．２．サイトのＦＥコード。
３０．１．３．サイトのＢＥコード。
３０．２．実際のエディタコード（クライアントにロードされるエディタＦＥコードおよびサーバで実行されるエディタＢＥコード）は、システムの（コンテナにプリロードされた「一般セクション」における）一般的なコードの一部である。
３０．３．サイトのＪＳＯＮ／ＦＥサイトコード／ＢＥサイトコードはＤＢに保持される（ユーザが明示的に保存する場合）。
３０．４．ＦＥ／ＢＥコードの一時的な保存は限られているため、ユーザは「移動」先のコンテナを介して同じコードの編集を続行できる。このことは、サイトのＦＥ／ＢＥコードはサイトのＪＳＯＮコードの一部ではないために必要とされる。
３１．プレビューを実行するときに使用することができ、さらにエディタが（大きい場合がある）サイトコード全体をロードしなくてもよいように、サイトコードはＤＢに保持されるが、編集中または現在のページに関連する関連セクションのみであることに留意されたい。
３２．ランタイムモードで動作する場合、本システムは通常のウェブサイトの提供について上述したように動作する。ＷＢＳは、（ＷＢＳで編集されるすべてのサイトで必要とされる）ビューアモジュールを有することができ、このようなモジュールは、起動されたサーバ／コンテナインスタンスにプリロードされたシステムの一般的なコードの一部である。
３３．よって、本発明のシステムは、編集およびＲＴの両方でＷＢＳにより使用され得る。
使用されている頭字語
ＢＥ：バックエンド
ＦＥ：フロントエンド
ＶＭ：仮想マシン
ＷＢＳ：ウェブサイト構築システム
ホーム＞Ｗｉｘコード＞Ｗｉｘコードの基本
サイト構造サイドバーを使う
Ｗｉｘコードリソースセンターにアクセスし、さらに学びましょう。
サイト構造サイドバーには、ページ、ライトボックス、ファイル、データベースコレクションなど、サイトを構成するすべてのファイルが表示されます。このサイドバーを使用すると、以下に詳述するように、サイトに影響を与える様々なアクションを実行できます。
Figure 2024075645000002
・サイドバーを非表示にするには、エディタの左下にある非表示アイコンをクリックします。
・サイドバーを表示するには、エディタの左下にある表示アイコンをクリックします。
ページ
サイドバーのページセクションには、サイトの通常ページ、動的ページ、およびルータページのすべてが一覧表示されます。通常ページは、ページセクションのタイトルのすぐ下に表示されます。動的ページおよびルータページはサブグループに表示されます。
通常ページ
サイトの通常ページは、ページセクションのタイトルのすぐ下に表示されます。ページの設定を変更するには、ページ名にカーソルを合わせると表示される設定アイコンをクリックします。サイトのホームページ以外の任意のページを動的ページとして設定できます。
動的ページ
新しい動的ページをグループに追加するには、セクション名にカーソルを合わせると表
示される設定アイコンをクリックします。
ＵＲＬやＳＥＯデータなどのページの設定を変更するには、動的ページ名にカーソルを合わせると表示される設定アイコンをクリックして、動的接続を除去して動的ページを通常ページにするか、動的ページを削除します。
ルータページ
ルータを作成してある場合、そのルータのプレフィックスに関連付けられているすべてのページが一緒に同じセクションにグループ化されます。例えば、ｍｙｒｏｕｔｅｒというプレフィックスでルータを作成した場合、セクションの名前はＭｙｒｏｕｔｅｒ Ｐａｇｅｓ（Ｒｏｕｔｅｒ）になります。
個々のルータページには、ルータのコードで使用されるデフォルト名が付けられます。必要に応じて名前を変更できます。ページ名はページ訪問者には見えません。
ルータのプレフィックスおよびｒｏｕｔｅｒｓ．ｊｓファイルに実装されている関連する関数の名前を変更するには、または新しいページをルータに追加するには、ルータセクション名にカーソルを合わせたときに表示される設定アイコンをクリックします。
ページの設定を変更したり、名前を変更したり、削除したり、ルータから除去して通常のページにするには、ルータページ名にカーソルを合わせたときに表示される設定アイコンをクリックします。
新しいルータを追加するには、ページセクションヘッダにカーソルを合わせると表示されるプラスアイコンをクリックします。
ライトボックス
サイトのページにライトボックスを追加してある場合、サイドバーのライトボックスセクションに表示されます。このセクションは、サイトに少なくとも１つのライトボックスを追加した場合にのみ表示されます。
新しいライトボックスを追加するには、エディタの［追加］メニューを使用します。
サイドバーで既存のライトボックスを選択すると、エディタはライトボックスモードに入ります。
サイドバーのパブリックセクションには、サイトからパブリックにアクセスできるファイルが含まれます。パブリックで使用するＪａｖａＳｃｒｉｐｔファイルおよびテキストファイルを作成することができ、これらのファイルをフォルダに整理できます。ページおよびサイトコードもパブリックにアクセス可能ですが、パブリックセクションには表示されません。
ページおよびサイトコードを編集するには、コードパネルを使用します。
新しいファイルまたはフォルダをパブリックセクションに追加するには、セクション名にカーソルを合わせると表示されるプラスアイコンをクリックします。
新しいファイルや新しいフォルダを追加したり、フォルダを削除したりするには、フォルダ名にカーソルを合わせると表示される設定アイコンをクリックします。
ファイル名を変更したりファイルを削除したりするには、ファイル名にカーソルを合わせると表示される設定アイコンをクリックします。
バックエンド
サイドバーのバックエンドセクションには、サイトからパブリックにアクセスできないファイルが一覧表示されます。バックエンドセクションは、サーバサイドで実行するコードを配置する場所です。バックエンドで使用するＪａｖａＳｃｒｉｐｔファイル、ウェブモジュール、およびテキストファイルを作成することができ、これらのファイルをフォルダに整理できます。
サイトのバックエンドセクションには、２つの特別なＪａｖａＳｃｒｉｐｔファイルが存在する場合があります。ｄａｔａ．ｊｓファイルにはデータフックのためのコードが含まれ、ｒｏｕｔｅｒｓ．ｊｓファイルにはルータおよびデータバインディングルータフッ
クのためのコードが含まれます。
新しいファイルまたはフォルダをバックエンドセクションに追加するには、セクション名にカーソルを合わせると表示されるプラスアイコンをクリックします。
新しいファイルや新しいフォルダを追加したり、フォルダを削除したりするには、フォルダ名にカーソルを合わせると表示される設定アイコンをクリックします。
ファイル名を変更したりファイルを削除したりするには、ファイル名にカーソルを合わせると表示される設定アイコンをクリックします。
データベース
新しいコレクションを追加するには、セクション名にカーソルを合わせると表示されるプラスアイコンをクリックします。
コレクションに基づいて新しい動的ページを追加したり、コレクションのパーミッションを更新したり、コレクションを除去したりするには、コレクション名にカーソルを合わせると表示される設定アイコンをクリックします。
関連するコンテンツ
動的ページについて
ライトボックスについて
データベースコレクションについて
ルータについて
データバインディングルータフックについて
ホーム＞Ｗｉｘコード＞Ｗｉｘコードの基本
コードパネルを使う
・Ｗｉｘコードリソースセンターにアクセスし、さらに学びましょう。
・この記事を全画面表示するにはここをクリックしてください。
エディタの下部に表示されるコードパネルでサイトのコードを編集します。コードパネルには、特別なツールバーとサイトの様々な要素のためのコードを含む２つのタブとがあります。また、コードを使用する方法や場所に応じて、いずれかのタブに任意の他のコードを追加することもできます。
ヒント：
コードパネルをページの下部から上にドラッグするだけで開くことができます。
エディタ内の要素は、特定のページまたはサイトのすべてのページに表示できます。特定のページのみに関連するコードを追加することも、すべてのサイトページに関連するコードを追加することもできます。コードパネルの左側にはページおよびサイトの２つのタブがあります。
・ページ：ページタブには、特定のページに表示される要素のためのコードが含まれています。プロパティパネルを使用して要素にイベントを追加すると、そのイベントのコードは自動的にページタブに配置されます。特定のページのみに関連するコードがある場合は、ここに追加します。
・サイト：ある要素がすべてのサイトページに表示され、サイト全体で一貫性のある機能をその要素に対して追加するには、そのコードをサイトタブに追加します。プロパティパネルを使用してすべてのページに表示される要素にイベントを追加すると、そのイベントのコードは自動的にサイトタブに配置されます。サイトのすべてのページに関連するコードがある場合は、ここに追加します。
すべてのページに表示される要素があり、１つのページに固有のコードをその要素に対して追加する場合は、そのページのページタブにコードを追加します。
Ｗｉｘコードの構文およびオートコンプリート
特定の要素を選択する
Ｗｉｘコードでは、標準のＪａｖａＳｃｒｉｐｔを使用してコーディングできます。また、Ｗｉｘコードには、ページ上の要素を選択するための特定の構文または規則のセットがあり、それは次のとおりです。
Figure 2024075645000003
ｊＱｕｅｒｙをご存知であれば見慣れたものであるはずです。ご存知でなくても、知っておくべきなのは次のことになります。
要素を選択するには、
１．＄ｗと入力します。
２．要素名を括弧および引用符で囲みます。
３．要素名の前にハッシュタグを付けます。
注意：
引用符は、単一引用符も二重引用符も使用できます。
Figure 2024075645000004
／／すべきこと：ページに関連するコードをここに記述します。
上下の矢印キーを使用して目的の要素を選択し、Ｅｎｔｅｒキーを押します。あるいは、リスト内の要素をクリックすることもできます。要素への参照は、必要なすべての構文と共にコードに追加されます。
ヒント：
・Ｃｔｒｌ＋スペースを押せばいつでもコード補完ポップアップを表示できます。
・要素名では大文字と小文字とが区別されます。「＃Ｂｕｔｔｏｎ１」は「＃ｂｕｔｔｏｎ１」と同じではありません。
・パブリックにｎｅｗ．ｊｓファイルを追加すると、最後にアクセスしたページの要素がコード補完によりリストされます。
要素名を見るには、要素にカーソルを合わせるか要素を選択します。プロパティパネルで任意の要素の名前を変更できます。
複数の要素を選択する
名前で複数の要素を選択するには、上記と同じ構文を使用して要素を参照し、次のよう
に各要素をカンマで区切ります。
Figure 2024075645000005
特定の種類のすべての要素を選択する
特定の種類のすべての要素を選択するには、次のように、ハッシュタグなしで要素の種類名を使用します。
要素の種類名は、ＷｉｘコードＡＰＩに表示される要素名です。
ＪａｖａＳｃｒｉｐｔテンプレート
Ｗｉｘコードに直接関連するオートコンプリートに加えて、コードパネルには標準のＪａｖａＳｃｒｉｐｔテンプレートおよびキーワードのためのオートコンプリートも含まれています。例えば、「ｆｏｒ」という単語を入力すると、オートコンプリートリストには「ｆｏｒ文」のテンプレートおよび「ｆｏｒ」というキーワードが含まれます。各テンプレートには、標準ＪａｖａＳｃｒｉｐｔ ＡＰＩへのリンクが含まれており、そこで詳細な情報を参照できます。
Figure 2024075645000006
ＪａｖａＳｃｒｉｐｔテンプレートを選択すると、テンプレートの完全な構文がコードパネルに追加されます。例えば、「ｆｏｒ文」を選択すると、次のテンプレートがコードに追加されます。
Figure 2024075645000007
後は、ループ内で実行するコードを追加するだけです。
参照する前に要素が読み込まれていることを確認する
＞ｏｎＲｅａｄｙに関する高度な情報
ページがブラウザに読み込まれると、ページの読み込みが終わる前にページのコードが実行される場合があります。その場合、ページが読み込まれる前にコードがページ内の要素を参照しようとしたときにエラーが発生する可能性があります。
Figure 2024075645000008
／／すべきこと：ページに関連するコードをここに記述します。
これが必要になるのは、＄ｗセレクタを使用して独自にコードを追加する場合だけです。プロパティパネルを使用して関数に追加したコードは、ページが読み込まれた後にのみ実行されます。
要素を使う
エディタ内のすべての要素には、プロパティ、メソッド、およびイベントハンドラがあり、これらを使用して、要素を使ったり、サイトに機能を追加したりできます。
要素を選択した後にピリオドを入力すると、これらのアイテムの全一覧が表示されます。
Figure 2024075645000009
／／すべきこと：ページに関連するコードをここに記述します。
上下の矢印キーを使用して目的のアイテムを選択し、Ｅｎｔｅｒキーを押します。必要な構文が要素セレクタの後に追加されます。オプションの下には、機能の簡単な説明が表示されます。「続きを読む」リンクをクリックすると、さらなる情報が表示されます。
オートコンプリートポップアップには、要素で呼び出すことができる標準のＪａｖａＳｃｒｉｐｔメソッドも含まれています。
Figure 2024075645000010
プロパティ
プロパティには、要素に関する情報が含まれています。これらの一部は読み取り専用ですが、値を設定できるものもあります。
例えば、テキスト要素にはｉｓＶｉｓｉｂｌｅプロパティがあり、要素が実際に画面上に表示されるか否かを返します。このプロパティは読み取り専用です。テキスト要素には、テキスト要素の現在のテキストを含むｔｅｘｔプロパティもあります。これは、読み取りおよび設定の両方が可能なプロパティです。
メソッド
メソッドは、要素に対してアクションを実行します。
例えば、ボタン要素には、サイトにボタンが表示されないようにするｈｉｄｅメソッドがあります。
一部のメソッドには、アクションの発生の仕方に影響する追加オプションがあります。例えば、次のように括弧内で指定することにより、ｈｉｄｅメソッドにアニメーションを追加できます。
Figure 2024075645000011
ここでも、すべてのオプションを知るには、ＷｉｘコードＡＰＩを見る必要があります。
イベントハンドラ
イベントハンドラは、要素がユーザアクション（イベント）に応答できるようにします。要素にイベントハンドラを追加する場合、イベントが発生したときに何を実行するかを指定することも必要になります。
例えば、「ツアーに参加する」というボタンがある場合を考えます。訪問者がボタンにカーソルを合わせると、テキストが「さあ行こう」に変わるように機能を追加しようとしています。その場合、次のようなコードをサイトに追加することになります（コードの各部分を説明するコメントを追加してあります）。
Figure 2024075645000012
／／ｏｎＭｏｕｓｅＩｎはイベントハンドラです。
／／コールバック関数はここから始まります。
／／これは、イベントが発生したときに実行されるコードです。
／／コールバック関数はここで終わります。
プロパティパネルを使用してイベントハンドラを要素に追加することもできることをお忘れなく。イベントハンドラを手動で追加する特別な理由がない限り、プロパティパネルを使用することをお勧めします。
警告およびエラー
コードパネルでコードを書いているときに、警告やエラーが表示される場合があります。警告は黄色で表示され、エラーは赤で表示されます。これらは、関連するコードの下に色付きの波線が表示される形で、また行番号の左側にアイコンが表示される形を取ります。
警告またはエラーメッセージを表示するには、アイコンにカーソルを合わせます。
警告
コードにおける警告は、変更した方がいいかもしれないコードに注意を促す情報メッセージです。警告はコードの実行を停止することはなく、多くの場合安全に無視できます。警告は黄色の三角形および黄色の波線で引かれた下線で表示されます。
Figure 2024075645000013
／／ここに関数をコーディングします
よくある警告メッセージは「ｒｅｔｕｒｎ」の後に不要な「ｅｌｓｅ」がある場合に現れます。これは、次のコーディングパターンを使用する場合に最もよく発生します。
Figure 2024075645000014
／／何かをする
／／他の何かをする
ｓｏｍｅＣｏｎｄｉｔｉｏｎがｔｒｕｅの場合、関数は戻ります。つまり、ｓｏｍｅＣｏｎｄｉｔｉｏｎがｔｒｕｅの場合にコードの実行を停止するのにｅｌｓｅは必要ないということです。
この警告は安全に無視することもでき、コードを次のパターンに変更することもできます。
Figure 2024075645000015
／／何かをする
／／他の何かをする
エラー
コードにエラーがあるということは、コードが適切に機能しないことを意味します。エラーの種類によっては、コードが期待どおりに機能しなかったり、まったく実行されなかったりする場合があります。サイト訪問者が使用できるようにサイトを公開する前に、コード内のすべてのエラーを必ず修正してください。
Figure 2024075645000016
次に示すのは、コードにエラーが見つかることがある一般的な状況です。
・エラーメッセージ：「＃ｔｅｘｔ１」は有効なセレクタではありません（上の画像を参照）
注意：検索と置換機能を使用して、コード全体にわたってこのエラーを修正できます。
・エラーメッセージ：「インポート」および「エクスポート」は最上位レベルでのみ表示されます。
ＡＰＩモジュールをインポートする場合、モジュールが使用される前にコードの最上位にｉｍｐｏｒｔ文が表示される必要があります。つまり、次のように関数内にモジュールをインポートすることはできません。一般的に、あらゆる変数宣言および関数定義の前に、コードの最初の行にすべてのｉｍｐｏｒｔ文を配置することをお勧めします。
Figure 2024075645000017
・場合によっては、エラー表示は実際の誤りの箇所で表示されずに、誤りによりエラーが生じる最初の行に表示されます。例えば、ページコードの関数のうちの１つで終わり波括弧（｝）を忘れた場合、コードのちょうど次の行でエラーが発生する可能性が高くなります。以下に示すコードでは、６行目に終わり波括弧がありませんが、エラーは８行目まで発生しません。
Figure 2024075645000018
メディアマネージャの組み込み
Ｗｉｘコードでは、Ｗｉｘメディアマネージャに保存した画像をコードで使用できます。ｓｒｃなどの画像プロパティを含む要素を使う場合、ポップアップウィンドウが開き、
Figure 2024075645000019
コードをテストする
コードは公開されたサイトで実行されますが、公開する前にコードをテストして、期待どおりに動作することを確認することをお勧めします。
公開する前にコードをテストするには、サイトをプレビューします。サイト内のコードは、プレビューモードでも、公開バージョンとまったく同じように実行されます。公開されたサイトでコードをデバッグすることもできます。
コードのバージョンを保存する
保存すると、対応するコードがサイトのそのバージョンと共に保存されます。サイト履歴に移動して、サイトの保存したバージョンに戻すと、そのバージョンで保存されたコードも復元されます。
関連するコンテンツ
ＷｉｘコードでＪａｖａＳｃｒｉｐｔを使う
Ｗｉｘコードを使用してコードをテストおよびデバッグする
ホーム＞Ｗｉｘコード＞データベースコレクション
データベースコレクションについて
Ｗｉｘコードリソースセンターにアクセスし、さらに学びましょう。
サイトのデータベースはいくつかのコレクションで構成されています。各コレクションは、スプレッドシートのようなデータのテーブルと考えることができます。テーブルの各行は、コレクション内のアイテムを表します。テーブルの各列はフィールドを表します。したがって、各アイテムには、コレクションの列によって定義されるフィールドが含まれます。
例えば、次のコレクションには４つのフィールドおよび５つのアイテムが含まれています。
Figure 2024075645000020
新しいコレクションを作成する
１．サイト構造サイドバーで、データベースセクション名にカーソルを合わせて、プラスアイコンをクリックします。
２．コレクションに名前を付けます。後で名前を変更できないことにご注意ください。
３．デフォルトでは、「サイトコンテンツ」コレクションパーミッションプリセットが選択されています。これにより、誰でもコンテンツを見ることができますが、作成者だけがコンテンツを追加、修正、および削除できます。ドロップダウンをクリックして、別のプリセットを選択したり、カスタムパーミッションを定義したりすることができます。パーミッションは後で更新できます。
４．完了したら、［コレクションを作成］をクリックします。
コレクションを編集する
データベースのそれぞれのコレクション内には、データのサンドボックスバージョンおよびライブバージョンが存在します。
エディタのコンテンツマネージャでサンドボックスバージョンを編集し、ダッシュボードでライブバージョンを編集します。画面上部の［ライブデータの編集］リンクをクリックすると、ダッシュボードのコンテンツマネージャに移動します。
通常フィールド
コレクションの各フィールドには、フィールド名、フィールドキー、およびフィールドタイプがあります。
Figure 2024075645000021
フィールド名
フィールド名は、コンテンツマネージャの列の先頭に表示されるラベルです。フィールド名は、エディタでページ要素をデータセットに接続するときにも使用されます。
例えば、テキスト要素をコレクションからのフィールドに接続するときは、テキスト接続パネルのフィールド名を使用します。
Figure 2024075645000022
コンテンツマネージャで新しいフィールドを追加するときに、フィールド名を指定します。フィールドの作成後にフィールド名を変更すると、そのフィールドへのすべての接続が更新されます。
フィールドキー
フィールドキーは、データＡＰＩまたはデータセットＡＰＩを使用してコード内のフィールドを参照するときに使用されます。
例えば、データＡＰＩを使用してアイテムを挿入するには、フィールドキーを使用します。
コンテンツマネージャで新しいフィールドを追加すると、フィールド名に基づいてフィールドキーが自動的に作成されます。必要に応じて独自のフィールドキーを指定できます。
重要：
フィールドの作成後にフィールドキーを変更することはできません。
フィールドタイプ
フィールドタイプは、フィールドに含まれるデータの種類を定義します。コンテンツマネージャで新しいフィールドを追加するときに、次のフィールドタイプのうちの１つを選択します。フィールドタイプのサポートおよび制限についてはこちらをお読みください。
・参照
・テキスト
・画像
・ブーリアン
・数値
・日付および時刻
・リッチテキスト
・ＵＲＬ
・文書
フィールドタイプは、コレクションのフィールドにページ要素を接続するときにも使用されます。特定の入力要素は、関連するフィールドタイプのフィールドにのみ接続できます。例えば、テキスト要素をテキストまたはＵＲＬフィールドに接続できますが、画像フィールドには接続できません。
コンテンツマネージャでは、間違ったフィールドタイプの新しい値を追加することはできませんが、ＣＳＶファイルからインポートされたデータまたはコードを介して追加されたデータは検証されません。例えば、数値フィールドにテキスト値をインポートできます。この場合、コンテンツマネージャにエラーが表示されます。
参照フィールドタイプを使用して、参照コレクションのプライマリフィールドからアイテムを選択します。詳しくは、「参照フィールドを作成するには」を参照してください。
注意：
プライマリフィールド
すべてのデータベースコレクションにはプライマリフィールドがあり、コンテンツマネージャではフィールド名の横にあるロックアイコンで示されます。デフォルトでは、タイトルフィールドはプライマリフィールドですが、コレクション内の任意の他のテキストフィールドを、ＩＤシステムフィールドを除くプライマリフィールドに設定できます。
参照フィールドに情報を入力する場合、参照したコレクションのプライマリフィールドの値から選択します。参照したコレクションのプライマリフィールドを変更すると、参照フィールドに表示される値は、新しいプライマリフィールドの値と一致するように変化します。各アイテムがプライマリフィールドで一意の値を有するようにすることをお勧めします。
詳しくは、「参照フィールドについて」を参照してください。
システムフィールド
すべてのデータベースコレクションには、次に示すデフォルトフィールドが含まれています。これらは編集できず、デフォルトでは非表示になっています。
Figure 2024075645000023
ＩＤフィールドの値は、データＡＰＩを使用してアイテムを追加するとき、またはＣＳＶファイルから新しいデータをインポートするときに割り当てることができます。後で変更することはできません。それ以外のすべての場合で、これらのフィールドの値は自動的に生成され、変更できません。
計算されたフィールド
動的ページを作成すると、動的ページがデータをプルするコレクションに新しいフィールドが追加されます。このフィールドには、動的ページのプレフィックスとページにバインドされるデータを判定するフィールドの値とを含む計算されたＵＲＬが含まれます。
例えば、タイトルフィールドに基づいて料理コレクションからのアイテムを表示する動的アイテムページがあるとします。コレクションには、／Ｄｉｓｈｅｓ／ｐｉｚｚａおよび／Ｄｉｓｈｅｓ／ｃｈｅｃｋｅｎなどのＵＲＬを持つ料理（タイトル）というフィールドがあります。
訪問者が動的ページに行くと、ページのＵＲＬに一致するＵＲＬを持つコレクションのすべてのアイテムがページのデータセットにバインドされます。
動的アイテムページの場合、各アイテムには一意のＵＲＬがあります。動的カテゴリペ
ージの場合、複数のアイテムがＵＲＬを共有します。
計算フィールドのコンテンツを編集することはできません。しかしながら、動的ページのＵＲＬを変更すると、それに応じてコレクション内のＵＲＬも変更されます。コレクションに基づいて複数の動的ページを作成する場合、コレクションには動的ページごとに１つの計算されたフィールドを持ちます。
詳しくは、「計算されたフィールドについて」を参照してください。
パーミッションモデルを使用すると、コレクション内のデータの操作を許可されている訪問者と許可されている操作とを管理できます。
パーミッションはコレクションごとに設定されます。どのユーザロールがどのアクションを実行できるかを判定するパーミッションを割り当てます。例えば、コメントコレクションに関してサイトメンバに作成パーミッションを付与しながらも、別のコレクションではアイテムを作成できないようにすることができます。
詳しくは、「データベースコレクションのパーミッションについて」を参照してください。
データのインポートおよびエクスポート
コレクションからＣＳＶファイルにデータをエクスポートでき、ＣＳＶファイルからコレクションにデータをインポートできます。
下記の記事をご参照ください。
・サンドボックスとライブデータについて
関連するコンテンツ
データベース構造を使えるようにする
フィールドタイプを変更する
参照フィールドについて
コレクションのパーミッションについて
コンテンツマネージャにコレクションデータをインポートするには
サンドボックスデータとライブデータについて
コレクションからフィールドを削除する
計算されたフィールドについて
動的ページについて
コンテンツマネージャでコレクションデータをエクスポートするには
ホーム＞Ｗｉｘコード＞アドバンスト
ルータについて
Ｗｉｘコードリソースセンターにアクセスし、さらに学びましょう。
Ｗｉｘコードを使用することにより、サイトに到来する要求を処理する場合に完全に管理を行えるルータを作成できます。これを行うには、指定されたプレフィックスを持つすべての到来する要求を受け取るようにルータを設定し、そのプレフィックスを持つ要求を受け取ったときに実行するロジックを定義します。実行するアクション、返す応答、要求をルーティングする場所、ページに渡すデータを決定します。
ルータを使用して次のことができます。
・任意のデータソースからのコンテンツを使用して動的ページを表示する。
・ＵＲＬをカスタマイズして、より意味のあるものにし、ＳＥＯの結果を改善する。
・ユーザを認証し、ユーザ専用のコンテンツを表示する。
・カスタムＨＴＴＰ応答コードを返す。
ルータのＡＰＩ参照はこちらを参照してください。
ＵＲＬプレフィックス
ルータを作成する場合、指定したＵＲＬプレフィックスに基づいて、どの要求をルータ
で処理するかを選択します。そのＵＲＬプレフィックスを持つすべての到来する要求が、処理のためにルータに送信されます。ＵＲＬプレフィックスはまた、ルータ名としても使用されます。
プレフィックスは、次の例で太字で示されているＵＲＬの一部です。
・プレミアムサイト：ｈｔｔｐｓ：／／ｄｏｍａｉｎ．ｃｏｍ／ｐｒｅｆｉｘ／ｃａｔｅｇｏｒｙ／ｉｔｅｍ
・無料サイト：ｈｔｔｐｓ：／／ｕｓｅｒ．ｗｉｘｓｉｔｅ．ｃｏｍ／ｙｏｕｒｓｉｔｅ／ｐｒｅｆｉｘ／ｃａｔｅｇｏｒｙ／ｉｔｅｍ
ルーティングロジックはｒｏｕｔｅｒｓ．ｊｓファイルで定義されます。このファイルは、サイト構造サイドバーのバックエンドセクションにあります。ルータへのエントリポイントである２つの主な機能があります。
これらは、次の規則にしたがって命名されます。
・＜ｒｏｕｔｅｒ ｐｒｅｆｉｘ＞＿ｒｏｕｔｅｒ（ｒｅｑｕｅｓｔ）
・＜ｒｏｕｔｅｒ ｐｒｅｆｉｘ＞＿ｓｉｔｅｍａｐ（ｓｉｔｅｍａｐＲｅｑｕｅｓｔ）
ｒｏｕｔｅｒ（）
ｒｏｕｔｅｒ（）関数では、定義されたプレフィックスを持つページ要求が送信されます。ルータは、到来する要求に関する情報を含むＷｉｘＲｏｕｔｅｒＲｅｑｕｅｓｔオブジェクトを受け取ります。次に、関数は要求の処理方法を決定し、適切なＷｉｘＲｏｕｔｅｒＲｅｓｐｏｎｓｅを返します。通常、ｒｏｕｔｅｒ（）関数は、表示するページ（存在する場合）とページに渡すデータとを決定します。次に、ｆｏｒｂｉｄｄｅｎ（）関数、ｎｏｔＦｏｕｎｄ（）関数、ｏｋ（）関数、ｒｅｄｉｒｅｃｔ（）関数、またはｓｅｎｄＳｔａｔｕｓ（）関数を使用して応答が送信されます。
ｓｉｔｅｍａｐ（）
ｓｉｔｅｍａｐ（）関数では、サイトマップ要求が処理されます。この関数を使用して、検索エンジンがルータのページへのリンクを確実に見つけられるようにします。各ＷｉｘＳｉｔｅｍａｐＥｎｔｒｙには、ＵＲＬ、タイトル、名前など、ページに関する情報が含まれています。
ｓｉｔｅｍａｐ（）関数はまた、アイテムプレビューウィジェットに入力するためにも使用され、プレビューモードでＵＲＬを切り替えることができます。
ルータデータ
ｒｏｕｔｅｒ（）関数は、ルーティング先のページにデータを送信することを選択できます。フロントエンドページコードでそのデータにアクセスするには、ｗｉｘ－ｗｉｎｄｏｗモジュールのｇｅｔＲｏｕｔｅｒＤａｔａ（）関数を使用します。
関連するコンテンツ
ルータを作成する
ホーム＞Ｗｉｘコード＞アドバンスト
ルータを作成する
ルータを作成することにより、サイトに到来する要求を処理する場合に完全に管理できます。
この記事では、ルータを機能させるために記述する必要があるかコードを説明します。ルータとは何か、またルータを作成するべき理由についての詳細は、「ルータについて」を参照してください。
ルータを追加する
ルータを追加するには：
１．サイト構造サイドバーのページセクションヘッダにカーソルを合わせると表示されるプラスアイコンをクリックし、［ルータを追加する］を選択します。
２．ルータのＵＲＬプレフィックスを入力し、［コードの追加と編集］をクリックします。指定されたＵＲＬプレフィックスを持つすべての到来する要求が、処理のためにルータに送信されます。
ルータを追加する場合には：
・ルータのｒｏｕｔｅｒ（）関数およびｓｉｔｅｍａｐ（）関数は、単純なルーティングシナリオのサンプルコードと共にｒｏｕｔｅｒｓ．ｊｓファイルに追加されます。ｒｏｕｔｅｒｓ．ｊｓファイルは、サイト構造サイドバーのバックエンドセクションにあります。
・ページの下の新しいセクションもルータのために作成されます。セクションには、前に選択したプレフィックスを使用して名前が付けられ、始めるためのページが１ページ含まれています。例えば、ルータに「ｍｙＲｏｕｔｅｒ」という名前を付けた場合、ｍｙＲｏｕｔｅｒ－ｐａｇｅという名前のページを持つＭｙＲｏｕｔｅｒ Ｐａｇｅｓ（Ｒｏｕｔｅｒ）セクションが追加されます。
サンプルシナリオ
ｒｏｕｔｅｒｓ．ｊｓファイルに追加されるサンプルコードには４つのパートがあります。
３．ｒｏｕｔｅｒ（）関数
４．ｓｉｔｅｍａｐ（）関数
ｉｍｐｏｒｔ文
ルータを作成するために使用される機能は、ルータＡＰＩに含まれています。この機能を使用するには、これをインポートする必要があります。デフォルトでは、ｏｋ（）関数とｎｏｔＦｏｕｎｄ（）関数、およびＷｉｘＲｏｕｔｅｒＳｉｔｅｍａｐＥｎｔｒｙオブジェクトがインポートされています。
Figure 2024075645000024
ルータＡＰＩからの機能をさらに使用する場合は、それをｉｍｐｏｒｔ文に追加する必要があります。
サンプルデータ
サンプルシナリオでは、ルータはｐｅｏｐｌｅＤａｔａという名前のオブジェクトに含まれる静的データを使用します。
Figure 2024075645000025
ルータでは静的データを使用できますが、通常はサイトのデータベースまたは外部ソースからのデータを使用します。そのデータを取得するためのコードをどこで記述するかについては、後ほど説明します。
データをどこから取得するかに関係なく、データを処理するコードを記述するため、データは任意の方法で構造化できます。
ルータ関数
ルータの作成時に指定したＵＲＬプレフィックスを持つすべての到来する要求は、処理のためにルータに送信されることに注意してください。ｒｏｕｔｅｒ（）関数で、これらの要求を処理します。
ｒｏｕｔｅｒ（）関数は、次の規則にしたがって命名されます。
Figure 2024075645000026
そのため、ルータにｍｙＲｏｕｔｅｒという名前を付けた場合、ｒｏｕｔｅｒｓ．ｊｓファイルに追加されるコードは次のようになります。
Figure 2024075645000027
／／コードをルーティングします。
ｒｏｕｔｅｒ（）関数には、到来する要求に関する情報を含むＷｉｘＲｏｕｔｅｒＲｅｑｕｅｓｔオブジェクトを受け取る要求パラメータがあります。オブジェクトには、ルータに到達するために使用されるＵＲＬ、要求の送信場所、要求の送信者に関する情報が含
まれています。
通常、ｒｏｕｔｅｒ（）関数は、表示するページ（存在する場合）とページに渡すデータとを決定します。次に、ｆｏｒｂｉｄｄｅｎ（）関数、ｎｏｔＦｏｕｎｄ（）関数、ｏｋ（）関数、ｒｅｄｉｒｅｃｔ（）関数、またはｓｅｎｄＳｔａｔｕｓ（）関数を使用して応答が送信されます。
ｒｏｕｔｅｒ（）関数のサンプルコードを見てみましょう。
Figure 2024075645000028
／／名前でアイテムデータを取得する
／／ＳＥＯタグを定義する
／／アイテムページをレンダリングする
／／アイテムが見つからない場合は４０４を返す
ｒｏｕｔｅｒ（）関数は、要求のパスを解析して名前の値を引き出すことから始まります。
Figure 2024075645000029
例えば、ユーザはｈｔｔｐｓ：／／ｍｙｓｉｔｅ．ｃｏｍ／ｍｙＲｏｕｔｅｒ／Ａｓｈをブラウズしてこのｒｏｕｔｅｒ（）関数に到達できます。受信したＷｉｘＲｏｕｔｅｒＲｅｑｕｅｓｔオブジェクトのパスプロパティは、１つの要素［”Ａｓｈ”］を持つ配列になります。ここでは名前の値は「Ａｓｈ」です。
次に、ｒｏｕｔｅｒ（）関数は、受け取った名前に基づいてデータを取得します。
Figure 2024075645000030
上記の例を続けると、ｐｅｏｐｌｅＤａｔａオブジェクトからＡｓｈの情報を引き出します。
したがって、データは次のようになります。
Figure 2024075645000031
外部ソースからデータを取得する場合には、ここでそのデータを取得するための呼び出しを行います。
到来する要求に対応するデータの取得を試みた後、データが見つかったかどうかを確認します。
Figure 2024075645000032
何も見つからなかった場合、ｉｆはスキップされ、ｎｏｔＦｏｕｎｄ（）関数を使用して４０４エラーを返します。
Figure 2024075645000033
探しているデータが見つかったと仮定して、ここでページのためのヘッダデータを準備します。
Figure 2024075645000034
サンプルコードは、取得したデータオブジェクトのタイトルプロパティに基づいてタイトルおよび説明を作成します。また、ｎｏＩｎｄｅｘをｆａｌｓｅに設定します。これは、検索エンジンがページをインデックスすべきであることを意味します。最後に、いくつかのメタタグプロパティも追加されます。
必要な情報を用いてＨｅａｄＯｐｔｉｏｎｓオブジェクトを作成できます。
ページのキーワードを含む文字列を使用して、ＨｅａｄＯｐｔｉｏｎｓオブジェクトにキーワードプロパティを追加することもできます。
最後に、ｏｋ（）関数を使用してＷｉｘＲｏｕｔｅｒＲｅｓｐｏｎｓｅオブジェクトを返します。
Figure 2024075645000035
ここで、ユーザを「ｍｙＲｏｕｔｅｒ－ｐａｇｅ」という名前のルータページにルーティングし、取得したデータとそのページ用に構築されたｓｅｏＤａｔａとを渡します。
状況に応じて、ｒｏｕｔｅｒ（）関数からいくつかの異なる応答を返すことができます。これまで、ｎｏｔＦｏｕｎｄ（）関数およびｏｋ（）関数が使用されているのを見てきました。また、ｆｏｒｂｉｄｄｅｎ（）関数を使用して４０３応答を返す、またはｒｅｄｉｒｅｃｔ（）関数を使用して３０１もしくは３０２応答を返す、またはｓｅｎｄＳｔａｔｕｓ（）関数を使用して選択したステータスコードで応答を返すこともできます。
ルータデータ
ｏｋ（）関数を使用してＷｉｘＲｏｕｔｅｒＲｅｓｐｏｎｓｅで返されたデータを使用するには、ｗｉｘ－ｗｉｎｄｏｗのｇｅｔＲｏｕｔｅｒＤａｔａ（）関数を使用します。
例えば、サンプルルータコードによって渡されたデータを取得し、それを使用して、作成されたｍｙＲｏｕｔｅｒ－ｐａｇｅページに個人の情報を表示できます。
まず、個人のタイトルおよび画像のためのプレースホルダとして機能するテキストおよび画像要素を追加する必要があります。
Figure 2024075645000036
ページをプレビューすると、ページに配置したプレースホルダに、ページに渡されたデータからの情報が入力されていることがわかります。プレビューウィジェットを使用して、ｒｏｕｔｅｒｓ．ｊｓファイルで定義されたｐｅｏｐｌｅＤａｔａオブジェクト内の人物のうちのいずれかのためのページの様子を確認できます。
プレビューウィジェットには、ルータのｓｉｔｅｍａｐ（）関数によって返されるＷｉｘＲｏｕｔｅｒＳｉｔｅｍａｐＥｎｔｒｙオブジェクトからのタイトル値が入力されます。
サイトマップ関数
ｒｏｕｔｅｒ（）関数と同様に、ｓｉｔｅｍａｐ（）関数は、次の規則にしたがって命名されます。
Figure 2024075645000037
そのため、ルータにｍｙＲｏｕｔｅｒという名前を付けた場合、ｒｏｕｔｅｒｓ．ｊｓファイルに追加されるコードは次のようになります。
Figure 2024075645000038
／／コードをルーティングします。
ｓｉｔｅｍａｐ（）関数には、到来する要求に関する情報を含むＷｉｘＲｏｕｔｅｒＳｉｔｅｍａｐＥｎｔｒｙオブジェクトを受け取るｓｉｔｅｍａｐＲｅｑｕｅｓｔパラメータがあります。オブジェクトには、ルータに到達するために使用されるＵＲＬ、ルータ内のページ、要求の送信者に関する情報が含まれています。
通常、ｓｉｔｅｍａｐ（）関数は、ルータが使用するデータのアイテムごとにＷｉｘＲｏｕｔｅｒＳｉｔｅｍａｐＥｎｔｒｙオブジェクトを作成します。そのため、この例では、ｐｅｒｓｏｎＤａｔａオブジェクトの各人物のエントリを作成します。インデックスページや検索ページなど、他のページのエントリを含めることもできます。
Figure 2024075645000039
／／データをサイトマップエントリに変換します。
／／Ｗｉｘエディタにおけるページの名前
／／ページの相対ＵＲＬ
／／より良いＳＥＯのために－Ｇｏｏｇｌｅの助けとなるように
／／サイトマップエントリを返します。
ｓｉｔｅｍａｐ（）関数はｐｅｏｐｌｅＤａｔａオブジェクトのキーを取得し、ＪａｖａＳｃｒｉｐｔのｍａｐ（）関数を使用してＷｉｘＲｏｕｔｅｒＳｉｔｅｍａｐＥｎｔｒｙオブジェクトの配列を、キーごとに１つのオブジェクトとなるように作成します。各エントリには、ｐａｇｅＮａｍｅプロパティ、ｕｒｌプロパティ、およびｔｉｔｌｅプロパティの値が与えられます。次に、配列はＰｒｏｍｉｓｅにラップされて返されます。
サイトマップエントリには、ｃｈａｎｇｅＦｒｅｑｕｅｃｙプロパティ、ｌａｓｔＭｏｄｉｆｉｅｄプロパティ、およびｐｒｉｏｒｉｔｙプロパティを含むことができて、検索エンジンに各ページに関するより多くの情報を提供することもできます。
外部データでルータを使用している場合、ｓｉｔｅｍａｐ（）関数でそのデータを取得し、取得した各アイテムのサイトマップエントリを構築します。
関連するコンテンツ
ルータについて
ホーム＞Ｗｉｘコード＞アドバンスト
ＳＥＯおよびルーティング
ルータページのＳＥＯ設定は、通常ページの設定とわずかに異なります。ＷｉｘページのＳＥＯについてはこちらをご覧ください。
通常ページの場合と同様に、ルータページのページタイトル、説明、ソーシャルネットワーク画像を定義できます。違いは、ルータページには静的データが含まれておらず、ＳＥＯ情報を動的に設定する必要があるため、表示されたときに保持している実際のコンテンツを反映することです。
ルータページでＳＥＯを設定するには２つのパートがあります。
・Ｇｏｏｇｌｅがページについて学習するためのメタタグを作成する。
・Ｇｏｏｇｌｅがページを見つけるのに使用するためのサイトマップを作成する。
メタタグ
ルータのｒｏｕｔｅｒ（）関数を作成するときに、ルータのページにＳＥＯメタタグを設定します。その関数内で、ＨｅａｄＯｐｔｉｏｎｓオブジェクトを作成し、ｏｋ（）関数を使用してルーティング先のページに渡します。
例えば、ルータを追加するときに提供されるサンプルコードにおいて、次のコードではルータによって取得されたデータを使用して、ＨｅａｄＯｐｔｉｏｎｓオブジェクトを構築し、ｍｙＲｏｕｔｅｒ－ｐａｇｅという名前のページに渡します。
Figure 2024075645000040
／／ページのデータを取得します。
ＨｅａｄＯｐｔｉｏｎｓオブジェクトには、ｒｏｕｔｅｒ（）関数で取得したデータを使用して、関連する値を設定できるいくつかのプロパティが含まれています。タイトルおよび説明のプロパティには、ＳＥＯの目的で使用されるページのタイトルおよび説明が含まれています。オブジェクトには、ページをインデックスするべきか否かをＧｏｏｇｌｅに伝えるｎｏＩｎｄｅｘフラグを含めることもできます。追加のメタタグをｍｅｔａＴａｇｓプロパティに追加できます。
ＨｅａｄＯｐｔｉｏｎｓオブジェクトにはキーワードプロパティを含めることもできますが、Ｇｏｏｇｌｅはサイトのキーワードを無視します。
サイトマップ
サイトのサイトマップは、Ｇｏｏｇｌｅがサイトのすべてのページを見つけるために使用するものです。ルータに属さないサイト上のページは、サイトのサイトマップに追加されます。しかしながら、動的に異なるすべてのバージョンを含め、ルータで利用可能なページを完全に制御するため、Ｇｏｏｇｌｅがそれらを見つけることができるように、ルータのプレフィックスに接続されるすべての可能なＵＲＬを含むサイトマップを作成する必要があります。
ルータのページをサイトのサイトマップに追加するには、ルータのためのｓｉｔｅｍａｐ（）関数を作成します。その関数内で、ルータがルーティングできるＵＲＬごとにＷｉｘＲｏｕｔｅｒＳｉｔｅｍａｐＥｎｔｒｙオブジェクトを作成します。各ＷｉｘＲｏｕｔｅｒＳｉｔｅｍａｐＥｎｔｒｙには、ＵＲＬ、タイトル、名前など、ページに関する情報が含まれています。また、コンテンツの変更頻度、最終変更日時、サイト内での相対的な優先度など、各ページに関する追加情報を追加することもできます。Ｇｏｏｇｌｅはサイトマップエントリを使用して、サイト内のすべてのページを発見します。
例えば、ルータを追加するときに提供されるサンプルコードにおいて、次のコードでは
ルータによって取得されたデータを使用して、ＨｅａｄＯｐｔｉｏｎｓオブジェクトを構築し、ｍｙＲｏｕｔｅｒ－ｐａｇｅという名前のページに渡します。
Figure 2024075645000041
／／データをサイトマップエントリに変換します。
／／非同期Ｐｒｏｍｉｓｅにラップします。
サイトマップが適切に機能していることを確認するには、公開されたサイトからサイトマップを取得できます。ウェブブラウザで、公開されたサイトのＵＲＬに移動し、それに／ｓｉｔｅｍａｐ．ｘｍｌを追加します。
例えば、プレミアムサイトの場合に、サイトの公開されたＵＲＬが次の場合、
ｈｔｔｐｓ：／／ｍｙｓｉｔｅ．ｃｏｍ
次のＵＲＬに移動します。
ｈｔｔｐｓ：／／ｍｙｓｉｔｅ．ｃｏｍ／ｓｉｔｅｍａｐ．ｘｍｌ
無料サイトの場合に、サイトの公開されたＵＲＬが次の場合、
ｈｔｔｐｓ：／／ｕｓｅｒｎａｍｅ．ｗｉｘｓｉｔｅ．ｃｏｍ／ｓｉｔｅ－ｎａｍｅ
次のＵＲＬに移動します。
ｈｔｔｐｓ：／／ｕｓｅｒｎａｍｅ．ｗｉｘｓｉｔｅ．ｃｏｍ／ｓｉｔｅ－ｎａｍｅ／ｓｉｔｅｍａｐ．ｘｍｌ
ホーム＞Ｗｉｘコード＞アドバンスト
サードパーティサービスにアクセスする
Ｗｉｘコードを使用して、サードパーティのウェブサービスにアクセスするコードを作成できます。サードパーティのサービスをクライアントサイドのコードから直接呼び出すことができます。しかしながら、ＡＰＩキーの公開などのセキュリティ上の懸念がある場合は、バックエンドウェブモジュールからサービスを呼び出すことができます。
注意：
サイトがＨＴＴＰＳサイトである場合、サービスからＨＴＴＰコンテンツを要求することはできません。無効な要求はエラーを引き起こします。これはブラウザの開発者ツールを使用して確認できます。要求を修正するには、ＨＴＴＰＳプロトコルを使用して要求されたリソースをＨＴＴＰＳサイトから取得するか、サイトのＳＳＬをオフにしてＨＴＴＰリソースを取得します。
＞アドバンスト：サービスを呼び出すために利用可能なモジュール
クライアントサイドサービスの呼び出し
例えば、サードパーティのサービスを呼び出して、為替交換レートを調べる場合を考えます。
この例では、次の要素を持つ単純なフォームを作成しました。
Figure 2024075645000042
フォームを設定したら、ボタンのプロパティを設定して、ｏｎＣｌｉｃｋハンドラが次の関数を呼び出すようにできます。
Figure 2024075645000043
この例では、フェッチ要求のための完全なＵＲＬを構築することから始めます。ＵＲＬは、サービスのアドレスおよびいくつかのクエリパラメータで構成されます。簡単のために、常に米ドルを換算するため、基本パラメータの値はＵＳＤにハードコードされます。シンボルパラメータの値は、フォームからプルされます。次に、関数は実際の要求を行います。応答を受信すると、渡されたシンボルの変換率をプルし、それをラベルのテキストとして設定します。
注意：
特定のＣＯＲＳ（オリジン間リソース共有）要求は、ブラウザから発信される場合に制限されます。通常、ＧＥＴ要求および特定のＰＯＳＴ要求は、サイトのパブリック、ページ、またはサイトコードから作成できます。他のすべての要求は、サイトのバックエンドコードから行う必要があります。無効な要求はエラーを引き起こします。これはブラウザの開発者ツールを使用して確認できます。ＣＯＲＳの制限によりフェッチ呼び出しで問題が発生している場合は、以下に説明するように呼び出しをバックエンドに移動します。
バックエンドサービスの呼び出し
バックエンドからのサービス呼び出しは、２つのパートで行われます。まず、バックエンドウェブモジュールでサービス呼び出しを行うコードを記述します。これにより、ＡＰＩキーの公開などのセキュリティ上の懸念が回避され、
例えば、サードパーティの気象サービスを呼び出して、ユーザが選択した都市の現在の天気を見つけることを考えます。
まず、気象サービスを呼び出してデータを取得する関数をバックエンドウェブモジュールに作成します。
Figure 2024075645000044
この例では、ｗｉｘ－ｆｅｔｃｈからｆｅｔｃｈをインポートすることから始めます。これはｈｔｔｐｓ要求を行うために使用されます。次に、天気を調べたい都市を取り込む新しい関数を作成します。関数は、フェッチ要求のための完全なＵＲＬを構築することから始まります。ＵＲＬは、サービスのアドレスおよびＡＰＩキーで構成されます。この例を機能させるには、＜ａｐｉ ｋｅｙ ｐｌａｃｅｈｏｌｄｅｒ＞を独自のＡＰＩキーに置き換える必要があります。次に、関数は実際の要求を行います。応答を受信すると、温度データを引き出します。その温度データは、クライアントサイドの呼び出しによって受け取られます。
クライアントサイドでは、バックエンド関数を呼び出す場所と、返されるデータをどう処理するかを決定する必要があります。
この例では、次の要素を持つ単純なフォームを作成しました。
Figure 2024075645000045
フォームを設定したら、ボタンのプロパティを設定して、ｏｎＣｌｉｃｋハンドラがバックエンドモジュールに記述した関数を呼び出すようにできます。
Figure 2024075645000046
／／フォームのページコード
ここではバックエンドで記述した関数をインポートすることから始めます。次に、ボタンのイベントハンドラでｇｅｔＣｕｒｒｅｎｔＴｅｍｐ関数を呼び出します。入力要素の値は、都市の引数として渡されます。関数の実行が終了したら、返された温度を表示するテキストラベルを設定します。
関連するコンテンツ
ウェブモジュールでフロントエンドからサーバサイドコードを呼び出す
←すべてのトピック
動的ページ
記事
＞動的ページについて
＞動的ページが必要な場合とは
＞動的ページタイプを選択するには
＞動的アイテムページを追加するには
＞動的カテゴリページを追加するには
＞動的ページデータセット設定を使う
＞動的ページをプレビューする
＞動的ページにリンクする
＞動的ページを削除する
＞動的ページと通常ページとを変換するには
＞動的ページＵＲＬを作成する
＞動的ページおよび動的ページが表示するアイテムについて
＞複数の動的ページＵＲＬを一意にする
＞ＵＲＬプレフィックスおよび動的ページのページグループ化について
＞動的ページのためのＳＥＯ設定
＞動的ページのためのページ情報設定
＞モバイルビューで動的ページのためのページ設定を使う
＞計算されたフィールドについて
ホーム＞Ｗｉｘコード＞動的ページ
動的ページについて
Ｗｉｘコードリソースセンターにアクセスし、さらに学びましょう。
動的ページを作成する場合、繰り返し使用でき、毎回データベースコレクションからの異なるアイテムを表示する１つのページレイアウトを設計します。動的ページは表示されるたびに異なるアイテムを表示するため、通常ページとは異なります。通常ページはその
コンテンツをページ自体に保存しますが、動的ページのためのコンテンツはデータベースコレクションに保存されます。
動的ページは次のような場合に役立ちます。
・ページを複製し、各ページのコンテンツまたはデザインを手動で変更している場合。動的ページを使用すると、アイテムを一度に１つずつ表示する、またはグループで複数のアイテムを表示する１つのページを作成できます。
・エディタで何も変更せずに、またはサイトのデザインを変更せずに、サイトのコンテンツを編集する場合。
動的ページには２つの種類があります。
・動的アイテムページ：コレクション内の１つのアイテムを表示するように設計されたページ。
・動的カテゴリページ：同じ基準に一致するすべてのコレクション内の複数のアイテムを表示するように設計されたページ。これらのアイテムは、リピータ、ギャラリー、またはテーブルに表示されます。
例
レシピサイトを作成していることを考えます。新しいデータベースコレクションを作成すると、タイトルフィールドがコレクションに自動的に追加されます。このフィールドを使用してレシピの名前を保存するとします。食事フィールドをコレクションに追加し、レシピが朝食、昼食、夕食のいずれであるかを記載します。また、レシピが前菜、メイン、デザートのいずれであるかを記載するコースフィールドを追加します。
次に、各レシピを独自のページに表示できるようにサイトを設計します。
この例では、個々のレシピを表示するページは動的アイテムページであり、食事に基づいてすべてのレシピを表示するページは動的カテゴリページです。
コレクションのいくつかのコンテンツを見て、これがどのように機能するかを見てみましょう。
Figure 2024075645000047
ここで、このコンテンツが動的アイテムページにどのように表示されるかを見てみましょう。
注意：
この例では、動的ページの能力を使用して何ができるかを説明します。それらの設定方法については、「動的アイテムページを追加するには」および「動的カテゴリページを追加するには」を参照してください。
動的アイテムページ
コレクションから各アイテムを表示するには、動的アイテムページを作成します。これは次のようになります。
Figure 2024075645000048
このレイアウトでは、実際のコンテンツが含まれている要素は見出し「レシピ」、「食事」、および「コース」のみであることに注意してください。これらの見出しの横（テキストに「＜＞」のついている部分）に表示されるコンテンツは、まだページに配置されていません。例えば、「＜レシピのタイトル＞」は、実際のレシピ名が表示されるテキストボックスのプレースホルダテキストに過ぎません。また、間にある画像は単なるプレースホルダ画像です（コレクションからの画像ではありません）。これらの要素が表示する実際のコンテンツは、コレクションから取得されます。
ここで、カップケーキレシピのこの動的アイテムページをプレビューしてみましょう。
Figure 2024075645000049
プレースホルダのそれぞれがどのようにカップケーキレシピの具体的な情報に置き換えられたか、また画像がどのようにコレクションからのカップケーキ画像を表示しているか
に注目してください。
同じページでエッグベネディクトのレシピをプレビューし、プレースホルダのコンテンツの変更を確認できます。
Figure 2024075645000050
ここで、このコンテンツが動的カテゴリページにどのように表示されるかを見てみましょう。
動的カテゴリページ
選択した基準に基づいて、レシピの異なるグループを表示する動的カテゴリページを作成できます。
提供されている食事に基づいてレシピを表示できるページを作成することを考えます。テーブルを使用して、それらのレシピを表示できます。
Figure 2024075645000051
アイテムページと同様に、この動的カテゴリページには実際のコンテンツはありません。ランチレシピをプレビューしたときの様子を見てみましょう。
Figure 2024075645000052
Figure 2024075645000053
動的ページにリンクする
動的ページはコンテンツを動的に表示するため、通常ページにリンクするのと同じ方法で動的ページにリンクすることはできません。詳しくは、「動的ページにリンクする」を参照してください。
ヒント：
下記の記事をご参照ください。
・動的ページＵＲＬを作成する
・動的ページおよび動的ページが表示するアイテムについて
・動的ページＵＲＬを一意にする
関連するコンテンツ
動的ページＵＲＬを作成する
複数の動的ページＵＲＬを一意にする
データベースコレクションについて
動的ページおよび動的ページが表示するアイテムについて
動的ページにリンクする
ホーム＞Ｗｉｘコード＞アドバンスト
データフックについて
データフックは、サイトのコレクションとの特定のやり取りの前後にコードを実行します。データフックを使用すると、やり取りの発生の直前または直後にやり取りをインターセプトできます。フックのコードは、やり取り自体に影響を与えるためにも使用できます。例えば、アイテムをコレクションに追加する前にアイテムをインターセプトして、最終検証を実行したり、実際にコレクションに入れるデータを微調整したりする場合があります。
一般的に、フックは、コレクションとのやり取りがページ要素によって開始されるか、データＡＰＩを使用してプログラムで開始されるかに関係なく実行されます。しかしながら、サイトのバックエンドコードからのデータＡＰＩ呼び出しは、オプションのＷｉｘＤａｔａＯｐｔｉｏｎｓオブジェクトを渡し、それを使用して、その特定のやり取りでフックが呼び出されないようにします。
フックタイプ
データのやり取りのライフサイクルには、フックできるいくつかの異なるポイントがあります。異なるフックは異なる引数を受け取り、異なる値を返します。詳しくは、「データＡＰＩ参照」を参照してください。
・ｉｔｅｍ：現在のアイテム。例えば、ｂｅｆｏｒｅＩｎｓｅｒｔでは、これは挿入されようとしているアイテムです。例えば、ａｆｔｅｒＱｕｅｒｙで発生する可能性があるような多くのアイテムがある場合、フック関数はアイテムごとに１回繰り返し呼び出されます。
・ｉｔｅｍＩｄ：現在のアイテムのＩＤ値。
・ｑｕｅｒｙ：実行されるＷｉｘＤａｔａＱｕｅｒｙオブジェクト。
・ｃｏｕｎｔ：カウントにおけるアイテムの数。
・ｅｒｒｏｒ：エラーオブジェクト。
Figure 2024075645000054
関連するコンテンツ
データフックを使うには
データＡＰＩを使う
ホーム＞Ｗｉｘコード＞アドバンスト
データバインディングルータフックについて
動的ページのうちの１つに要求が到来すると、ルータは要求のＵＲＬを使用して、表示するページとページのデータセットにバインドするデータを決定します。データバインディングルータフックを追加して、特定のポイントでこのプロセスをインターセプトし、追加のロジックを挿入できます。いくつかのフックをルータページでも使用できます。
フック
データバインディングルータフックはｒｏｕｔｅｒｓ．ｊｓファイルで定義されます。このファイルは、サイト構造サイドバーのバックエンドセクションにあります。
フック関数は、次の規則にしたがって命名されます。
Figure 2024075645000055
ルータプレフィックスは、動的ページを作成する際に選択するＵＲＬの最初の部分です。動的ページのＵＲＬは、ページの設定で確認できます。
例えば、／ｄｉｓｈｅｓ／ｎａｍｅというＵＲＬのページがあり、ｂｅｆｏｒｅＲｏｕｔｅｒフックを作成する場合、関数は次のようになります。
Figure 2024075645000056
／／関数コード
・ｂｅｆｏｒｅＲｏｕｔｅｒ
・ｃｕｓｔｏｍｉｚｅＱｕｅｒｙ
・ａｆｔｅｒＲｏｕｔｅｒ
・ａｆｔｅｒＳｉｔｅｍａｐ
フック関数の詳細については、「ルータＡＰＩ参照」を参照してください。
サイトのコレクションとの特定のやり取りの前後にコードを実行するデータフックを登録することもできます。登録した場合、データフックはｃｕｓｔｏｍｉｚｅＱｕｅｒｙ（）とａｆｔｅｒＲｏｕｔｅｒ（）との間で実行されます。
ｂｅｆｏｒｅＲｏｕｔｅｒ（）
このフックは、ルータが要求されたページに移動する前にトリガされます。このフックを使用して、要求を異なるページにルーティングしたり、エラー応答を返したりできます。例えば、誰がページを要求しているかを確認し、ユーザの役割に基づいて、ルータに次のステップを続行させるか、エラータイプの応答コードを返すかを決定できます。
ｃｕｓｔｏｍｉｚｅＱｕｅｒｙ（）
このフックは、ページのデータクエリが実行される前にトリガされます。このフックを使用して、ページのデータセットにバインドされるデータを判定するクエリをさらに調整または変更できます。例えば、ステータスフィールドがアクティブに設定されているアイテムのみを返すようにクエリをフィルタリングできます。
ａｆｔｅｒＲｏｕｔｅｒ（）
このフックは、ルータがデータをバインドした後、ページが表示される前にトリガされます。このフックを使用して、取得したデータに基づいてルータの応答を変更できます。例えば、ページの２つのバージョン、すなわち、縦長画像のためのページと横長画像のためのページとを持つことができます。データベースから画像をプルした後、画像の向きに対応するページを表示できます。
ａｆｔｅｒＳｉｔｅｍａｐ（）
このフックは、サイトマップが作成された後にトリガされます。このフックを使用して、サイトマップ内のページのリストを修正できます。例えば、サイトマップに検索ページの情報を追加できます。
ホーム＞Ｗｉｘコード＞アドバンスト
データバインディングルータフックを作成する
データバインディングルータフックを作成することにより、動的ページのデータがページにバインドされるプロセスをインターセプトできます。
この記事では、データバインディングルータを機能させるために記述する必要があるコードを説明します。データバインディングルータフックとは何か、またデータバインディングルータフックを作成するべき理由についての詳細は、「データバインディングルータフックについて」を参照してください。
データバインディングルータフックを追加する
データバインディングルータフックを追加するには、
１．サイト構造サイドバーで動的ページのうちの１つにカーソルを合わせると表示される設定アイコンをクリックし、［設定］をクリックしてページのページ情報設定を表示します。
２．［その他の機能］で、［フックの追加］をクリックして［フックの追加］ダイアログを表示します。
３．［フックの追加］ダイアログにおいて、追加するフックを選択し、［コードの追加と編集］をクリックします。
データバインディングルータフックを追加すると、選択したデータバインディングルータフックの関数スタブがｒｏｕｔｅｒｓ．ｊｓファイルに追加されます。ｒｏｕｔｅｒｓ．ｊｓファイルは、サイト構造サイドバーのバックエンドセクションにあります。
データバインディングルータフック関数は、次の規則にしたがって命名されます。
Figure 2024075645000057
したがって、動的ページにｍｙＰｒｅｆｉｘというプレフィックスがある場合、ｂｅｆｏｒｅＲｏｕｔｅｒフックのｒｏｕｔｅｒｓ．ｊｓファイルに追加されるコードは次のようになります。
Figure 2024075645000058
／／コードをルーティングします。
登録できるフックを実行される順序で次にリストします。
・ｂｅｆｏｒｅＲｏｕｔｅｒ
・ｃｕｓｔｏｍｉｚｅＱｕｅｒｙ
・ａｆｔｅｒＲｏｕｔｅｒ
・ａｆｔｅｒＳｉｔｅｍａｐ
フック関数の詳細については、「ルータＡＰＩ参照」を参照してください。
サイトのコレクションとの特定のやり取りの前後にコードを実行するデータフックを登
録することもできます。登録した場合、データフックはｃｕｓｔｏｍｉｚｅＱｕｅｒｙ（）とａｆｔｅｒＲｏｕｔｅｒ（）との間で実行されます。
ｂｅｆｏｒｅＲｏｕｔｅｒ（）
このフックは、ルータが要求された動的ページに移動する前にトリガされます。このフックを使用して、要求を異なるページにルーティングしたり、エラー応答を返したりできます。正しい応答を判定するためにページにバインドされるデータが必要な場合は、代わりにａｆｔｅｒＲｏｕｔｅｒ（）フックを使用します。
ｂｅｆｏｒｅＲｏｕｔｅｒ（）フックは、到来する要求に関する情報を含むＷｉｘＲｏｕｔｅｒＲｅｑｕｅｓｔオブジェクトを受け取ります。オブジェクトには、ルータに到達するために使用されるＵＲＬ、要求の送信場所、要求の送信者に関する情報が含まれています。
フックのボディ内で、必要なコードを記述できます。そこに記述するコードは、要求への応答方法を判定するのに役立ちます。
この関数は、ルータにルーティングを継続させる、またはＨＴＴＰ応答コードで応答させるＷｉｘＲｏｕｔｅｒＲｅｓｐｏｎｓｅオブジェクトを返す必要があります。
ルータが同じデータで元々進んでいた同じページに進むようにするには、ｎｅｘｔ（）関数を使用して適切なＷｉｘＲｏｕｔｅｒＲｅｓｐｏｎｓｅを返します。
しかしながら、フックに到達する前に元々行っていた以外のことをルータに実行させる場合は、ｆｏｒｂｉｄｄｅｎ（）関数、ｎｏｔＦｏｕｎｄ（）関数、ｒｅｄｉｒｅｃｔ（）関数、またはｓｅｎｄＳｔａｔｕｓ（）関数を使用してＷｉｘＲｏｕｔｅｒＲｅｓｐｏｎｓｅを返すことができます。
この例では、特定の要求が目的のターゲットにルーティングされるのを制限するフックを動的プレフィックスに作成します。
次のコードは、ウェブサイトのバックエンドセクションのｒｏｕｔｅｒｓ．ｊｓファイルに配置されます。
Figure 2024075645000059
データバインディングルータフックを作成するために使用されるフック機能は、ルータＡＰＩに含まれています。この機能のうちのいくつかを使用するには、これをインポートする必要があります。
ここでは、ｆｏｒｂｉｄｄｅｎ（）関数およびｎｅｘｔ（）関数をインポートします。
Figure 2024075645000060
ルータＡＰＩからの機能をさらに使用する場合は、それをｉｍｐｏｒｔ文に追加する必要があります。
フック関数では、パスが文字列「ａｄｍｉｎ」で始まるか否かを確認することから始めます。
Figure 2024075645000061
Figure 2024075645000062
ただし、パスが「ａｄｍｉｎ」で始まる場合、どのタイプのユーザが要求を行っているかを確認します。
Figure 2024075645000063
ユーザがサイトの所有者である場合は、フックによってインターセプトされる前に、ルータが移動していた場所に進むようにもう一度ルータに指示します。
Figure 2024075645000064
しかし、ユーザがサイトの所有者ではない場合、４０３応答を返します。
Figure 2024075645000065
ｃｕｓｔｏｍｉｚｅＱｕｅｒｙ（）
このフックは、ページのデータクエリが実行される前にトリガされます。このフックを使用して、ページのデータセットにバインドされているデータを判定するクエリをさらに調整または変更できます。
ｃｕｓｔｏｍｉｚｅＱｕｅｒｙ（）フックは、到来する要求に関する情報を含むＷｉｘＲｏｕｔｅｒＲｅｑｕｅｓｔオブジェクト、現在のルートを含む文字列、およびルーティングされるページのデータを取得するために使用されるクエリを含むＷｉｘＤａｔａＱｕ
ｅｒｙオブジェクトを受け取ります。
フックのボディ内で、必要なコードを記述できます。そこに記述するコードは、初期データを継続するか、何らかの方法で変更するかを判定するのに役立ちます。
関数は、ルーティングされるページに渡される最終データを取得するために使用されるＷｉｘＤａｔａＱｕｅｒｙオブジェクトを返す必要があります。
ただし、ルータで異なるデータを使用する場合は、データＡＰＩの関数を使用して現在のクエリを調整するか、新しいクエリを作成できます。
例
この例では、アクティブなユーザのみを見つけるために特定の要求が目的のターゲットに特定のルートのためのクエリをフィルタリングするフックを動的プレフィックスに作成します。
次のコードは、ウェブサイトのバックエンドセクションのｒｏｕｔｅｒｓ．ｊｓファイルに配置されます。
Figure 2024075645000066
クエリを作成するために使用される機能は、データＡＰＩに含まれています。この機能のうちのいくつかを使用するには、これをインポートする必要があります。
フック関数では、ルートがユーザを表示する動的ページに移動しているか否かを確認することから始めます。
Figure 2024075645000067
そこに行く場合は、「アクティブ」ユーザのみを取得するようにクエリを調整します。
Figure 2024075645000068
それ以外の場合は、受け取った同じクエリを返します。
Figure 2024075645000069
このフックは、ルータがデータをバインドした後、ページが表示される前にトリガされます。このフックを使用して、取得したデータに基づいてルータの応答を変更できます。
ａｆｔｅｒＲｏｕｔｅｒ（）フックは、到来する要求に関する情報を含むＷｉｘＲｏｕｔｅｒＲｅｑｕｅｓｔオブジェクトおよびルータの応答に関する情報を含むＷｉｘＲｏｕｔｅｒＲｅｓｐｏｎｓｅオブジェクトを受信します。
フックのボディ内で、必要なコードを記述できます。そこに記述するコードは、初期応答を継続するか、別の応答に変更するかを判定するのに役立ちます。
この関数は、ルータにルーティングを継続させる、またはＨＴＴＰ応答コードで応答させるＷｉｘＲｏｕｔｅｒＲｅｓｐｏｎｓｅオブジェクトを返す必要があります。
ルータが同じデータで元々進んでいた同じページに進むようにするには、応答パラメータで関数が受け取ったオブジェクトを返します。
しかしながら、フックに到達する前に元々行っていた以外のことをルータに実行させる場合は、ｏｋ（）関数、ｆｏｒｂｉｄｄｅｎ（）関数、ｎｏｔＦｏｕｎｄ（）関数、ｒｅｄｉｒｅｃｔ（）関数、またはｓｅｎｄＳｔａｔｕｓ（）関数を使用してＷｉｘＲｏｕｔｅｒＲｅｓｐｏｎｓｅを返すことができます。ルータが元々ルーティングしようとしていたページとは異なるページ上のルータからのデータを使用するには、［ｏｋ（）］関数を使用してページを選択し、そのページに元の応答からのｒｅｓｐｏｎｓｅ．ｄａｔａおよびｒｅｓｐｏｎｓｅ．ｈｅａｄｅｒを渡すことができます。このユースケースの例については、以下を参照してください。
例
この例では、２つのページのうちの１つにユーザをルーティングするフックを動的プレフィックスに作成します。ページの２つのバージョン、すなわち、水平方向の画像のためのページと垂直方向の画像のためのページとがあります。データベースから画像をプルした後、どの種類の写真を表示するかを確認し、画像の向きに対応するページにルーティングします。
次のコードは、ウェブサイトのバックエンドセクションのｒｏｕｔｅｒｓ．ｊｓファイルに配置されます。
Figure 2024075645000070
データバインディングルータフックを作成するために使用されるフック機能は、ルータＡＰＩに含まれています。この機能のうちのいくつかを使用するには、これをインポートする必要があります。
ここでｏｋ（）関数をインポートします。
Figure 2024075645000071
ルータＡＰＩからの機能をさらに使用する場合は、それをｉｍｐｏｒｔ文に追加する必要があります。
フック関数では、応答ステータスがＯＫステータスであり、応答のルーティング先のページが水平方向の写真を表示するページであるかどうかを確認することから始めます。
Figure 2024075645000072
他のステータスを見つけた場合、または応答しているページが２つのバージョンを持つページではない場合、単に元の応答を返します。
Figure 2024075645000073
ただし、ルータが水平方向の画像を表示するページにルーティングしようとしている場合、ページに表示される画像の向きを確認します。それには向きを取得します。
Figure 2024075645000074
写真の向きが送信先のページと一致しない場合、その向きと一致する別のページにルーティングし、元の応答からデータおよびヘッド情報を取得して、新しいページにも送信します。
Figure 2024075645000075
しかし、写真の向きが送信先のページと既に一致している場合は、そのままの送信先に送信します。
Figure 2024075645000076
ａｆｔｅｒＳｉｔｅｍａｐ（）
このフックは、サイトマップが作成された後にトリガされます。このフックを使用して、サイトマップ内のページのリストを修正できます。
ａｆｔｅｒＳｉｔｅｍａｐ（）フックは、到来する要求に関する情報を含むＷｉｘＲｏ
ｕｔｅｒＳｉｔｅｍａｐＲｅｑｕｅｓｔオブジェクト、およびサイトマップのエントリを含むＷｉｘＲｏｕｔｅｒＳｉｔｅｍａｐＥｎｔｒｙ配列を受け取ります。
フックのボディ内で、必要なコードを記述できます。そこに記述するコードは、初期サイトマップエントリを継続するか、何らかの方法で変更するかを判定するのに役立ちます。
関数は、サイトマップのすべてのエントリを含むＷｉｘＲｏｕｔｅｒＳｉｔｅｍａｐＥｎｔｒｙ配列を返す必要があります。
フックが受信したのと同じサイトマップエントリでルータを続行する場合は、関数がｓｉｔｅｍａｐＥｎｔｒｉｅｓパラメータで受け取ったオブジェクトを返します。
ただし、ルータでサイトマップエントリを修正する場合は、標準のＪａｖａＳｃｒｉｐｔ配列処理方法を使用して、受信した配列のエントリを追加、除去、または修正できます。
この例では、サイトマップに検索ページを追加するフックを動的プレフィックスに作成します。サイトマップ関数は、検索ページのＵＲＬのみを公開することに注意してください。このＵＲＬにページを実際に実装するには、ｂｅｆｏｒｅＲｏｕｔｅｒ（）フックを使用して、検索ページＵＲＬの要求を確認し、ユーザを検索ページにルーティングします。
次のコードは、ウェブサイトのバックエンドセクションのｒｏｕｔｅｒｓ．ｊｓファイルに配置されます。
Figure 2024075645000077
サイトマップエントリを作成するために使用される機能は、ルータＡＰＩに含まれています。この機能のうちのいくつかを使用するには、これをインポートする必要があります。
ここでＷｉｘＲｏｕｔｅｒＳｉｔｅｍａｐＥｎｔｒｙをインポートします。
Figure 2024075645000078
フック関数では、要求のプレフィックスを取得することから始めます。
Figure 2024075645000079
次に、検索ページの新しいエントリを作成します。
Figure 2024075645000080
そして、新しいエントリをサイトマップエントリの配列に追加します。
最後に、エントリの配列をＰｒｏｍｉｓｅにラップして返します。
Figure 2024075645000081
ホーム＞Ｗｉｘコード＞データを接続する
リピータに動的コンテンツを表示する
Ｗｉｘコードリソースセンターにアクセスし、さらに学びましょう。
リピータは、同じレイアウトを使用して複数のアイテムを表示する要素です。好みのレイアウトを作成すると、各リピータアイテムはその同じレイアウトを使用して異なるコンテンツを表示します。
リピータアイテムはコンテナのように機能します。他の要素をリピータ要素にアタッチします。１つのリピータアイテムに加えた変更は、他のすべてのアイテムに自動的に反映されます。
注意：
リピータレイアウトを設計するときに、テキスト、画像、図形、ボックス、ボタン、ギャラリー、およびテーブルなどの要素を使用できます。
リピータを使用して静的コンテンツを表示できます。つまり、エディタにおいて各アイテムの各要素のコンテンツを手動で決定できます。
また、データベースコレクションからのコンテンツを動的に表示するには、リピータおよびそれにアタッチされた要素をデータセットに接続します。リピータには、コレクション内のアイテムごとに１つのアイテムが含まれ、各リピータアイテムは同じテンプレートを使用しますが、異なるコンテンツを表示します。データセット設定で一度に表示されるアイテムの数を制御します。
以下は、いくつかの可能性を示す例です。
例
次の図のように、すべてのレシピをコレクションに保存するレシピサイトがあるとします。図には、各料理の写真、料理法、提供するコースが含まれています。各レシピに関する情報を表示する動的アイテムページは既に作成されています。
Figure 2024075645000082
２ チリコンカン メイン テキサス流メキシコ料理
３ チョコレートケーキ デザート グローバル
４ チョコレートケーキ乳成分不使用 デザート グローバル
５ チョコレートカップケーキ デザート グローバル
６ クレープ デザート フランス料理
７ クロワッサン サイド フランス料理
８ クロワッサンサンドイッチ メイン フランス料理
９ 餃子 メイン 中国料理
１０ エンチラーダ メイン テキサス流メキシコ料理
１１ ファヒータ メイン テキサス流メキシコ料理
１２ フレンチフライ サイド フランス料理
１３ きのこのフジッリ メイン イタリア料理
１４ ワカモレ サイド テキサス流メキシコ料理
ここで、リピータを使用してレシピをリストし、訪問者がリストをスクロールして興味のあるレシピを見つけることができるようにします。訪問者が料理の画像をクリックすると、そのアイテムの動的ページに移動します。以下の画像は、リピータがどのように見えるかを示しています。画像には、料理の写真、料理のタイトル、料理法、提供するコースが含まれています。写真はそのアイテムの動的ページにリンクしています。
Figure 2024075645000083
ファヒータ フレンチフライ
メイン サイド
料理法：テキサス流メキシコ料理 料理法：フランス料理
きのこのフジッリ ワカモレ
メイン サイド
料理法：イタリア料理 料理法：テキサス流メキシコ料理
マカロン ナチョス
デザート メイン
料理法：フランス料理 料理法：テキサス流メキシコ料理
リピータを追加および構成する
リピータアイテム内の既存の要素を移動し、不要な要素を除去します。また、新しい要素、具体的にはテキスト、画像、ボタン、ボックス、図形、ギャラリー、およびテーブルをリピータにアタッチすることもできます。
リピータの１つのアイテムのデザインまたは位置に加えた変更は、すべてのアイテムに自動的に反映されます。
以下の図は、エディタでのリピータの様子を示しています。リピータアイテムが２つしかないことに注意してください。リピータのサイズはデータセットから制御されるため、これ以上必要ありません。また、両方のリピータアイテムが同一であることに注意してください。
Figure 2024075645000084
＜料理の名前＞ ＜料理の名前＞
＜コース＞ ＜コース＞
料理法：＜料理法＞ 料理法：＜料理法＞
ヒント：
大きな要素を追加する場合、まずそれらをページに追加し、その後サイズを変更します。次に、それらをリピータ要素にドラッグします。［アイテムにアタッチ］が表示されたら、要素をドロップできます。
リピータをデータセットに接続する
動的コンテンツを表示するには、リピータをデータセットに接続する必要があります。
リピータがデータセットに接続されると、関連するコレクションから情報を取得できます。また、表示したいアイテムの数に合わせてサイズを調整します。これは、データセット設定パネルの［表示するアイテムの数］フィールドで制御します。以下を参照してください。
アタッチされた要素をデータセットに接続する
次に、アタッチされた要素をデータセットに接続します。１つのアイテムのテンプレートに加えた変更は、すべてのアイテムに自動的に反映されることに注意してください。
各アイテムで同じのままであるラベルを使いたいとしましょう。それには、テキスト要素にテキストを入力してから、データセットに接続しないでおきます。
上記の例では、画像要素はコレクションの写真フィールドに接続され、そのレシピの動的アイテムページにリンクしています。＜料理の名前＞、＜コース＞、および＜料理法＞のテキスト要素は、コレクション内の対応するフィールドに接続されているため、動的コンテンツを表示できます。「料理法：」テキスト要素はどのデータセットにも接続されていないため、各リピータアイテムに同じテキストが表示されます。
リピータアイテムの背景画像を変更する
各アイテムに異なる背景画像を表示させるには、リピータアイテムの背景画像をデータセットの画像フィールドに接続します。以下の図は、背景画像がレシピコレクションの写真フィールドに接続されている場合のリピータの様子を示しています。レシピの名前およびレシピの動的アイテムページへのリンクを表示するボタンを追加してあります。
Figure 2024075645000085
ファヒータ フレンチフライ
きのこのフジッリ ワカモレ
マカロン ナチョス
リピータをナビゲートする
デフォルトでリピータが表示するアイテムの数は、リピータに接続されているデータセットのデータセット設定によって制御されます。これはリピータ「ページ」と呼ばれます。
詳しくは、「ボタン接続パネルを使用する」を参照してください。
複数のコレクションからの情報を表示する
リピータはまた、参照フィールドを持つコレクションの関連アイテムを表示したり、あるデータセットを別のデータセットでフィルタリングした状況で関連アイテムを表示したりできます。これにより、各リピータアイテムが「マスタ」として機能する「マスタ－詳細」プレゼンテーションを作成できます。マスタ－詳細ページの作成に関するアイデアについては、こちらをご覧ください。
関連するコンテンツ
データセット設定を使う
テーブルまたはギャラリーに動的コンテンツを表示する
ホーム＞Ｗｉｘコード＞動的ページ
動的ページをプレビューする
Ｗｉｘコードリソースセンターにアクセスし、さらに学びましょう。
動的ページを作成すると、エディタにプレビューパネルが表示されます。このパネルにはドロップダウンリストが含まれており、コレクションからプレビューするアイテムまたはカテゴリを選択できます。
ヒント：
プレビューパネルを閉じた場合に再度開くには、別のページに移動してからその動的ページに戻ります。
Figure 2024075645000086
このドロップダウンリストには、この動的ページで表示できるコレクションからのアイテムのみが自動的に入力されます。動的アイテムページの場合、このリストにはコレクション内のすべてのアイテムが含まれます。動的カテゴリページの場合、このリストには、カテゴリページの作成に使用した基準に基づいて可能なすべての組み合わせが含まれます。
例えば、レシピサイトがあり、レシピのコースおよび食事をフィルタリングする動的カテゴリページを作成する場合、リストは次のようになります。
Figure 2024075645000087
しかし、すべてのレシピのアイテムページのリストは次のようになります。
Figure 2024075645000088
Figure 2024075645000089
重要：
プレビューモードでは、管理者のパーミッションでサイトを表示しています。これはコンテンツの表示の仕方に影響し、サイト訪問者のエクスペリエンスと一致しない場合があります。
関連するコンテンツ
動的ページについて
Ｗｉｘコードを使用してコードをテストおよびデバッグする
チェックリスト：コレクションのコンテンツと共にサイトを公開する
←すべてのトピック
データを接続する
記事
＞データセットとデータの接続について
＞データセット設定を使う
＞エディタでデータセットを使う
＞Ｗｉｘコードを使用して要素にリンクを追加する様々な方法を理解する
＞Ｗｉｘコードで要素にリンクを追加するには
＞テーブルまたはギャラリーに動的コンテンツを表示する
＞リピータに動的コンテンツを表示する
＞テーブル接続パネルを使う
＞あるデータセットを別のデータセットでフィルタリングする
＞データセットによりフィルタを作成するには
＞テキスト接続パネルを使う
＞ボタン接続パネルを使う
＞画像接続パネルを使う
＞ビデオプレーヤ接続パネルを使う
＞リピータ接続パネルを使う
＞リピータアイテム接続パネルを使う
＞カラム接続パネルを使う
＞ページ接続パネルを使う
＞データシートのフィルタリングと並べ替え
＞ストリップ接続パネルを使う
＞ボタンおよび画像のためのデータセットアクション
＞現在ログインしているユーザに基づいてページをフィルタリングするには
ホーム＞Ｗｉｘコード＞データを接続する
データセットとデータの接続について
・Ｗｉｘコードリソースセンターにアクセスし、さらに学びましょう。
・この記事を全画面表示するにはここをクリックしてください。
注意：
データセットはエディタに要素として表示されますが、公開されたサイトには表示されません。
データの接続は、ページ要素をデータベースコレクションに接続するプロセスです。これにより次のことが可能になります。
・サイトページにコレクションのコンテンツを表示する。
・ユーザ入力をキャプチャしてコレクションに保存する。
データセットは以下を制御します。
・要素での使用に利用可能なコレクション
・要素がコレクション内のコンテンツでできること（表示、追加、既存のものの修正）。これは、コレクションのパーミッションの影響も受けます。詳しくは、「データセットモードおよびコレクションパーミッションを使う」を参照してください。
・表示されたコンテンツがフィルタリングされているか並べ替えされているか
データセットは、ページ上の要素とコレクションとの間のブリッジまたはコネクタと考えることができます。まずデータセットをコレクションに接続し、次に要素をデータセットに接続します。これにより、次の図に示すように、要素がコレクションに接続されます。
Figure 2024075645000090
同じデータセットに接続されているページ上のすべての要素は、データセットで定義されているようにコレクションのコンテンツで機能します。データセットは、コレクション内のどのアイテムが現在フォーカスされているかも追跡します。これは、コレクションのコンテンツの表示の仕方、およびユーザ入力のキャプチャの仕方に影響します。いくつかの例を見て、これがどのように機能するかを見てみましょう。
コンテンツを表示する
レストランのサイトで、訪問者がメニューのオプションをスクロールして閲覧できるようにする場合を考えます。メニューのすべてのアイテムのコレクションが用意できていて、それぞれのアイテムについて、次のものを表示しようとしています。
・料理の名前
・提供される場面
・前菜、メイン、またはデザートのいずれかである
・料理に関するアレルギー情報
・料理の写真
これらのアイテムを１つずつページに表示するように設計できますが、その前に、次のことをする必要があります。
・コレクション内の異なるアイテムを要素が表示するように、ページ上の要素を接続する。
コレクション内の特定のアイテムについては、すべての要素がその同じアイテムに対応する情報を表示している必要があります。
コレクション内の異なるアイテムを要素が表示するように、ページ上の要素を接続する。
要素をセットアップするには、ページに要素を追加して、［データに接続］アイコンを用いてそれらすべてを同じデータセットに接続します。また、コレクションからどのフィールドを表示するかを定義します。
訪問者が料理をスクロールできるボタンをページに追加する
訪問者がデータセット内の前または次のアイテムに移動できるように、ページにボタンを追加します。これらのボタンは、要素と同じデータセットに接続されている必要があります。
同期して変化するように要素を設定する
訪問者がページの前または次のボタンをクリックすると、すべての要素にコレクション内の同じアイテムに関するコンテンツが表示されます。これは、データセットが現在フォーカスされているアイテムを追跡し、同じデータセットに接続されているすべての要素が連携して動作するためです。要素の１つが現在フォーカスされているアイテムを変更すると、そのデータセットに接続されているすべての要素の要素が変更されます。
コンテンツをキャプチャする
訪問者が無料の夕食にサインアップできるようにするレストラン用のフォームを作成するとします。ユーザ入力要素を使用して、訪問者から必要な情報を収集するようにフォー
ムを設定します。
ここでも、［データに接続］アイコンを使用して、各要素を同じデータセットに接続します。また、訪問者が各入力要素に入力したデータを保存するために使用するコレクション内のフィールドを定義します。
ヒント：
ユーザがコレクションに書き込みできるように、コレクションおよびデータセットのパーミッションを設定することをお忘れなく。
また、送信ボタンを作成する必要があります。フォームへの入力が完了したら、訪問者はこのボタンをクリックして、コレクションに情報を送信します。
このボタンは、ユーザ入力要素と同じデータセットに接続される必要もあります。
これは、データセットがコレクション内の現在のアイテムを追跡するために機能します。この場合、データセットはコレクション内の新しい空のアイテムを指しています。すべての要素が同じデータセットに接続されているため、それらはすべて同じアイテムに保存されます。
動的ページデータセットについて
動的ページを作成すると、動的ページデータセットがページに自動的に追加されます。通常のデータセットと同様に、動的ページデータセットを使用すると、ページ要素をコレクションに接続できます。ただし、動的ページデータセットが通常のデータセットと異なる点がいくつかあります。
動的ページが表示できるコンテンツは、そのＵＲＬによって制御されます。このため、通常のデータセットとは異なり、動的ページデータセットでは、データセットが接続されるコレクションを変更できません。
ＵＲＬはページが表示できるコンテンツを制御するため、コレクションのコンテンツのためのフィルタとしても機能します。ここでも、ページ設定でＵＲＬ定義を変更することにより、コンテンツフィルタリングを変更します。動的ページデータセット設定を使用して、さらなるフィルタを追加したり、ページ上のコンテンツを並べ替えたりすることもできます。
また、ページから動的ページデータセットを削除することもできません。データセットを除去するには、動的ページを通常ページに変換する必要があります。
関連するコンテンツ
データベースコレクションについて
チュートリアル：データベースコレクションにユーザ入力を保存するフォームを作成する
ＷＣＤ－Ｗｉｘコード
コード要素および検索エンジンサポートを組み込むウェブサイト構築システム
もくじ
はじめに １
関連出願 ２
背景技術 ２
システムの説明およびアーキテクチャ ３
コンセプトの詳細 ７
付属書類一覧 １０
はじめに
１．本出願は、ウェブサイト構築システム（および他の視覚的編集システム）を対象とするものであり、検索エンジンによりインデックスされ得る、またＳＥＯをサポートし得るウェブサイトを生成しながら、クライアントサイドおよびサーバサイドの両方において
ユーザ提供コード（ＵＰＣ）の組み込みを実現する、洗練された視覚的編集ツールについて説明している。
２．本出願は、Ｗｉｘコードのコンテキストで説明されている複数のコンセプトについて説明している。Ｗｉｘコードは、Ｗｉｘ．Ｃｏｍ Ｌｔｄが提供するＷｉｘウェブサイト構築システムの一部として開発されているサーバレスサイト開発プラットフォームである。以下の説明は、このようなシステムの包括的な説明を含む。Ｗｉｘコードの実装は本コンセプトおよび技術の唯一の実施形態ではなく、本明細書の開示に従って追加の異なる実施形態を構築できることを明確にしておきたい。
関連出願
３．本出願は、付属書類Ａ１に記載されている特許出願を参照しており（または関連しており）、そのすべてが本出願の譲受人と同一の譲受人に譲渡されている。付属書類Ａ１に記載されている特許出願および特許のそれぞれの開示は、その全体が明示的に本明細書に組み込まれる。
背景
４．出願人は、クラウドエコシステムの欠陥を見出した。ｌａａＳ（サービスとしてのインフラストラクチャ）、ＰａａＳ（サービスとしてのプラットフォーム）、およびＳａａＳ（サービスとしてのソフトウェア）の状況によって、ＶＭ、コンテナおよびネットワーキング、バックエンド開発者向けの様々な種類のプラットフォーム、モバイル開発者向けのバックエンド、ならびに個人および企業向けの既製のソフトウェアのための解決策が提供されている。その中で欠けているのは、ウェブサイトおよびウェブアプリのためのプラットフォームである。
５．サーバレス（サーバレスコンピューティングとも呼ばれる）の登場している中で、この欠陥にはまだプレーヤがいない。出願人は、この欠陥にある程度対処するために、ウェブサイトおよびウェブアプリの開発およびデプロイのためのプラットフォームであるＷｉｘコードを開発した。このプラットフォームは、フロントエンドに最適化されたＪａｖａＳｃｒｉｐｔ、ＳＥＯ互換性、ＷＹＳＩＷＹＧサイトビルダー、ウェブメソッド、およびバックエンドＪａｖａＳｃｒｉｐｔなどの要素ならびに要求時コンテナブートを提供する。
６．特に、本開示のシステムは、フロントエンドおよびバックエンドの両方のコードに対してウェブサイトに組み込まれた埋め込みコードを指定しながら、ウェブサイトを視覚的に作成する機能を提供する。このすべては、検索エンジンによりインデックスされ、ＳＥＯ技法を適用するウェブサイトの機能を維持しながら実行できる。
７．ウェブサイト構築システムは、スタンドアロンシステムとすることもできるし、より大きな編集システム内に組み込むこともできる。また、ウェブサイト構築システムは、オンライン（すなわち、アプリケーションが編集され、サーバに保存される）とすることも、オフラインとすることも、部分的にオンライン（ウェブサイトはローカルで編集されるが中央サーバにアップロードされる）とすることもできる。本開示のシステムは、通常、オンラインのウェブサイト構築システムの一部であり得るが、他の種類のウェブサイト構築システムに組み込むこともできる。
８．視覚的デザイン環境に基づいた既存のウェブサイト構築プラットフォームは、通常、ＭｉｃｒｏｓｏｆｔのＯｆｆｉｃｅスイートを操作するために必要なスキルセットなどのスキルセットを有するユーザを対象としている。しかしながら、こうしたユーザが構築しているのはサイトの５％のみである。
９．本開示のシステムは、作成するのにより高いレベルのスキルを通常必要とするより複雑なサイトをサポートする。このようなサイトは、通常、設計者、スクリプトライター、および開発者によって作成され、インターネット内のサイトの９５％を含む。付属書類Ａ２は、この範囲のサイト作成者およびサイトタイプをさらに説明するプレゼンテーションを含む。
システムの説明およびアーキテクチャ
１０．付属書類Ａ３は、例示的なシステムおよびその要素の詳細な内部技術説明を含む。
１１．付属書類Ａ４は、技術的なユーザ／開発者向けの例示的なシステムの内部技術説明を含む。
１２．付属書類Ｂは、例示的なシステムの仕様とユーザ／開発者による使用法とを説明する、１セットのユーザ向けガイドおよびチュートリアルを含む。
１３．付属書類Ｃは、例示的なシステムの全体的な紹介を提供する、１セットのプレゼンテーション、チュートリアル、およびビデオスクリプトを含む。
１４．（基本的なＷｉｘシステムに加えて構築された）例示的なシステムの基本設計は、以下に説明する１５のサブシステムから構成される。１６番目の「サブシステム」は、サイト設計者から提供され、（適切なカプセル化および分離が適切に行われている）システムの一部として実行され得るユーザ提供コード（ＵＰＣ）である。
１５．これらの例示的なサブシステムは、クライアントサイドのプレゼンス、サーバサイドのプレゼンス、またはその両方を持つことができる。例示的なサブシステムは、中でも以下を含み得る。
Figure 2024075645000091
１６．これらの例示的なサブシステムおよびその例示的な機能は、次のように簡単に説明できる。
１
（サブシステム名）計算グリッド
（頭字語）ＣＧＤ
（説明）
ドッカー（１）を実行するバックエンドサーバ：
・ドッカー内の部分を含まない。
・ドッカーのリサイクルおよびドッカーの高速起動を行う。
・エレメントリに特定のサービスを提供し得る。
（１）ｈｔｔｐｓ：／／ｗｗｗ．ｄｏｃｋｅｒ．ｃｏｍ／ｗｈａｔ－ｄｏｃｋｅｒ
ｈｔｔｐｓ：／／ｗｗｗ．ｄｏｃｋｅｒ．ｃｏｍ／ｗｈａｔ－ｃｏｎｔａｉｎｅｒ
２
（サブシステム名）エレメントリ
（頭字語）ＥＬＭ
（説明）
各ドッカー内のアプリケーションサーバ：
・ｎｏｄｅ．ｊｓベース。
・クライアントサイドのスクリプトを準備するために使用。現在、これは計算グリッドの別のサービスとして外部に移動されている。
３
（サブシステム名）Ｗｉｘデータ
（頭字語）ＷＤＴ
（説明）
システムの基礎となるＤＢであり、以下を含む：
・クライアントおよびサーバＡＰＩおよび実装。
・パーミッションシステム。
・フックシステム（カスタマイズ可能なコールバック）
・ＤＢドライバ。基礎となるＤＢ（以下のＷｉｘ ＤＢまたは代替的なＤＢなど）に接続する。
スキーマの使用について：
・単独で「ソフト」スキーマを使用。スキーマは上から提供される。
・スキーマは、ＡＰＩにはなく、アプリケーションレベルにある。
・コンテンツマネージャは、スキーマとは異なるセルを有する場合がある。よって、「非準拠データを処理する」ユースケースを有する。
サンドボックスおよびライブの２つのＤＢインターフェースを提供する。単一のＤＢおよび２つ目のための差分で実装される。Ｏ（１）操作を保持する。以下のアルゴリズムに関するコメントを参照されたい。
４
（サブシステム名）ウェブメソッド／ＲＰＣ
（頭字語）ＷＢＭ
（説明）
クライアントからサーバへのＲＰＣ：
・Ａｊａｘのための自動ラッパー
・セキュリティサービスを提供する。
・サーバからのエラーおよびログメッセージは自動的にクライアントに、すなわちブラウザコンソール（デバッグ用）に送信される。これによりデバッグ時に「単一システムイメージ」の感覚を提供する。
５
（サブシステム名）設定不要ＩＤＥ
（頭字語）ＺＳＩ
（説明）
設定不要ＩＤＥ：
・エディタに組み込まれたオンラインＩＤＥ
・コード補完をサポート
・メディアのための特定のサポート（画像／ビデオ／文書、ＵＲＬなどのためのメディアマネージャを開く）
６
（サブシステム名）エディタプラットフォーム
（頭字語）ＥＰＴ
（説明）
Ｗｉｘサイトにアプリケーションを追加する新しい手法：
・ウェブワーカー（２）に基づく
・ｉｆｒａｍｅにおけるウェブワーカー。アプリコードを実行する。
・コントローラ。Ｗｉｘコンポーネントに接続する。
・ＡＰＩへのインターフェースを含む。
・ルータ（インフラストラクチャ）を有する。コードバックエンド。ページのＵＲＬおよび選択を制御できる。
（２）ｈｔｔｐｓ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／Ｗｅｂ＿ｗｏｒｋｅｒ
７
（サブシステム名）クライアントサイドウェブワーカー
（頭字語）ＣＳＷＷ
（説明）
クライアントユーザコードを実行するクライアント上のウェブワーカー独立スレッド内のＲＴコードが：
・ウェブサイトを操作および修正するウェブワーカーｉｆｒａｍｅのコードを許可する一連のＡＰＩから構成される。
・コンポーネントのデータの変更および可視性の変更に制限される場合がある。
・また、特定のアイテム（次のアイテム、アイテムＸ、．．．）を表示するためにギャラリーを変更するなど、一部のタイプのコンポーネントを制御できる。
・コンポーネントの追加／除去、コンポーネント属性の変更など、サイト自体の修正を含むように拡張できる。
８
（サブシステム名）ルータ
（頭字語）ＲＴＲ
（説明）
ルータインフラストラクチャ。ユーザがルータコードを直接記述できる。
９
（サブシステム名）動的ページ
（頭字語）ＤＹＰ
（説明）
独自のルータを持つアプリケーション。
ルータは、Ｗｉｘデータのコレクションがあれば、アイテムおよびカテゴリページを作成し、データバインディングを介してデータを公開する。
これらは実際には、独自のＵＲＬで新しく作成されたページである。
これはすべてのルータの状況である。
他のページタイプにも拡張できる。
１０
（サブシステム名）データバインディング
（頭字語）ＤＢＤ
（説明）
独自のコントローラを定義するアプリケーション。そのコントローラが管理するのはデータセットであり、データベース内のデータをＵＩコンポーネントに接続する。
１１
（サブシステム名）コンテンツマネージャ
（頭字語）ＣＭＧＲ
（説明）
ＷｉｘデータのためのＥｘｃｅｌのような編集ツール。
・ソフトスキーマをサポート。
・よって、システムは数値セル内に文字列値を持つことができる。セルは文字列表示機能を使用して表示されるが、赤い線でマークされます（スペルチェックと同様）。ホバー時に、文字列でポップアップを表示し、ユーザが修正できるようにする。
１２
（サブシステム名）動的ＳＥＯ
（頭字語）ＤＳＥＯ
（説明）
Ｗｉｘコードのための完全なＳＥＯソリューション。
・ＳＥＯを動的ページ、データバインディング、およびＡＰＩに適用する。
・代わりに、サーバ環境で上記のワーカー（通常はクライアントで実行）を実行する。
・処理された検索エンジン対応ページを提供する。
１３
（サブシステム名）計算関数
（頭字語）ＣＦＮ
（説明）
関数をフロントエンドに直接公開するバックエンドの機能。関数を呼び出して応答を取得する。ＨＴＴＰ式バックエンド。
１４
（サブシステム名）Ｗｉｘ ＤＢ／ドックストア
（頭字語）ＷＤＢ
（説明）
システムの基礎となるスケールアウトＭｏｎｇｏ ＤＢ。データの外部管理シャーディング（３）をサポートする。
（３）ｈｔｔｐｓ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／Ｓｈａｒｄ＿（ｄａｔａｂａｓｅ＿ａｒｃｈｉｔｅｃｈｔｕｒｅ）
１５
（サブシステム名）＄Ｗ ＡＰＩ
（頭字語）＄ＷＡＰＩ
（説明）
サイトのビジュアルに影響を与えるためにユーザが使用するＡＰＩ：
・コンポーネント属性、可視性などに影響を与えるＤＢＤが使用するメインチャネル。
・ｊＱｕｅｒｙに類似。
－
（サブシステム名）ＵＰＣ
（頭字語）ＵＰＣ
（説明）
ユーザ提供コード：
・これは、ウェブサイトの一部としてユーザにより記述または提供される実際のコードである。
・ウェブワーカー内で実行される。通常クライアントで実行されるが、ＳＥＯのためにサーバで実行されてもよい。
１７．様々なサブシステム間の関係は、次のように視覚化され得る。
Figure 2024075645000092
１８．これらの例示的なサブシステムのそれぞれの詳細な説明は、付属書類Ａ５に含まれる。
１９．付属書類Ａ６は、上記のＷＤＴの一実施形態を実装するための特定の「データベースオーバーレイ」アルゴリズムを含む。代替的な実施形態は、「マイナスＤＢ」を使用する代わりに、議論された「プラスＤＢ」で「廃棄記録」（削除された記録を意味する）を使用し得る。
コンセプト詳細
２０．出願人は、本明細書でより詳細に説明されるいくつかの領域、機能、および能力を見出した。これらには次のものを含む。
２０．１．オンラインウェブサイト構築環境でのカスタムバックエンド機能。
２０．２．データベースで入力されるウェブページの動的プレビュー。
２０．３．仮想ウェブページのプレビュー中におけるデータベースの編集
２０．４．ウェブサイトホスティングのためのオンデマンドウェブサーバ実行インスタンス
２０．５．ウェブサイトのライブ運用およびテストのための共通データベース。
２０．６．自動レイアウト推奨エンジン（マジックレイアウト）。
２０．７．ＳＥＯを改善するための自動ウェブサイト設計推奨。
２０．８．分離されたユーザアップロードプラグインは、共同ホストされたウェブサイトにわたる感染を回避する。
２０．９．ウェブサイトのためのユーザアップロードプラグインを分離する。
２０．１０．ユーザ提供プラグインがオンラインエディタの機能を拡張する。
２０．１１．設計ツールから分離したｉＦｒａｍｅエディタインターフェース。
２１．付属書類Ｄは、これらのコンセプトのそれぞれに関するさらなる詳細および開示を提供する。
以下は、いくつかのコンセプトに関する特定の追加の明確化である。
２２．オンラインウェブサイト構築環境でのカスタムバックエンド機能。
２２．１．システムは、生成されたページのＨＥＡＤタグに含まれるスクリプトまたはマーカを介して、特定の検索エンジンスパイダーサポートを提供し得る。
２２．２．このようなマーカまたはスクリプトは、スパイダーが特定の専用ウェブサービスを使用するように誘導し、ページをインデックス可能にするのに役立つ。
２３．ウェブサイトホスティングのためのオンデマンドウェブサーバ実行インスタンス
２３．１．本コンセプトは、特定のサイトのために構成されたウェブサーバインスタンスを実行し（特定のプラグインおよびこのサイトのサーバサイドのユーザ提供コードを含む）、かつタイムアウトなしで、またユーザが許容できる合計時間枠内でのＨＴＴＰ要求への応答を十分な速さで行う、ドッカーコンテナの高速ブートを含む。
２３．２．通常、仮想マシンの起動には数分かかる。ドッカーコンテナの起動には依然として２～３分かかる。これらの時間の両方とも許容可能ではない。
２３．３．本開示のシステムでは、すべての関連するサイト固有ではないコードを含むが、ユーザ／サイト固有のコードを含まないスタンバイドッカー（例えば、コンテナ）のプールが提供される。
２３．４．本システムは、特定のウェブサイトのサーバに接続する要求をライブポートでリッスンし得る。特定のウェブサイトに関連付けられているライブドッカーがある場合、本システムはそれに接続し得る。それ以外の場合は、プールからのスタンバイドッカーを使用し、要求されたコンテンツをプールに投入するか、そのようなコンテンツをロードするように指示することができる。
２３．５．サイトが所与の期間（１５分など）アクティブでない場合、システムはスタンバイコンテナをドロップし得る。
２４．ウェブサイトのライブ運用およびテストのための共通データベース：
２４．１．このコンセプトは、同じＤＢ上でステージングおよびライブデータを実行することが含まれる。
２４．２．上記のように、例示的なアルゴリズムが付属書類Ａ６に詳述されている。
２４．３．開発システムがＤＢに書き込むと、データのコピーが作成され得る。このコピーは、開発システムから見えるものであり得る。開発データはライブサイトでは表示されない場合がある。
２５．ウェブサイトのためのユーザアップロードプラグインを分離する：
２５．１．このコンセプトでは、ｉＦｒａｍｅを使用して１つのサイトからコンテンツを取得し、別のサイトに安全に組み込む方法について説明する。しかしながら、このようなコンテンツの組み込みは、次のようないくつかの方法を使用して実装され得る。
２５．１．１．ＡＪＡＸを介してコンテンツを転送すること。
２５．１．２．静的コード分析の対象となるリモートコンテンツを直接含めること。例えば、ＪＳコードを分析して安全かどうかを確認する。
２５．２．本開示のシステムは、プラグインコードを実行するためにより小さい（かつ通常は非表示である）ｉｆｒａｍｅを使用するが、プラグインＵＩ自体はウェブサイト構築システムにネイティブであり得る。
これは、ＴＰＡのＵＩの一部または全部がｉＦｒａｍｅに実装されているＴＰＡ（サードパーティアプリケーション）で使用される構成とは異なるが、ＴＰＡはＴＰＡをホスト
するページ内の他のネイティブコンポーネントと依然として通信できる（ＴＡＣＡ Ｗｉｘ特許出願で説明されているように。付属書類Ａ１参照）。
２５．３．プラグインはまた、プラグインがユーザ提供のコード（クライアントサイドでのみ実行される）のみを通常含むという点で、ＴＰＡとは異なる。一方、ＴＰＡコードはＴＰＡプロバイダサーバで実行される。
２５．４．よって、本開示のシステムは以下の利点を提供し得る。
２５．４．１．プラグインをサイトにインストールできるようにし、これにより、機能が追加されるが、コードの分離に起因してウェブサイト自体が危険にさらされることはない。
２５．４．２．プラグインはサイトのクッキーおよびＤＯＭにアクセスできない。また、ウェブコンポーネント（４）または同様のシステムにより提供される（制限された）カプセル化のように、このセキュリティ対策をバイパスすることはできない。
（４）ｈｔｔｓ：／／ｗｗｗ．ｗｅｂｃｏｍｐｏｎｅｎｔｓ．ｏｒｇ／
２５．４．３．本開示のシステムにより、（例えば、プラグインを別々のｉＦｒａｍｅに配置することなどにより）複数のプラグインをインストールできるため、互いに干渉することはない。
２５．４．４．本開示のシステムにより、両方に単一のｉＦｒａｍｅを使用したり、複数のｉＦｒａｍｅ間でＡＰＩを使用したりして、別のプラグインを拡張するプラグインをインストールできる。このようなプラグインは、互いに分離またはサンドボックス化されておらず、例えば、同じベンダが提供するプラグインファミリの一部であり得る。
２５．４．５．本開示のシステムは、サイト自体から切り離されたリッチＡＰＩを備えた安全なプラグインサブ領域を提供することができ、同じ領域に複数のプラグインを配置できるようにし、上記の＄ｗ ＡＰＩを介してリッチＡＰＩをサポートする（場合により、ＴＡＣＡ特許出願で説明されているように、制御されたクロスｉＦｒａｍｅ ＡＰＩを使用する。付属書類Ａ１参照）。
２５．５．この構成は、ｉＦｒａｍｅには開発されたＡＰＩがなく、ホスティングＷＢＳ（ウェブサイト構築システム）またはＷＢＳページとやり取りしないために、通常のｉＦｒａｍｅとは異なる。また、ＣＳＲＦ（クロスサイトリクエストフォージェリ）、クッキー窃取、ＸＳＳ（クロスサイトスクリプティング）の防止にも効果的である。ただし、使用できるのはオンラインＷＢＳのみである。
２５．６．これは既存の従来技術のシステムとは対照的であり、従来のシステムは通常、正しく記述されたプラグインに依拠するか、特定のプラグインに制限されている。
２５．７．本実装は、例えば、ＰｏｓｔＭｓｇのためのゲートウェイへのフックに依拠し、特定のメッセージをフィルタリングし得る。よって、本開示のシステムはまた、ユーザが任意のプラグインに付与されたアクセスパーミッションを正確に制御できるようにするユーザ指向のパーミッション技法も実装できる。これは、スマートフォンのオペレーティングシステムが、インストールされているアプリケーションに付与されるアクセスパーミッションを正確に制御する仕方に似ている（例えば、「アプリＸＹＺはＧＰＳを使用できますか？／連絡先にアクセスできますか？」）ただし、これはインストール前にプラグインのコピーをダウンロードする必要なく行われる。
２５．８．本開示のシステムは、オンラインＷＢＳとして、プラグインが更新されるとすぐにプラグインのすべてのインストールが更新され、プラグインを１か所に格納し得ることにさらに留意されたい。これは、各プラグインのインストールが別個であり、それ自体で更新する必要がある既存のオフラインの従来のシステムとは対照的である。
付属書類一覧
Figure 2024075645000093
０１－ＣＧＤ
計算グリッド
Ｗｉｘコードの計算グリッド
目的および機能
グリッドにはＷｉｘコードの２つの主要な機能がある。
・フロントエンドおよびバックエンドのコードを開発する場合、エディタモードであり、エディタモードは、安全なマルチテナント方式でのプレビューのためにフロントエンドコードのバンドルとバックエンドコードの実行を提供しながら、ソースコードの基礎となるファイルシステムを提供する。
・パブリック表示では、パブリックモードのユーザバックエンドコードのための高速で安全なマルチテナント方式の信頼できるエグゼキュータ。
計算グリッドアーキテクチャ
Figure 2024075645000094
クラウドランタイム（旧エレメントリ）
目的
・クラウドランタイムの実行は、コンピューティンググリッドの存在の唯一の目的である。
・クラウドランタイムコンテナは、信頼性、高速性、および安全性を備えるように設計されている。
高速性
・クラウドランタイムコンテナは、単一ノードＪＳプロセスを実行する軽量コンテナである。
・コンテナがユーザコードを提供する準備が整うのに比較的長い時間がかかるため、そのためのスタンバイコンテナのプールを維持する。
・オンデマンド機能を提供するために常に十分なスタンバイコンテナがあることを確認することは、クラウドライフサイクルの役割である（以下を参照）。
信頼性
・パブリック（編集しない）モードでは、
○コンテナは完全に廃棄可能である。
○システムは、ユーザコードが実行されているコンテナを１００ミリ秒未満でプロビジョンできる。
・編集モードでは、
○ユーザコードは、定期的に自動的にアーカイブされる。
○コードの編集はクラウドランタイムコンテナが実行されているのと同じファイルシ
ステムで行われるため、ユーザはコードをすぐに実行してプレビューできる。
安全性
・クラウドランタイムコンテナは１つのアプリケーションのみを実行するため、コンテンツリークは発生しない。
・コンテナは、静的にリンクされたノードＪＳバイナリのみを含む。
・コンテナのルートファイルシステムは読み取り専用である。
・各コンテナは一意のユーザＩＤで実行される。
・ユーザコードはホストワーカーによってコンテナの外部から投入される。
・コンテナはコードにアクセスできないが、コードが割り当てられているユーザはアクセスできる。
・ユーザコードファイルシステムは実行パーミッションを持たない。
・ディスククオータ、メモリ、ＣＰＵ、ネットワーク、および他のシステムリソースクオータ制限がコンテナに適用される。
クラウドライフサイクル
・クラウドライフサイクルはグリッドホストの外部であるが、このコンテキストで言及するに値する。その機能は、Ｗｉｘコードの計算グリッドを制御および管理することである。
・ライフサイクルは、グリッドホスト上の２つのコンポーネントを使用して、ホストおよびクラウドランタイムコンテナを管理する。
ａ．ドッカーデーモン。ホストワーカーおよびクラウドランタイムコンテナを開始、停止、および制御する。
ｂ．ホストワーカー。クラウドランタイムコンテナファイルシステムのパーミッション、クオータ、およびアーカイブ機能を管理する。
・このドキュメントに関連するのは、クラウドランタイムが使用している各ユーザコードごとにＵＮＩＸ（登録商標） ＵＩＤを割り当てるライフサイクル機能である。
グリッドホスト
計算グリッドは、Ｗｉｘコードライフサイクルサービスによって管理される３つの主要コンポーネントで構築される。グリッド上の各ホストは、次のコンポーネントを有する。
１．ドッカーデーモン
２．（ドッカーコンテナ内の）ホストワーカー
３．（ドッカーコンテナ内の）クラウドランタイム（旧エレメントリ）
・グリッドホストが稼働を開始すると、グリッドホストＩＰを、その定義されたリソース、すなわちＣＰＵおよびメモリと共にメッセージコンテナに送信することにより、自身をライフサイクルに登録する。
・グリッドホストには、クラウドライフサイクルを管理するために、動作中のドッカーデーモンがインストールされ、実行されている必要がある。
ホストワーカー
ホストワーカーは、クラウドライフサイクルがホストを管理するために使用するコンポーネントの一部である。これには２つの役割がある。
１．ライフサイクル機能を拡張して、システムのパーミッション、クオータ、ネットワーク、ファイルシステム、およびコードアーカイブを管理および操作する。
２．ユーザがＷｉｘエディタでコードを編集する際に、エディタにＡＰＩのようなファイルシステムを提供する。
ホストワーカーライフサイクル
１．クラウドランタイムコンテナ作成前
ａ．ユーザコードのためのディレクトリを作成する。
ｂ．適切なパーミッションおよびディスククオータを設定する。
２．クラウドランタイムコンテナが「ウォーム」で作動した後
ａ．コンテナにネットワークトラフィックの実施を設定する
ｂ．ユーザがコードを編集している間に、ユーザコードを定期的に自動アーカイブする。
３．クラウドライフサイクルがコンテナの停止を決定した場合に、
ａ．ユーザコードを保存してデータベースにアップロードする（エディタモードで）。
４．ライフサイクルによりスケジュールされた定期的なタスクを実行する。
ａ．「感染した」コンテナを見つけ、キルする。
ｂ．コードがアーカイブされた後、ディスクをクリーンアップする。
ホストワーカーファイルシステムＡＰＩ
上述のように、ホストワーカーの他の役割は、エディタに仮想ファイルシステム（ＶＦＳ）ＡＰＩを提供することである。その意味でのホストワーカーの役割は次のとおりである。
１．次のような基本的なファイルシステム操作を提供する。
ａ．ファイルおよびディレクトリの作成、更新、読み取り、削除操作。
２．上記の操作が、クオータおよびパーミッションの制限を維持しながら許可されたユーザに代わってのみ行われることを確認する。
０２－ＥＬＭ
エレメントリ
Ｗｉｘコード－クラウドランタイム／エレメントリ
概要
クラウドランタイム（別名エレメントリ）は、プレビューおよび表示のモードの両方の編集のためのユーザ要求を処理するｎｏｄｅ．ｊｓベースのサービスである。サービスは、複数のシナリオでユーザコードを実行し、ユーザクライアントコードを処理およびトランスパイルする役割を果たす。
メインエンドポイント
・ウェブメソッド。サブプロジェクト＃４ドキュメントで指定されている。
・動的ルータ。サブプロジェクト＃８ドキュメントで指定されている。
・Ｗｉｘデータ。サブプロジェクト＃３ドキュメントで指定されている。
・Ｗｉｘエンドポイント（計算関数）。サブプロジェクト＃１３ドキュメントで指定されている。
・静的ファイル。ユーザコードをトランスパイル、バンドル、および処理する。
内部／外部モジュール分離
サービスは内部モジュールと外部モジュールとに分離され、ユーザコードは外部モジュールにマウントされ、ユーザはそこからｗｉｘライブラリ（ｗｉｘ－ｄａｔａ、ｗｉｘ－ｒｏｕｔｅｒｓ、ｗｉｘ－ｅｎｄｐｏｉｎｔｓ、ｗｉｘ－ｆｅｔｃｈ）にアクセスできる。
ユーザが外部モジュールのみにアクセスするように制限するために、サービスはスコープ指定を要するモジュール（ｗｉｘが開発したオープンソースプロジェクト）を使用する。
ユーザコードのトランスパイル
Ｗｉｘコードにより、ユーザは最新のＥＣＭＡＳｃｒｉｐｔ（現時点ではＥＳ２０１７
まで）機能を使用してコードを記述でき、クラウドランタイムの役割のうちの１つは、ランタイム環境によってこのコードをＪａｖａＳｃｒｉｐｔのサポートバージョンにトランスパイルすることである。
・クライアントサイドコード。クラウドランタイムには．ｊｓファイルおよび．ｍａｐファイルを要求するためのエンドポイントがあり、サービスはクライアントサイドコードをトランスパイルおよびバンドルするために同じコアライブラリをクラウドバンドラサーバと共有している。
・バックエンドコード。ＥＣＮＡＳｃｒｉｐｔの最新機能はｎｏｄｅ（ｖ６．１１．０）の現在のＬＴＳバージョンではサポートされておらず、サービスは必要なファイルのトランスパイルを遅延評価するためにバベルレジスタを使用する。
ユーザコードの実行
ユーザは、ウェブメソッド、ｗｉｘ－ｄａｔａフック、カスタムルータ、データバインディングルータフック、および計算関数を使用して、最終的にクラウドランタイムサービスで実行する必要があるバックエンドコードを作成できる。
クラウドランタイムは、ユーザコードをコンテキストでラップするためにノードドメインを使用し、これによりユーザコードのスタックトレースおよびログをキャプチャできる。
０３－ＷＤＴ
Ｗｉｘデータ
Ｗｉｘデータ
ＷｉｘデータＡＰＩ
ＷｉｘデータＡＰＩ。データベースへのアクセスに使用される。ＷｉｘデータＡＰＩは、クライアントサイドのブラウザコード（ＣＳＷＷを参照）とユーザバックエンドコード（ＥＬＭを参照）との両方で使用される。ルータのドキュメントはこちらで参照できる。
ＷｉｘデータＡＰＩモジュールはまた、データ変換およびエラー処理も実行する。
ＷｉｘデータＡＰＩは、ウェブメソッドプロトコル（ＷＢＭを参照）を使用してＷｉｘデータプロバイダと通信する。
Ｗｉｘデータプロバイダ
Ｗｉｘデータプロバイダ。ＡＰＩの実装である。ユーザが自分のバックエンドコードを持たない場合、実装はクラウドマルチテナントサーバでＡＰＩ要求を実行して処理するか、ユーザドッカーコンテナで実行される（ＥＬＷを参照）。Ｗｉｘデータプロバイダは、必要なＷｉｘデータロジックを実行する。
・認証を処理する。パーミッションの構成は、各ロール（サイト所有者、データ所有者、誰でも）が持つパーミッション（読み取り、挿入、更新、削除）を定義します。
・フックを処理する。フックにより、ユーザコードはＡＰＩを介して実行されるＷｉｘデータ要求をインターセプトおよび修正できる（こちらの文書を参照）。
・必要なクエリおよびデータ変換を実行して、高度なＷｉｘデータ機能をサポートする。
○削除されたフィールドを結果から非表示にし、フィルタリングする。
○結果として得られるオブジェクトを計算フィールドで強化する（計算フィールドはスキーマで定義された特別なフィールドであり、既存のフィールドデータに基づいて新しいフィールドを生成できる）。
○参照されたコレクションアイテムを結合する。
○保存されるドキュメントを所有者識別で強化する。
Ｗｉｘデータプロバイダは、ＶＦＳに格納されたスキーマおよびパーミッションを認識している。
ドックストア
ドックストア。ＭｏｎｇｏＤＢとＷｉｘデータプロバイダとの間のブリッジとして機能するサービス。
・ＷｉｘデータからＭｏｎｇｏ形式へのクエリ変換を実行する。
・データベースのコピー機能およびデータ同期機能を含む（これによりサンドボックスからライブおよびテンプレートからユーザサイトにデータを同期できる）。
・ＩＤを生成し、ドキュメントの作成時間および更新時間を格納することにより、データの強化を実行する。
Figure 2024075645000095
ユーザライブラリ
出願人らの知る限り、どのプロジェクトでも（コピーのように）オープンソースコードを直接使用することはない。
ＷｉｘデータＡＰＩおよびＷｉｘデータプロバイダで使用されるオープンソースライブラリは次のとおりである。
Figure 2024075645000096
０４－ＷＢＭ
ウェブメソッド／ＲＰＣ
ＷＢＭウェブメソッド／ＲＰＣ
ウェブメソッドは、ネットワークを介して呼び出され得る、ＥＣＭＡＳｃｒｉｐｔモジュールからエクスポートされた関数である（このようなモジュールはウェブモジュールと呼ばれる）。これは、エンドユーザのブラウザ内のＣＳＷＷで実行されるコードがＥＬＭで実行されるコードとシームレスにやり取りできるようにするメカニズムである。このメカニズムは、どのロールがどのウェブメソッドを呼び出すことを許可されているかの認証を処理し、要求スコープ指定情報をウェブメソッドに投入し、エラーを伝播し、ブラウザコンソールに記録されるＣＳＷＷに記録する。加えて、同じＥＣＭＡＳｃｒｉｐｔモジュールインポート構文を使用して、ＣＳＷＷおよびＥＬＭの両方のユーザコードから同じコードを呼び出すことができる。この手法により、アプリケーションをデバッグおよび開発する際の「単一イメージシステム」の感覚が得られる。
ウェブメソッドのサーバ部分はＥＬＭ内で実行され、ＲＴＲフックおよびカスタムルータ、ＷＤＴフック、ＣＦＮなど、ＥＬＭで実行されるユーザコードからプロミスを返す通常の関数として自由に呼び出すことができる。ＷＢＭはまた、ＷＤＴのためのＲＰＣメカニズムとしても使用されて、バックエンドコードおよびページコードで同じように使用できるようにする。プロミスを返す通常の関数としてウェブメソッドを呼び出すためのＪａｖａＳｃｒｉｐｔプロキシは、ユーザコードにバンドルされ、ＣＳＷＷ内で実行される。
このメカニズムは、次のコンポーネントによって実装される。
・ウェブメソッドドメイン。要求スコープ指定情報をｎｏｄｅ．ｊｓドメインにアタッチし、これは、後でウェブモジュールエクステンションによって生成された関数によって取得され、加えてｎｏｄｅ．ｊｓのデフォルトのロギング関数をオーバーライドして、このドメインにログを収集する。
・ウェブモジュールエクステンション。バベルレジスタを使用して、グローバル要求関数の動作をオーバーライドして、ＥＣＭＳｃｒｉｐｔ ２０１５コードをＥＬＭで使用されるノードのターゲットバージョンに変換し、ユーザウェブモジュールからエクスポートされた関数をラップするために要求メカニズムにフックする。
・ウェブメソッドエクスプレスルータ。エレメントリサポートから到来する要求のためのＥＬＭへのエントリポイントである。ＣＳＷＷからのウェブメソッド呼び出しの認証を
処理する。また、ウェブメソッドの実行が終了すると、ウェブメソッドの実行中に収集されたログを転送する。
・エレメントリサポート。ワイヤプロトコルを介したウェブメソッドのクライアントサイドを提供する。ＣＳＷＷで実行され、ウェブメソッドプロキシによって呼び出される。また、エレメントリから受信したログもユーザのブラウザコンソールに出力する。
・ウェブメソッドプロキシは、ウェブモジュールの静的分析を実行して、エクスポートされる関数を決定することにより生成される。これらは、ＣＳＷＷ内で実行するためのユーザコードにバンドルされる。
ウェブメソッドのロードおよび実行は、ｂａｂｅｌ－ｐｒｅｓｅｔ－ｅｓ２０１５－ｎｏｄｅ６と共にバベルレジスタを使用して実装される。スコープ指定要求は、ユーザコードからインポートされ得るモジュールのファイルシステムの場所を変更するために使用される。ウェブメソッドプロキシは、Ａｃｏｒｎパーサを使用して静的分析を実行し、生成されたプロキシをＢｒｏｗｓｅｒｉｆｙを使用してユーザページコードとバンドルすることで生成される。エレメントリサポートおよびウェブメソッドエクスプレスルータにより使用されるオーバーザワイヤプロトコルは、ネイティブＪａｖａＳｃｒｉｐｔ Ｄａｔｅｓを処理するための拡張機能を備えたＪＳＯＮに基づいている。
コンポーネント図
Figure 2024075645000097
０５－ＺＳＩ
設定不要ＩＤＥ
ＩＤＥ
ＩＤＥコンポーネントは、Ｗｉｘエディタに組み込まれたオンラインコードエディタである。
既存のサイトページのコードを編集したり、Ｗｉｘコードファイルシステムに存在するファイル（パブリックおよびバックエンドファイル）を編集したりするために使用できる。
ＩＤＥはまた、リッチなコンテキストコード補完、Ｗｉｘメディアマネージャの組み込み、コードの書式設定、カスタム警告およびエラーも提供する。
これらのカスタム機能はすべて、Ｏｒｉｏｎと呼ばれる既存のオープンソースＩＤＥの上に構築されている。
コード補完
ＩＤＥは、標準のＪａｖａＳｃｒｉｐｔ環境およびＷｉｘコードＡＰＩの両方に対して、リッチなコード補完をユーザに提供する。
コード補完は、以下の補完を提案できる。
１．ＷｉｘコードコンポーネントＡＰＩ（＄ｗ）。現在のページに存在する要素に応じて提案、例えば「＄ｗ（’＃ｂｕｔｔｏｎ１’）」を提示する。つまり、ユーザには、現在のページに存在する要素についてのみ提案が表示され、他のページの要素については表示されない。これらの提案は、通常のパブリック／バックエンドファイルには表示されず、ページコードを編集する場合にのみ表示される。
２．「ｗｉｘ－ｄａｔａ」、「ｗｉｘ－ｗｉｎｄｏｗ」など、コードのコンテキストに依存しないＷｉｘコードの一般的なＡＰＩ。つまり、ページのコードを編集するとき、または通常のパブリック／バックエンドファイルにおいて利用可能である。
３．ＪＳオブジェクトおよび関数、例えば「ｃｏｎｓｏｌｅ．ｌｏｇ（）」もまた、すべてのファイルタイプで利用可能である。
４．テンプレート。モジュールのインポート（例えば、「’ｗｉｘ－ｌｏｃａｔｉｏｎ’から場所をインポートする」）と、ｆｏｒループなどのＪＳ共通テンプレートと、の両方のテンプレート提案を提供する。
５．関数パラメータ。関数のパラメータおよび名前を提示する。
コード補完ウィジェットはまた、選択されたすべての提案の簡単な説明を完全なドキュメントへのリンクと共に提供する。
メディアマネージャの組み込み
ユーザは、画像要素のソースを変更するコードをサイトに追加できる。つまり、実際に表示されるイメージを置き換える。ユーザは、画像のソースプロパティを任意の画像ＵＲＬに、またはＷｉｘメディアマネージャからの画像に設定できる。ソースプロパティを設定しようとする場合、コード補完ウィジェットはメディアマネージャを開くことを提案します。そこで、ユーザは画像を選択でき、そのＵＲＬ（カスタムＷｉｘコードＵＲＬプロトコル）がコードに貼り付けられる。例えば、「＄ｗ（”＃ｉｍａｇｅ１”）．ｓｒｃ＝”ｉｍａｇｅ：／／ｖ１／６ｅ７９５８ｄｅ７８６８４２ｅｂ８１１１４９ａｃ９ｃ２５ｆ７３ｃ．ｊｐｇ／２３６２＿４７２４／Ｃｏｔｔｏｎ Ｃａｎｄｙ Ｃｏｎｅ”」。ユーザはまた、ＵＲＬにカーソルを合わせることができ、画像を表示するツールチップが開き、画像を置き換えるメディアマネージャを開くためのリンクが表示される。
技術的情報
ＩＤＥは、オープンソースプロジェクトＯｒｉｏｎ［ｈｔｔｐｓ：／／ｗｉｋｉ．ｅｃｌｉｐｓｅ．ｏｒｇ／Ｏｒｉｏｎ］の上に構築される。独自のカスタムエクスペリエンスとＷｉｘ固有のバグ修正と動作の変更を提供するために、Ｏｒｉｏｎからの特定のモジュ
ールを独自のモジュールでオーバーライドする。元のＯｒｉｏｎコードを修正する代わりに、カスタムモジュールの読み込み構成があり、これは、元のモジュールの代わりにオーバーライドするモジュールをロードすることを把握し、コードを元のソースコードから分離する。
ＯｒｉｏｎおよびＯｒｉｏｎの依存関係を除き、プロダクションコードでは他のライブラリまたはパッケージを使用しない。
コードを構築してテストするために、無数のオープンソースパッケージ、例えばｇｒｕｎｔ、ｍｏｃｈａ、ｋａｒｍａ、ｓｅｌｅｎｉｕｍ－ｗｅｂｄｒｉｖｅｒ、ｌｏｄａｓｈなどを使用する。これらのパッケージのためのコードは開発時にのみ使用され、最終製品の一部としては出荷されない。
コード補完を提供するために、内部モジュール「ｗｉｘコード参照ドック」に依存している。このモジュールは、ＡＰＩ（＄ｗなど）を公開するすべてのＷｉｘコードライブラリに依存し、コード補完を提供するために必要なすべての情報を保持する１つの大きなファイルを構築する。このファイルは、構築プロセス中にコピーされ、ＩＤＥによって実行時に使用される。
コード全体はＪａｖａＳｃｒｉｐｔで記述される。
０６－ＥＰＴ
エディタプラットフォーム
エディタプラットフォーム
クライアントサイドウェブワーカーおよびＳＤＫを使用することにより、ウェブアプリケーションでカスタムコードを実行させることができる。このプラットフォームにより、再利用可能なコードを記述でき、したがって、同じウェブアプリケーション内で、また複数のウェブアプリケーションにわたって複数のインスタンスに配信することができる。このプラットフォームは、次のコンポーネントから構成される。
・アプリグローバルエンティティ：パート間での共有状態。
・ルータ：ＵＲＬおよびページ解像度の制御。
・コントローラ：アプリのロジックチャンク、複数のインスタンス。
・ＡＰＩ：すべての公開および混合。
アプリケーショングローバルエンティティ
アプリケーションのグローバル状態により、次のようなシナリオが可能になる。
・ショッピングカート、多段階の購入エクスペリエンス中のアイテムの集約
・複数ページのウィザードエクスペリエンス
・多段階のチェックアウトエクスペリエンス（カート、配送情報、アカウント情報）
・終了後にすべての情報を保存するオーサリングエクスペリエンス
このプラットフォームにより、ユーザコードがアプリケーションのグローバル状態を保存できて、上記のシナリオを可能し得る。また、クライアントのウェブワーカーがアプリケーションのロジック態様に影響を与えずにページの遷移およびクリーンアップを実装するための抽象化も提供する。
アプリケーションルータ
アプリケーションはルータを作成し（セクション８を参照）、これをウェブサイトに登録できる。アプリケーションは構成情報をウェブサイトに保存でき、これにより、アプリケーション開発者はルータのための単一サーバエンドポイントを作成でき、分散ターゲットごとに複数の構成をとることができる。ブログのルーティング要件の例は次のとおりであり得る。
１．ｄｏｍａｉｎ．ｃｏｍ／ｂｌｏｇ／２０１６／０７／２６／ｍｙ－ｐｏｓｔ
→１．「ｍｙ ｐｏｓｔ」を表示する一般的な投稿ページ
２．ｄｏｍａｉｎ．ｃｏｍ／ｂｌｏｇ／２０１６／０７／２６
→２．２０１６年７月２６日からのすべての投稿
３．ｄｏｍａｉｎ．ｃｏｍ／ｂｌｏｇ／２０１６／０７
→３．２０１６年７月からの最初の１０件の投稿
４．ｄｏｍａｉｎ．ｃｏｍ／ｂｌｏｇ／２０１６／０７？ｐａｇｅ＝２
→４．２０１６年７月からの＃１１～＃２０の投稿
５．ｄｏｍｉｎ．ｃｏｍ／ｂｌｏｇ／ｔａｇ／ａ－ｔａｇ－ｉ－ｕｓｅ－ａ－ｌｏｔ
→５．「ａ－ｔａｇ－ｉ．．．」とタグ付けされた最初の１０件の投稿。
６．ｄｏｍａｉｎ．ｃｏｍ／ｂｌｏｇ／ｃａｔｅｇｏｒｙ／ｍｙ－ｃａｔｅｇｏｒｙ
→６．「ｍｙ ｃａｔ．．」というカテゴリからの最初の１０件の投稿
７．ｄｏｍａｉｎ．ｃｏｍ／ｂｌｏｇ／２０１６／０７／２６／ｍｙ－１００ｔｈ－ｐｏｓｔ
→７．第１００番目の投稿のためにデザインされた特別な投稿ページ
アプリケーションがルータを構成し、これをインスタンス／サイトごとに保存できるようにすることにより、ルータサーバコードが１回作成され、ＵＲＬ構造は同じでも異なるＵＲＬ形式（日付あり／なし）および特定の投稿のための特定のページをサポートできる。一般的な使用法は次のとおりである。
・特異性に基づいたカスケードページテンプレート（すなわち、アイテム→製品→デジタルグッズ）
・ＳＥＯ（検索エンジン最適化）要件に基づく様々なＵＲＬ形式
・ＣＭＳ（コンテンツ管理システム）においてコンテンツを追加することによるページの追加
コントローラ
コントローラにより、ユーザコードの作成者は、コードをコンポーネントのリストと共に再利用可能な仕方でパッケージ化できる。通常の（Ｗｉｘコード）メソッドでは、ユーザはページに一意のＩＤに基づいてコンポーネントにアクセスする。このことは、同じページで２回まで使用するオプションを減らし、配信が困難にする。コントローラには次のプロパティがある。
・構成であり、サイトに保存する。この構成により、コントローラのインスタンスを別のインスタンスと区別する仕方が提供されるため、コードを再利用できる。例えば、コントローラコードが外部データソースに接続し、情報を取得し、画像およびテキストを使用してそれを提示する場合、構成はリモートシステムにおけるアイテムＩＤになる。このように、同じページ上の２つの別個のコントローラは、異なる画像およびテキストコンポーネントを使用して、リモートシステムにおいて２つのアイテムを表すことができる。
・ロール（文字列）を名前として使用し、接続構成を使用したコンポーネントへの接続。これにより、コンポーネントがページで受け取るＩＤに関係なく、コントローラコードを事前に記述してから配信できる。これは、同じＩＤを持つことができない２つの異なるコンポーネントにアクセスする同じページ上の２つ以上のコントローラに特に役立つ。ほとんどの場合、コントローラはロールを使用して操作するためにコンポーネントを選択する（セクション１５のセレクタを参照）。各コンポーネントには複数のロールを定義して、複雑なデータバインディングシナリオと行動プログラミングモデルを実現できるが、複数のコントローラは定義できない。（つまり、各コントローラはコンポーネントの異なる態様を担当する。例えば、ドロップダウンコンポーネントは１つのコントローラからオプションのリストを取得し、選択したパラメータを別のコントローラに保存できる）。
ＡＰＩ
各コントローラは、独自のＡＰＩを公開できる。これにより、コントローラがコンポーネントとして表示され、同様の動作が行われる。サイトレベルまたは他のコントローラの他のコード作成者がコントローラコードをブラックボックスとして再利用できるようにし、コントローラをランタイム環境の拡張ブロックに変える。
０７－ＣＳＷＷ
クライアントサイドウェブワーカー
クライアントサイドウェブワーカー
クライアントサイドウェブワーカーにより、カスタム機能を使用してウェブサイトを拡張できる。その拡張の最も一般的な使用法は次のとおりである。
・サイトの動的コンテンツ強化
・カスタムユーザフロー
・カスタム対話
これを可能にするために、ＳＬＡ、セキュリティ、およびこれらの拡張機能をユニファイドクラウドでホストする能力を維持しながら、次のアーキテクチャが使用される。
Figure 2024075645000098
以下は、システムの論理コンポーネントのリストである。
・サイトトップフレーム：これはウェブアプリケーションのメインページである。ユーザのドメインまたはホスティングサービスの一般的なドメイン（Ｗｉｘ）で提供される。これはウェブアプリケーションを実行するメインエンジンであり、別名「ビューア」または「ランタイム環境」である。
・ＩＦｒａｍｅサンドボックス：悪意のあるコード（クッキーハイジャックなど）からトップフレームのセキュリティを保護するために、異なるドメインを持つＩＦｒａｍｅが構築される。ドメインの違いは、サンドボックスシステムリソース（ウィンドウ、クッキーなど）およびメモリである（すべての通信はｐｏｓｔＭｅｓｓａｇｅのみを使用して実行でき、メモリ共有は使用できない）。
・ウェブワーカー：ウェブワーカーは、非同期コードの実行を可能にする標準的なブラウザ機能である。すべての通信はｐｏｓｔＭｅｓｓａｇｅを介して可能であり、ウェブワーカーでグローバルに利用可能なＡＰＩサーフェスはトップフレームよりもはるかに制限されているため、ウェブワーカーはトップフレームに別の保護レイヤを作成する。例えば、ウィンドウグローバルオブジェクトは利用可能ではなく、ＤＯＭ（ドキュメントオブジェクトモデル）アクセスは禁止されており、つまり、ウェブワーカーコードはＵＩ要素を操作できない。ウェブワーカーのセキュリティ上の利点に加えて、非同期の性質により、ウェブワーカーがＣＰＵを集中的に使用している場合でもトップフレームが応答を停止することはないことが確保される。別の利点は、トップフレーム実行コンテキストを遮るこ
となくユーザコード（ウェブワーカーで実行中のコード）をデバッグおよび一時停止できユーザが、ブレークポイント中でも、ＵＩレイヤにおいてユーザコードの伝播を確認できることである。
・ＲＭＩ（リモートモデルインターフェース）：このコンポーネントは、トップフレームの論理モデルを作成および維持し、ｐｏｓｔＭｅｓｓａｇｅトランスポートレイヤを介してウェブワーカーと共有する役割を果たす。モデルの変更は、ウェブアプリケーションに影響を与える。例えば、ボタンのテキストおよびリンクはモデルで表される。モデル内のこれらの値の変更は、視覚的なボタンコンポーネントおよびその機能に影響を与える。加えて、ＲＭＩレイヤにより、ウェブワーカーがトップフレームで事前定義されたメソッドを呼び出すことができる。これは、ウェブワーカーの機能を強化し、モデル（すなわち、アニメーション）で表されるように、状態に関連しないアクションを実行するために使用される。リモートモデルは非同期バリアをブリッジし、同期コードをユーザコードが認識できるようにし、これは、記述は単純であるが、アクションは非同期である。例えば、ユーザコードは画像ＵＲＬをＡからＢに変更する。コードの次の行は、次のアクションを決定するための値を示す。モデルの値は既にＡからＢに変更されているため、一貫した値であるＢを返すが、モデルの非同期動作は、ウェブアプリケーションのＵＩに既に表示されていることを保証しない。
・ＳＤＫ：ＳＤＫは、ＲＭＩモデルの上にあるラッピングレイヤである。より単純なＡＰＩをユーザコードに公開し、モデルを一貫性のあるドキュメント化されたメソッド呼び出しならびにプロパティセッターおよびゲッターに簡素化するために使用される。ライフサイクルメソッドおよび＄ｗオブジェクトをユーザコードのベースコンテキストとして公開する。詳細な説明は、セクション１５で提供される。
０８Ａ－ＲＴＲ
ルータ
ＲＴＲ ルータ
ルータにより、サイト所有者がサイトのカスタムＵＲＬ構造を定義できる。ルータは、特定のＵＲＬをページに解決するために動的ページによって使用され、サイトマップ要求を介してサイトで利用可能なすべてのページを取得するためにＳＥＯおよびエディタによって使用される。ルータはまた、ページに関連付けられる追加のＳＥＯ情報も公開する。ルータには２つのタイプ、すなわちデータバインディングルータおよびカスタムルータがある。ルータはＥＬＭ内で実行されるバックエンドコンポーネントである。
データバインディングルータは、サイト所有者から提供された１つ以上のデータベースフィールドおよびカスタムテキストフラグメントに基づいてＵＲＬ構造を自動的に接続する。これは、エディタのＵＩを使用して完全に実行でき、ユーザコードは必要としない。加えて、これらのルータはフックによってカスタマイズされ、これにより、ユーザコードがルータに渡されるパラメータを修正し、応答を修正し、ＷＤＴに発行されたクエリを修正できる。
カスタムルータは、サイトの所有者にＵＲＬ構造の完全な制御を提供する。エディタから、サイトの所有者は特定のプレフィックスのためのルータを作成でき、ＵＲＬの残りの部分がカスタムルータによって解釈される。ルータ要求は、ユーザが提供する２つの関数、すなわちルータ関数およびサイトマップ関数により処理される。ルータ関数は、単一のＵＲＬの特定のページへの解決を処理する。ＷｉｘルータＡＰＩは、この要求に渡されるデータを説明している。この関数は、追加のＳＥＯ情報と共に、ＡＰＩで事前定義された応答（例えば、ＯＫ、見つかりません、禁止など）のうちの１つを返すことが期待されている。サイトマップ関数は、ルートで利用可能なすべてのページをリストすることが期待されていることを除いて同様である。
動的ルーティングは、２つのコラボレータによって実現され、１つはユーザのブラウザで実行され、もう１つはバックエンドで実行される。動的ルータにより処理されるＵＲＬを介してページがロードされると、ブラウザにデフォルトのＨＴＭＬページがロードされ
、表示するページを判定するためにバックエンドに対してＡＪＡＸ要求が行われる。コードのバックエンド部分は、どのプレフィックスがどのルータで処理されるかを認識していない。ルータが表示することを選択できるページを含む、ＵＲＬを解決するために必要なすべてのデータはこの要求で送信され、バックエンドからの応答は、ページの適切な動的ページを開き、それにデータを投入するために使用される。ルータは、ページが開かれるときにページに公開されるデータを入力することを選択でき、そのため、サーバへの別のラウンドトリップを回避できる。
０８Ｂ－ＲＴＲ
ルータ－詳細
動的ルーティング
データバインディングルータ
カスタムルーティング
はじめに
動的ルーティングモデル
動的ルーティングモデルの基本コンポーネント
ルーティングのさらなる詳細な説明
ルータエンドポイント
ＵＲＬ解決エンドポイント
ＵＲＬ解決エンドポイント入力
ＵＲＬ解決エンドポイント出力
ページロールの詳細
サイトマップエンドポイント
サイトマップを正しく実装する
ユーザクレデンシャルの考慮
４０４応答コードを返すことになるＵＲＬの考慮
ルートの考慮
動的ページ上の「ノーインデックス」フラグの考慮
サイトマップエンドポイント入力
サイトマップエンドポイント出力
注記：プレビューピッカー
注記：リンク作成
動的ルーティングおよびＳＥＯメタタグ
ＨＴＴＰクッキーおよびヘッダ
４０４ページおよび４０３ページ
動的ルータを実装する際のクロスドメインの問題
完全な例
データバインディングルータ
データバインディングのコンセプトの簡単な要約
データバインディングルータ
ＵＲＬをＷｉｘデータクエリに変換する
データをクライアントに返す
データセットを用いて取得したデータをＵＩ要素にバインドする
ＵＲＬパターンからリンクを作成する
スキーマの拡張
一時的計算フィールド
参照フィールド
データバインディングルータに関する他の考慮事項
データバインディングルータにおけるページロール
ＳＥＯメタタグを指定する
サイトマップエンドポイント
データバインディングルータ上のフック
未解決の問題
カスタムルータ
はじめに
このドキュメントでは、エディタ／ビューアスタックに追加する予定の動的ルーティング機能の背後にあるアーキテクチャおよび様々なサブシステムを概説する。次に、このドキュメントでは、新しいデータバインディングルータを概説し、動的ルーティングモデルの上に構築する仕方について概説する。最後に、このドキュメントでは、開発者が独自の動的ルーティング実装を作成するためにカスタムルータを構築する仕方について説明する。
動的ルーティングモデル
動的ルーティングにより、ｗｉｘサイト／アプリで動的ＵＲＬを定義および管理できる。これにより、ユーザおよびエディタアプリは、公開時に知られるＵＲＬを持つ静的なページ以上のものを持つサイトを作成できる。
最終的にユーザおよびアプリは次のことができる。
－具体的なレンダリングされたページにマップするＵＲＬパターンを定義する
－コンテンツが到来する動的ＵＲＬに依存する動的ページを作成する
－これらのＵＲＬをボット（検索エンジンおよび同様の自動化されたコンシューマ）に公開する
動的ルーティングモデルの基本コンポーネント
このモデルの基本コンポーネントは、アプリ、ルータ、ルート、ルータエンドポイント、ＵＲＬ、動的ページ、ページロール、およびサイトマップである。以下では、それらと、それらがやり取りして動的ルーティングモデルを作成する仕方について説明する。
動的ルーティングを可能にする基本的な構造はルータである。ルータはアプリによって所有される。必要に応じて、各アプリに複数のルータがある場合がある。
ルータは、特定の到来するＵＲＬを、ビューアがレンダリングする特定の動的ページに解決する役割を果たす。
到来する動的ＵＲＬは次の構造を有する：＜ｓｉｔｅ＞／＜ｐｒｅｆｉｘ＞／＜ｓｕｆｆｉｘ＞：
－＜ｓｉｔｅ＞：プレミアムサイトの場合は＜ｍｙ．ｓｉｔｅ．ｃｏｍ＞の形を有し、無料サイトの場合は＜ｕｓｅｒ＿ｎａｍｅ．ｗｉｘｓｉｔｅ．ｃｏｍ／ｓｉｔｅ＿ｎａｍｅ＞の形を有する。
－＜ｐｒｅｆｉｘ＞：この部分は、到来するＵＲＬを処理するルータを判定する部分である。各ルータは、サイトヘッダに１セットの一意のプレフィックスを登録する。この情報は、エディタランタイムによって管理される。エディタは、２つのルータが同じプレフィックスを定義しないことを確保する。
－＜ｓｕｆｆｉｘ＞：プレフィックスの後に来るあらゆるもの。この部分は、プレフィックスと共に、到来するＵＲＬを解決するためにルータによって後で使用される。
各ルータは１つまたは複数のルートをサポートする。ルートは、ＵＲＬの＜ｓｕｆｆｉｘ＞部分のテンプレートである。ルートの例（ルートを太字で示す）は次のとおりである。
－ｍｙ．ｓｉｔｅ．ｃｏｍ／ｂｌｏｇ／
－ｍｙ．ｓｉｔｅ．ｃｏｍ／ｂｌｏｇ／ｐｏｓｔ－｛ｉｄ｝
－ｍｙ．ｓｉｔｅ．ｃｏｍ／ｂｌｏｇ／｛ｙｅａｒ｝／｛ｍｏｎｔｈ｝／
－ｍｙ．ｓｉｔｅ．ｃｏｍ／ｂｌｏｇ／ｆｅａｔｕｒｅｄ－ｐｏｓｔｓ
アプリは、可能なすべてのルートを常にサポートするのであってもよいし、有効にするルートと無効にするルートとをユーザに選択させるのであってもよい。例えば、ブログア
プリでは、注目記事機能を使用するか否かを決定するのはユーザに委ねられていてもよい。
異なるルート間の違いを認識できるように確保するのは、アプリおよび特定のルータに委ねられていることに留意されたい。ブログアプリのための次の２つのルートを考える。
－ｍｙ．ｓｉｔｅ．ｃｏｍ／ｂｌｏｇ／｛ｙｅａｒ｝／
－ｍｙ．ｓｉｔｅ．ｃｏｍ／ｂｌｏｇ／｛ａｕｔｈｏｒ｝／
到来するＵＲＬを復号するために使用するルートを判断するのが難しい場合がある－「２０１６」という名前の作成者がいる可能性がある－そのような場合には、代わりに次のルートを作成する方がよい場合がある。
－ｍｙ．ｓｉｔｅ．ｃｏｍ／ｂｌｏｇ／｛ｙｅａｒ｝／
－ｍｙ．ｓｉｔｅ．ｃｏｍ／ｂｌｏｇ／ａｕｔｈｏｒｓ／｛ａｕｔｈｏｒ｝／
動的ページは、単純に、ルータがルーティングできる任意のページである。動的ページはルータによって所有されている。つまり、すべてのルータは、そのルータだけがルーティングできる１セットの動的ページを有する。したがって、ルータは「レガシー」静的ページにルーティングできない。
各動的ページには、１つまたは複数のページロールが割り当てられる。ページロールは、ルータが、到来するＵＲＬを、レンダリングするための具体的なページに解決する仕方を決定するのに役立つ。
（簡略化された）アルゴリズムは次のように動作する。
１．［ビューアランタイム］＜ｐｒｅｆｉｘ＞部分に基づいて、到来するＵＲＬが解析されて、どのルータがそれを解決するかを決定する
２．［ビューアランタイム］は、選択したルータのＵＲＬ解決エンドポイントを呼び出し、ルータが特定の動的ページＩＤにＵＲＬを解決するために必要な情報を渡す。
３．［選択されたルータ］到来するＵＲＬのためのページロールの順序付きリストを計算する
４．［選択されたルータ］動的ページのリストとそれに関連付けられたページロールに基づいて、解決する動的ページＩＤを選択する。順序付きリストの各ページロールについて、ルータはそのロールに整合する動的ページを探す。そのロールを持つ動的ページが見つかると、検索は終了する。ページが見つからない場合、ＵＲＬは４０４応答コードに解決される。
５．［選択されたルータ］選択されたページＩＤを、動的ページ（最も重要なこととして、オプションのデータペイロード）のレンダリングに必要な補助情報と共に、ビューアに返す。
６．［ビューア］選択された動的ページをレンダリングする
ルータが異なる到来するルートを同じページＩＤに解決するのはまったく問題ないことに留意されたい。例えば、動物園管理アプリケーションを考える。このアプリケーションは、＜ｚｏｏ＞プレフィックスの下にルータを登録し、次の２つのルートをサポートする。
－／ｚｏｏ／ａｎｉｍａｌ＿ｏｆ＿ｔｈｅ＿ｄａｙ
－／ｚｏｏ／ａｎｉｍａｌｓ／｛｛ａｎｉｍａｌ＿ｎａｍｅ｝｝
この場合、両方のルートともページロール｛ａｎｉｍａｌ＿ｐａｇｅ｝に解決される。到来するＵＲＬが＜／ｚｏｏ／ａｎｉｍａｌｓ／ｔｉｇｅｒ＞であり、現在虎が「今日の動物」である場合、両方のルートとも動物をレンダリングする動的ページに解決され、両方とも画面上に美しい虎をレンダリングする。
ルーティングのさらなる詳細な説明
これまで見てきたように、ビューアはルータを使用して、レンダリングするためのページを解決する。しかしながら、動的ページを正しくレンダリングするためには、考慮すべき点がさらにいくつかある。
このことを詳細に説明するこちらの図を参照されたい。
ルータエンドポイント
各ルータは、次の２つのエンドポイントをサポートする必要がある。
－ＵＲＬエンドポイントの解決：到来するＵＲＬをページＩＤに解決するために使用される
－サイトマップエンドポイントの取得：このルータが解決できるＵＲＬの完全なリストを取得するために使用される
これらのエンドポイントおよびその動作の詳細を以下に示す。
ＵＲＬ解決エンドポイント
このエンドポイントは、到来するＵＲＬを特定の動的ページに解決する必要がある場合に使用される。
ＵＲＬ解決エンドポイント入力
到来するＵＲＬを解決するために、ルータは次の情報を潜在的に必要とする。
－ＵＲＬのパート（サイト、プレフィックス、サフィックス）。これにはＵＲＬクエリ文字列（「？」の文字の後、および「＃」の文字の前のパート）を含める必要があることに留意されたい。
－アプリ符号付き署名インスタンス：ルータエンドポイントは、到来する要求がどのサイトからのものであるかがわかるように、アプリケーションインスタンスＩＤを知っている必要がある。例えば、ブログアプリケーションを考える。特定のブログ投稿に関して到来するＵＲＬを解決するには、ルータはブログアプリインスタンスを知っている必要がある。
－ユーザクレデンシャル：符号付きインスタンスの一部である。ルータは、現在要求を発行しているユーザのユーザクレデンシャルを知る必要がある。これは、例えば、そのユーザが要求された特定のページの情報を表示することを許可されているか否かを知るために必要とされている。例えば、ブログルータは、匿名ユーザがｍｙ．ｓｉｔｅ．ｃｏｍ／ｂｌｏｇ／ａｄｍｉｎの背後にあるページを表示することを禁止したい場合がある。
－ルートアレイ：［これはルータ構成の一部である。］このアプリインスタンスがサポートするルートの配列。通常、各ルートは、そのＵＲＬパターン、この特定のルートに関するタイトルおよび他のＳＥＯメタタグなどに関する情報を提供する。詳細については、以下のＳＥＯセクションを参照されたい。
－ルータ構成：アプリおよびルータ固有の追加情報。例えば、ブログアプリを考える。このアプリが所与の著者のすべての投稿を含む動的ページを提供すると仮定する。このようなページのＵＲＬは、ｍｙ．ｓｉｔｅ．ｃｏｍ／｛｛ａｕｔｈｏｒ＿ｎａｍｅ｝｝のようになる。この場合、これらのＵＲＬを処理するルータがあり、投稿データベース内の特定の著者ＩＤに著者名をマッピングできる必要がある。そのマッピングを行うために、ルータ構成は次のものを持つ：｛ａｕｔｈｏｒ＿ＩＤ：１２３｝．ルータエンドポイントが呼び出されると、ａｕｔｈｏｒ＿ＩＤ １２３の投稿が取得される。
－動的ページおよびそれに関連するロールのリスト：上記で説明したようなロールマッチングに基づいてレンダリングするページＩＤを選択するためにルータによって使用される。
ＵＲＬ解決エンドポイント出力
－ルータがＵＲＬを解決した一次結果をレンダリングするためのページＩＤ。
－ＨＴＴＰ応答コード：ＵＲＬを扱っているため、可能性のあるＨＴＴＰ応答コードを考慮する必要がある。具体的には、応答コードは｛２００、３０１、３０２、４０３、４０４｝を含む。ビューアランタイムはこれらのコードを使用して正しく動作する。
－データペイロード：ルータは、後で特定の動的ページのレンダリングに使用されるデータペイロードを返す可能性がある。このペイロードは、例えば、ページ上のコンポーネ
ントにバインドするために使用されるデータセットに供給できる。
－タイトル：レンダリングされるページのタイトル。ビューアランタイムはこれを使用して、ブラウザのためのページのタイトルを設定する。タイトルは、特定の動的ページに対して取得されたコンテンツに基づいて計算され得る。通常、ルートが異なるとタイトルが異なり得る。例えば、＜／ｚｏｏ／ａｎｉｍａｌ＿ｏｆ＿ｔｈｅ＿ｄａｙ／＞というルートは、「今日の動物－虎！」というタイトルと共に動物を表示する動的ページに解決され得る。＜／ｚｏｏ／ａｎｉｍａｌｓ／ｔｉｇｅｒ＞というルートは同じ動的ページに解決され得るが、タイトルは単に「当園の虎」になり得る。したがって、タイトルを作成するためのテンプレートは通常、その特定のルートのためのルータ構成の一部である。
－ＳＥＯメタタグ：ＳＥＯ関連の情報。これについては後で詳述する。
ページロールの詳細
上で説明したように、システムはページロールを使用して、解決する実際の動的ページを判定する。ページロールにより、アプリはフォールバックを作成できる。つまり、アプリのユーザが特定のコンテンツのために特定の動的ページを作成でき、これが他のコンテンツに使用される標準の動的ページとは異なる場合があることを意味する。
例えば、ブログアプリでは、２つの異なる動的ページが存在し得る。
－＜ｐｏｓｔ－ｐａｇｅ＞というロールを持つ標準の投稿ページ。
－＜ｐｏｓｔ－ｐａｇｅ－ｉｄ－１２３＞というロールを持つ特定の投稿ページ。
ルータは、＜ｓｉｔｅ＞／＜ｂｌｏｇ＞／＜ｐｏｓｔ－ｉｄ－ｘｘｘ＞という形式の到来するＵＲＬを解決する。次のページロール順序付きリストを計算する：｛ｐｏｓｔ－ｐａｇｅ－ｉｄ－ｘｘｘ，ｐｏｓｔ－ｐａｇｅ｝。
１２３以外のＩＤを持つすべての到来するＵＲＬについては、ルータは標準の投稿ページに解決します。しかしながら、＜ｓｉｔｅ＞／＜ｂｌｏｇ＞／＜ｐｏｓｔ－ｉｄ－１２３＞というＵＲＬについては、ルータはその１２３投稿のための特定のページに解決する。
このメカニズムにより、動的ページを解決するためのフォールバック方針を作成している。後でユーザがポストＩＤ ３２１に特定のページを追加することを決定した場合、必要なのは正しいページロールを持つ新しい動的ページを追加することだけであり、ルータはそのページに解決することを把握する。
サイトマップエンドポイント
サイトマップは、所与のサイトで公開されているＵＲＬのリストである。動的モデルのコンテキストでは、このリストはＵＲＬのリストを含み、それぞれについてサイトマップのコンシューマが必要とする情報が追加されている。
サイトマップは２つの異なるシナリオのために働く。
－まず、サイトマップは、サイト内のページのリストをボット要求に公開するという従来の目的に使用される。このシナリオでは、ルータサイトマップエンドポイントは、解決できるＵＲＬの完全なリストを計算し、それらを到来するボット要求に返す。
－次に、サイトマップはエディタでも使用できる。このシナリオでは、エディタはサイトマップエンドポイントに要求を発行し、返された結果を使用して、返されたＵＲＬのうちの１つをエンドユーザに選択させる。これは、２つの異なるケースで役立つ。
－ユーザが動的ページへのリンクを作成するとき。リンクを作成するには、エディタはリンク先の完全なＵＲＬを必要とする。
－ユーザが動的ページをプレビューしたいとき。この場合、正しくレンダリングするために必要なデータをページに提供する仕方を知るために、このページに解決する正確なＵＲＬを知る必要がある。
サイトマップを正しく実装する
次の態様を考慮する必要がある。
ユーザクレデンシャルの考慮
ＵＲＬのリストでは、呼び出しのためのユーザクレデンシャルを考慮する必要がある。ボット（匿名）要求の場合、サイトマップにはパブリックに利用可能なＵＲＬのみを含める必要がある。ボットは、匿名ユーザに禁止されているＵＲＬを見るべきではない。例えば、＜ｍｙ＿ａｐｐ＞というプレフィックスのルータを持つアプリがあると仮定する。そのアプリが、＜ｓｉｔｅ＞／＜ｍｙ＿ａｐｐ＞／＜ａｄｍｉｎ／ｓａｌａｒｉｅｓ＞の下に従業員の給与を管理するためのページを有する場合、このＵＲＬは呼び出し元に返されない。
４０４応答コードを返すことになるＵＲＬの考慮
ルータが特定のＵＲＬを解決できる可能性はあるが、サイトがそのＵＲＬをレンダリングする正しいページロールを持つ動的ページを定義していない可能性がある。これらの場合、ルータは４０４応答コードに解決される。ボット要求に返す結果から、このようなエントリを除去するのは、ルータのサイトマップエンドポイントの役割である。
ルートの考慮
ルータは、特定のサイトで使用されていないルートを潜在的にサポートし得る。例えば、＜／ｐｏｓｔｓ／ｐｏｓｔ－ｉｄ＞や＜／ｐｏｓｔｓ／ｆｅａｔｕｒｅｄ－ｐｏｓｔｓ＞などのルートをサポートするブログルータを考える。しかしながら、特定のサイトのブログインスタンスでは、ユーザが注目記事機能を使用しないことを決定していることがあり、そのため、どの投稿も注目としてマークせず、注目記事のための動的ページさえも作成していない。
そのような場合、サイトマップはこのＵＲＬを返すべきではなく、そうでないと、ボットはそれを探して４０４応答を取得するか、さらに悪いことには、空の投稿リストを持つ別の動的ページを取得する。
これらの問題を回避する方法は、サイトマップ生成で、サイト内のアプリインスタンスでサポートされるルートを考慮し、サポートされるルートのＵＲＬのみを生成することである。
動的ページ上の「ノーインデックス」フラグの考慮
ユーザは、動的ページを「ノーインデックス」としてマークする場合がある。これは、検索ボットによりインデックスされるべきではないことを意味する。サイトマップエンドポイントがＵＲＬのリストを計算するとき、各ＵＲＬが解決するページＩＤも計算する必要がある。そのページＩＤが「ノーインデックス」としてマークされている場合、そのＵＲＬはリストから除去されるべきである。
サイトマップエンドポイント入力
サイトマップを計算するために、エンドポイントは次の入力に依拠する。
－符号付きインスタンス：生成するアプリインスタンスのサイトマップを知るためにエンドポイントによって使用される
－ユーザクレデンシャル：符号付きインスタンスでエンコードされているため、ルータは、ユーザが表示を許可されているＵＲＬを含むサイトマップを生成できる。
－「Ｉｓ＿ｅｄｉｔｏｒ」フラグ：これにより、エンドポイントは、エディタの使用に適したサイトマップを生成できる。エディタは、サイトマップをエンドユーザに表示するための情報を必要とするが、これはボットは要求していない。
－ルータ構成：この特定のルータがサイトマップを生成する仕方に関する情報。
－このサイトで使用中のルート：（ルータ構成の一部として）サポートされるルートのリスト。生成されるサイトマップは、この特定のサイトにおいてこのアプリの特定のインスタンスで使用中のルートのみを含むべきである。
－このルータの動的ページおよびそのページロールのリスト：動的ページに実際にマップされるＵＲＬのみがサイトマップに含まれるようにするために使用される。どのページにも解決しないＵＲＬは、リストから除外する必要がある。
－このルータの動的ページごとの「ノーインデックス」フラグ（ルート構成の一部）：「ノーインデックス」とマークされたページに解決されるＵＲＬは、ボット用に生成されたサイトマップに表示されるべきではない。しかしながら、要求がエディタから到来する場合は、同じＵＲＬを含めるべきであり、なぜならその場合には、解決されたページにインデックスされているか否かは関係ないためである。
サイトマップエンドポイント出力
ボット要求の場合、以下が出力されるべきである。
－ボットがスキャンするＵＲＬのリスト
－ＵＲＬごとに、次の（すべてオプションの）パラメータ：
－最終変更日
－変更頻度
－インデックスする優先順位
１つのサイトマップ要求は５０，０００個を超えるＵＲＬを返すべきではないことに留意されたい。この段階では、出願人らは結果のページングをサポートする予定はない。５０，０００を超えるＵＲＬがある場合は、余分なＵＲＬを省略されたい。
ボットのためのサイトマッププロトコルの完全な仕様については、こちらを参照されたい。
エディタ要求の場合、以下が出力されるべきである。
－ＵＲＬのリスト
－ＵＲＬごとに、次のパラメータ：
－扱いやすいタイトル。エディタで特定の動的ページへのリンクを作成するときに使用され、またエディタのプレビューピッカーボックスにより使用される。
－このＵＲＬが解決されるページＩＤ。エディタのリンク作成ダイアログにより使用されて、ユーザが特定の動的ページに解決するＵＲＬを選択できるようにする。
注記：プレビューピッカー
ユーザが動的ページをプレビューしようとする場合、エディタはこの動的ページに使用するＵＲＬサフィックスを知っている必要がある。プレビューピッカー要素はサイトマップを呼び出し、この動的ページＩＤに解決されるＵＲＬの結果をフィルタリングする。次に、ユーザはリストをブラウズし、その扱いやすいタイトルによりＵＲＬを選択する。エディタは、ここで、動的ページをレンダリングするために使用する正しいＵＲＬサフィックスを把握している。
注記：リンク作成
ユーザが動的ページへのリンクを作成しようとしていると仮定する。エディタはサイトマップを取得し、このページＩＤにマップするＵＲＬを探す。ユーザは、その扱いやすいタイトルを見てＵＲＬをブラウズし、そのうちの１つを選択する。エディタは、ここで、選択したＵＲＬのサフィックスを使用して、特定のページＩＤへの「ルータリンク」を作成する。
動的ルーティングおよびＳＥＯメタタグ
ルータは、ＵＲＬ解決エンドポイントの一部としてメタタグを提供する必要がある。主なものは、「タイトル」、「ノーインデックス」、「説明」、および「画像」を含む。アプリおよびそのルータにとって意味のある方法で、解決されたＵＲＬごとにそれらを提供することはルータに委ねられている。つまり、ビューア／エディタインフラストラクチャはメタタグに依存しない。各アプリはｉｆｒａｍｅを提供して、メタタグの動作を定義で
きる。このｉｆｒａｍｅは、動的ページのためのページ設定ダイアログの一部としてレンダリングされる。情報は、ルータの構成の一部として保持され、後で正しい応答を生成するために使用され得る。
ＨＴＴＰクッキーおよびヘッダ
クッキーは様々なエンドポイントに送信されない。ヘッダに関しては、サポートすることが重要なヘッダの最終リストはまだ未定である。
４０４ページおよび４０３ページ
これらのページはビューア／エディタインフラの一部として組み込みサポートを有する。ユーザはそのような特別なページを作成でき、それらが存在する場合は、インフラは適切なＨＴＴＰ応答コードが受信された場合にそれらにルーティングすることを認識する。
動的ルータを実装する際のクロスドメインの問題
未定
完全な例
未定
データバインディングルータ
ドキュメントのこのパートでは、新しいデータバインディングルータを概説し、このドキュメントの最初のパートで詳述した動的ルーティングインフラの上に構築する仕方について説明する。
データバインディングのコンセプトの簡単な要約
読者がデータバインディングモデルの基本を理解していることを前提としている。
その上で、データバインディングコンポーネントの簡単な概要は次のとおりである。
－コレクション：ｍｏｎｇｏ－ＤＢベースのレコードセット。
－スキーマ：コレクション内のデータのメタモデル。コレクションのスキーマはスキーマファイルに保存される（コレクションごとに１つ）。
－コンテンツマネージャ：ユーザがコレクションのコンテンツを管理できるスプレッドシートのようなアプリケーション。
－Ｗｉｘデータ：ｗｉｘコードの一部としてデータアクセスを提供するライブラリ。Ｗｉｘデータは、ユーザ提供フックの実行、パーミッションの実施、検証の実行などを担当するクライアントインターフェースおよびバックエンドレイヤを有する。
－データセット：ユーザがＷｉｘデータＡＰＩを介して提供されるデータにＵＩ要素をバインドできるようにするエディタ／ビューア要素。
－データバインディング：データセットを使用して視覚的コンポーネントをデータにバインドする機能。
－開発ＤＢ：エディタが動作するデータベースインスタンス。
－プロダクションＤＢ：ライブサイトが動作するデータベースインスタンス。
データバインディングルータ
本データバインディングシステムの提供を完了するために、動的ＵＲＬと動的ページのレンダリングに必要なデータとの間のギャップを埋めるルータを提供する。
基本的に、データバインディングルータは、到来するＵＲＬを解析し、ｗｉｘデータを使用してクエリに変換する役割を果たす。結果が取得されると、それらは特別なタイプのデータセットに送られ、そしてレンダリングされたページ上の要素にデータが提供される。
このシステムを構成する様々な要素を見ると、正しいクエリを作成すること、クライア
ントにデータを返すこと、および特別なデータセットを使用してデータをページ上のコンポーネントにバインドすることがある。
ＵＲＬをＷｉｘデータクエリに変換する
動物のレコードを有する動物のコレクションがあると仮定する。また、動物ページに／ａｎｉｍａｌｓ／｛｛ａｎｉｍａｌ＿ｎａｍｅ｝｝のルートを設定すると仮定する。ルータはどのようにして正しいｗｉｘデータクエリを生成するのであろうか。
ルータは次を実行する必要がある。
－クエリするコレクションを知る→ルートを定義するときにルータの構成の一部としてコレクション名を保持する。
－クエリするフィールド（複数可）を知る→ルータの構成でマッピングを維持する。この場合、｛｛ａｎｉｍａｉ＿ｎａｍｅ｝｝を「名前」フィールドにマッピングする。
－正しいクエリ構文を生成する→これはもう少し複雑である。ＵＲＬの値は常に小文字で、スペースは含まれない。しかしながら、コレクション内の値は通常、人間が読みやすい形式である。例えば、動物名はコレクションでは「Ｇｒｅｙ Ｗｏｌｆ」であるが、ＵＲＬでは「ｇｒｅｙ－ｗｏｌｆ」である。これを克服するために、ルータは「ｒｅｇｅｘ－ｑｕｅｒｙ」を生成する必要がある－「ｇｒｅｙ－ｗｏｌｆ」のすべての可能な順列のコレクションを検索する：｛「Ｇｒｅｙ Ｗｏｌｆ」、「Ｇｒｅｙ－Ｗｏｌｆ」、「ｇｒｅｙ ｗｏｌｆ」など｝
データをクライアントに返す
こちらはより単純である。ルータは、ｒｅｓｏｌｖｅ＿ｕｒｌ（）ＡＰＩごとにペイロードを提供し、そしてそれだけである。
データセットを用いて取得したデータをＵＩ要素にバインドする
クライアントサイドでデータを利用可能になっているため、ページ上のＵＩコンポーネントにプッシュするデータセットが必要である。このデータセットにはいくつかの特別な特性があるため、これをルータデータセットと呼んでいる。このデータセットは次の特別な動作を有する。
－実行時に、データペイロードを期待し、ｗｉｘデータクエリを単独で発行する代わりに、それで自身を初期化する。
－実行時に、さらにデータを取得する必要がある場合（例えば、グリッドがスクロールされる場合など）、このＵＲＬに対してルータによって定義されたフィルタにアクセスする必要がある。したがって、ルータによって作成されたクエリと同様の結果を返すｗｉｘデータクエリを生成する方法を知っている。
－編集時には、ユーザがＵＲＬ要素にバインドされている部分のフィルタをオーバーライドすることはできない。ユーザは、通常のデータセットと同様に、さらなるフィルタを追加したり、並べ替えおよびページサイズを指定したりできることに留意されたい。
－編集時に、ユーザがマスタページに移動することを許可しない（特定のページを暗示するＵＲＬにバインドされているため）。
－他のＵＸ関連の動作（例えば、削除される場合の特別な通知、または複製された場合の特別な動作）。
ＵＲＬパターンからリンクを作成する
次に、リンクの生成に注目する。各動物の一意のページへのリンクを有した状態で、グリッド状にすべての動物を表示する非常にシンプルなインデックスページが必要であると仮定する。グリッドで使用されるこれらのリンクをどのように生成するのであろうか。
基本的な考え方は、特定のコレクションのための動的ページに定義された、よく知られたＵＲＬパターン、またはルートを使用することである。これらのパターンがわかれば、それらからリンクを生成できる。
例えば、システムに３つの異なるＵＲＬパターンがあるとする。
－［ｍａｉｎ ｒｏｕｔｅ］＼ｚｏｏ￥ａｎｉｍａｌｓ→動物園内のすべての動物のコレクションページ
－［ｈａｂｉｔａｔ ｒｏｕｔｅ］＼ｚｏｏ＼ａｎｉｍａｌｓ／｛｛ｈａｂｉｔａｔ｝｝→｛｛ｈａｂｉｔａｔ｝｝に住む動物を示している
－［ａｎｉｍａｌ ｒｏｕｔｅ］／ｚｏｏ／ａｎｉｍａｉｓ／｛｛ａｎｉｍａｌ＿ｎａｍｅ｝｝→特定の動物のページ
これらのパターンを定義し、動物コレクションのレコードを与えると、これらのＵＲＬを３つすべて作成できる。これを機能させるには、システムのいくつかの新しいコンセプトを含む。
スキーマの拡張
スキーマの拡張は、アプリケーションによって提供されるコレクションのスキーマファイル内のセグメントである。この拡張は、通常、既存のスキーマファイルにスキーマ要素を追加する。
この場合、所与のコレクションに対して新しいルートが追加（または変更、または除去）されると、システムは関連するコレクションに対してデータバインディングアプリによって提供されるスキーマ拡張を修正する。ルートごとに、ルートのＵＲＬを生成する仕方をシステムに伝える一時的計算フィールド（以下を参照）を作成する。
一時的計算フィールド
これらのフィールドは、（ａ）計算された、（ｂ）一時的なものである。つまり、コレクション内の実際のレコードに保持されることはなく、むしろ、指定された計算ごとにデータ取得時に計算される。これらの計算はすべて、ｗｉｘデータバックエンドレイヤで行われる。
上記のルートの例では、次の３つのこのようなフィールドを作成する。
－Ｍａｉｎ＿ＵＲＬ：ｓｔｒｉｎｇ．Ｖａｌ＝“／ａｎｉｍａｌｓ／”
－Ｈａｂｉｔａｔ＿ＵＲＬ：ｓｔｒｉｎｇ．Ｖａｌ＝“／ａｎｉｍａｌｓ／”＋ｔｏ＿ｕｒｌ＿ｐａｒｔ（ｆｉｅｌｄ＿ｖａｌ［“ｈａｂｉｔａｔ”］）
－Ａｎｉｍａｌ＿ＵＲＬ：ｓｔｒｉｎｇ．Ｖａｌ＝“／ａｎｉｍａｌｓ／”＋ｔｏ＿ｕｒｌ＿ｐａｒｔ（ｆｉｅｌｄ＿ｖａｌ［“ｎａｍｅ”］）
上記の計算では、計算を実行するｗｉｘデータエンジンには不明であるため、ＵＲＬの＜ｓｉｔｅ＞パートを指定されていないことに留意されたい。計算を完了し、不足している＜ｓｉｔｅ＞部分を追加して完全なＵＲＬを作成するのはルータに委ねられている。
参照フィールド
将来のバージョンでは、あるコレクションから他のコレクションへの参照フィールドを追加する予定である。このようなフィールドが存在することにより、コレクションＡのアイテムからコレクションＢのアイテムにリンクするＵＲＬを作成できる、つまり、コレクションＡにコレクションＢへの参照フィールドがあり、そこにコレクションＢのアイテムのＩＤがある場合、コレクションＢで定義された一時的リンクフィールドに基づいて、そのＩＤを使用して正しいＵＲＬリンクを生成できる。
しかしながら、現在のバージョンにはない。
データバインディングルータに関する他の考慮事項
ページデータバインディングルータにおけるページロール
少なくともこのシステムのｖ１では、動的ページごとに複数のロールを使用したり、ユーザにページのカスタムロールを指定させたりする予定はないことに留意されたい。これは、ユーザが「フォールバックページ」またはページロールの一般的な機能ごとにより具体的なページを作成できないことを意味する。
ＳＥＯメタタグを指定する
ＳＥＯメタタグは、エディタが提供するページ設定ダイアログインフラにデータバインディングアプリが提供するｉｆｒａｍｅを介して管理される。そのｉｆｒａｍｅを介して、ユーザはデータバインディングルータが所有する動的ページごとにＳＥＯメタタグを生成する仕方を指定できる。
この構成は、ルータの構成の一部として保持され、ルータエンドポイントに渡されて、データベースから取得したデータに基づいて正しいメタタグを生成する。
例えば、ユーザは「動物」ページのタイトルに次の表現を指定できる：「動物園の大きな｛｛ｎａｍｅ｝｝に会いに来て！」。ルータは、データを取得するときに正しいタイトルを生成する。
サイトマップエンドポイント
サイトマップの実装は比較的単純である。
－コレクションごとに、そのすべてのアイテムを取得する。
－ＵＲＬルートごとにフィールドを計算しているため、必要な情報は既にある。
－後は、計算されたＵＲＬの個別のセットを取得し、呼び出し元に返すだけである。
データバインディングルータ上のフック
ルータが機能を実行する前後にユーザコードを実行できるようにする予定である。基本的なメカニズムは、現在のｗｉｘデータにあるバックエンドフックに似ている－ユーザは、ルータの実行前または実行後に呼び出される関数を登録できる。
実行前フックは、ルータ自体と同じ入力パラメータを取得し、実際のルータ実装に渡しても渡さなくてもよい。
実行後フックは、ルータの実行から出力パラメータを取得し、ＨＴＴＰ応答の一部として送り返される前にそれらを変更してもよい。
未解決の問題
－開発／プロダクションＤＢ
－ページレベルでのパーミッション
カスタムルータ
－カスタムルータを作成する
－カスタム動的ページを作成する
－エラーを含む、カスタムルータのためのＡＰＩ
－カスタムルータと共にページロールを使用する
－カスタムルータと共にデータバインディングを使用する
０９－ＤＹＰ
動的ページ
動的ページ
一般的な説明
動的ページを作成すると、繰り返し使用でき、毎回データベースコレクションからの異なるコンテンツを表示する１つのページレイアウトを設計します。
通常ページには繋がり得るＵＲＬが１つしかないが、それとは反対に、動的ページは異なるＵＲＬを有することができる。ページに表示されるコンテンツは、そのページへのアクセスに使用されたＵＲＬによって異なる。
動的ページは表示されるたびに異なるコンテンツを表示するため、通常のページとは異なります。通常のページはそのコンテンツをページ自体に保存しますが、動的ページのコンテンツはデータベースコレクションに保存されます。
例えば：
レシピサイトがあり、単一のレシピのためのデータを表示するページを設計することを考える。通常の静的ページでは、レシピごとに個別のページを作成する必要がある。動的ページを用いると、１つの動的ページのみを作成し、実行時に表示されるべき特定のレシピを判定し得るＵＲＬパターンを割り当てるだけでよい。
（Ｗｉｘデータコレクションに保存されている）レシピのそれぞれが「ｔｉｔｌｅ」という名前のフィールドを含む場合、動的ページのＵＲＬを「ｗｗｗ．．．．／ｒｅｃｉｐｅｓ／｛ｔｉｔｌｅ｝」となるように定義できる。
ユーザが「ｗｗｗ．．．／ｒｅｃｉｐｅｓ／ｐｉｚｚａ」をブラウズすると、ページは「ｐｉｚｚａ」などのタイトルのレシピのためのコンテンツを表示する。
主なコンポーネント／関連するＷｉｘコード要素
コンテンツマネージャ（およびＷｉｘデータデータベース）
ユーザがコレクションを作成してデータを管理するために使用する。
データバインディングエディタアプリケーション
ユーザが動的ページを作成および管理し、またページコンポーネントを関連するコンテンツパーツに接続できるようにするパネルにより、Ｗｉｘエディタを強化する。
データバインディングルータ
２種類の要求を受け入れるバックエンドアプリケーション：
１． ルーティング要求。データバインディングアプリケーションに属する動的ページをロードする場合に、ｗｉｘビューアは所与の入力されたＵＲＬに対して表示するページおよびコンテンツをルータに要求する。ルータは、所与のＵＲＬをサイト所有者によって定義されたパターンと照合することを試み、データベース内の関連コンテンツを探す。見つかった場合、ルータは関連するページの識別子およびコンテンツで応答する。
２． サイトマップ要求。ボットがＷｉｘサイトのサイトマップを要求し、サイトにデータバインディングアプリケーションに属する動的ページが含まれる場合、ルータは解決し得るすべての可能なＵＲＬのリストを返すように要求される。
データバインディングビューアアプリケーション
動的ページがロードされたときに実行される。ルータから返されたコンテンツを受信し、構成に従ってページ上のコンポーネントにバインドする。
技術的情報
コード全体はＪａｖａＳｃｒｉｐｔで記述される。
ｒｅａｃｔ、ｒｅｄｕｘ、ｌｏｄａｓｈ、ｃｏなど、コードと共に出荷される様々なオープンソースライブラリを使用している。
他のオープンソースライブラリは、コードの構築およびテストに使用されるが、同梱されていない：ｗｅｂｐａｃｋ、ｂａｂｅｌ、ｍｏｃｈａ、ｅｓｌｉｎｔなど。
サードパーティサービス
Ｓｅｎｔｒｙ
コードは、Ｓｅｎｔｒｙ（ｈｔｔｐｓ：／／ｓｅｎｔｒｙ．ｉｏ）と呼ばれるサードパーティのサービスを使用して、実行時（エディタ時間およびビューア時間の両方）に発生する問題のあるフローのログを取る。
エラーが発生するたびに、コードはエラーに関する情報と現在のコンテキストとをＳｅｎｔｒｙに送信する。この情報には次のようなものが含まれる。
－アプリケーションバージョン
－エディタ構成
－エラーの説明
－サイト／エディタＵＲＬ
－リファラＵＲＬ
－ユーザエージェント（ブラウザタイプ、バージョンなど）
－オペレーティングシステム
－ユーザのデータベースのコンテンツ
－ＩＤＥにおいてユーザにより記述されたコード
－エラーにつながったユーザアクション
１０－ＤＢＧ
データバインディング
データセットおよびデータバインディング
データバインディングシステムのコア要素はデータセットである。データセットはデータのクライアントサイドプロバイダであり、視覚的コンストラクト（すなわち、エディタコンポーネント）は双方向にバインドできる。データセットはまた、クライアントアプリケーションが、バックエンドロジックレイヤ、また最終的にはデータストア自体によりデータ取得およびデータ変換プロトコルを実装することにより、データを管理するチャネルでもある。
最も単純なタイプのデータセットは、コレクションデータセットである。このようなデータセットは、単純に、特定のコレクションからデータを取得し、基礎となるモデルのフィールドメタデータに基づいて並べ替えおよびフィルタリングを可能にし、そのコンシューマがレコードを反復処理し、場合により、新しいレコードを作成し、既存のレコードを更新できるようにする。データセットは、クエリベースのデータセットである。このようなデータセットは、単一のコレクションに対するクエリによって駆動される。
エディタ要素はデータセットにバインドされ得る。特に、エディタ要素のプロパティは、データセットのコレクションフィールド表現にバインドされる。複数の要素が同じデータセットにバインドされ得る。
実行時には、次の（簡略化された）シナリオが実行される。
－ページがロードされる
－ページコードが実行される。その一部として、１つまたは複数のデータセットが作成される（ページへのデータセットのアタッチの仕方については後述）。
－データセットは、ここで、ＵＩコンストラクトに自身を繋ぐ。これは次のように行われる。
－このデータセットにバインドされているページコンポーネントを見つける。
－それぞれについて、データセットとコンポーネントとの間のやり取りを促進するマッチングアダプタを作成する。
－アダプタは、そのコンポーネントからの変更イベントのリスナとして自身を登録するため、変更を中継してデータセットに返すことができる。
－ここで、データ取得機能を実行することによりデータセットにデータが入力される。
－初期データが利用可能になると、関連するアダプタを使用することにより、データが関連するデータバインドコントロールに設定される。
－ここで、データセットの状態は、多くのイベントのうちの１つに対する反応として変化する場合がある。
－「次のレコード」、「前のレコード」などの呼び出し
－「次のページ」、「前のページ」などの呼び出し
－ユーザ入力による現在のレコードへの変更
－他。
－データセットの状態に対するこのような変更のたびに、アダプタを介してすべてのバインドされたコンポーネントに対して更新コマンドを出す
－また、データセットは、要求されたときに変更をバックエンドストアに「コミット」
する場合がある。これは、「現在のレコード」ポインタが新しいレコードに移動したときに自動的に発生するか、「変更のコミット」ＡＰＩ呼び出しによって明示的に発生する。これについては後で詳述する。
Figure 2024075645000099
Figure 2024075645000100
データセットの状態
Figure 2024075645000101
１１－ＣＭＧＲ
コンテンツマネージャ
コンテンツマネージャ（ＣＭＧＲ）
ＣＭＧＲは、ユーザがＷｉｘデータコレクションに格納されているデータを操作できるようにするＥｘｃｅｌに似たデータ管理アプリケーションである。アプリケーションは、２つの主要な部分、すなわちＷｉｘサイトのそれぞれの部分に置かれるＣＭＧＲエディタアプリケーションおよびＣＭＧＲマイアカウントアプリケーションから構成される。
エディタにおけるコンテンツマネージャ（ＣＭＧＲエディタ）
ＣＭＧＲエディタはクライアントサイドウェブワーカーにより開かれる。これは、エディタＡＰＩとＣＭＧＲとの間のメディエータであるエディタＳＤＫを取得し、ＣＭＧＲがＷｉｘサイトの状態を操作できるようにする。ＣＭＧＲエディタは次を可能にする。
－サイトのテスト／サンドボックスデータの表示および編集（ＷｉｘデータＡＰＩを使用）
－コレクションのパーミッションを編集する（エディタＳＤＫを使用してクラウドＶＦＳのファイルを修正する）
－Ｗｉｘデータフックの表示および編集（編集はＳａｎｔａ Ｅｄｉｔｏｒの外部パネルで行われ、修正はクラウドＶＦＳに格納される）
－コレクションデータをサンドボックスからライブに、またはその逆に同期する（ＷｉｘデータＡＰＩを使用）
－ライブデータをプレビューする（ＷｉｘデータＡＰＩを使用）
－スキーマの管理：新しいスキーマの作成、フィールドの追加／編集／除去（エディタＳＤＫを使用してクラウドＶＦＳのファイルを修正する）
マイアカウントのコンテンツマネージャ（ＣＭＧＲマイアカウント）
ＣＭＧＲマイアカウントはＷｉｘダッシュボードによって開かれる。ＣＭＧＲマイアカウントは次を可能にする。
－サイトのライブデータの表示および編集（ＷｉｘデータＡＰＩを使用）
－スキーマに保持されないデータに一時的（未定義）フィールドを追加する
コンテンツマネージャグリッド
ＣＭＧＲエディタおよびＣＭＧＲマイアカウントの両方におけるプライマリコンポーネントである。コレクションのスキーマを使用して、グリッドの列を構築する。スキーマは、特定のＷｉｘサイトに関連付けられたＷｉｘコードファイルシステムに格納される。Ｗ
ｉｘデータからロードされたユーザデータを使用して、グリッドの行を構築する。これは次のことを可能にする。
－コレクションアイテム（行）の管理：追加、編集、除去、複製（ＷｉｘデータＡＰＩを使用）
－フィールドの可視性を切り替える
－データのフィルタ（ＷｉｘデータＡＰＩを使用）
－データの並べ替え（ＷｉｘデータＡＰＩを使用）
データ型
ＣＭＧＲは、文字列、数値、ブーリアン、日付、ページリンク、画像、ＪａｖａＳｃｒｉｐｔ配列およびオブジェクト、参照などの複数のデータ型を処理する。
文字列、数値、ブーリアン、日付、配列、およびオブジェクトはプリミティブ型である（ＪａｖａＳｃｒｉｐｔでネイティブにサポートされている）。
ページリンクは、コレクションに格納されない特別な文字列であり、動的ページのパターンを指定すると、実行時にｗｉｘデータによって構築される。ページリンクは、Ｗｉｘサイトにおいて動的ページにリンクするために使用され得る。
画像は、外部リソースへの文字列か、Ｗｉｘメディアサーバに格納されているファイルを参照する特別なＷｉｘメディア文字列である。ユーザは、Ｗｉｘメディアダイアログを介して画像をアップロードできる。
参照は、Ｗｉｘデータコレクション間の結合を有効にするために使用される他のコレクションへのポインタである。
実装
アプリケーションは、Ｒｅａｃｔというオープンソースフレームワークによってレンダリングされる。
ｈｔｔｐｓ：／／ｇｉｔｈｕｂ．ｃｏｍ／ｆａｃｅｂｏｏｋ／ｒｅａｃｔ
アプリケーションの状態は、ｒｅｄｕｘというオープンソースライブラリで処理される。ｈｔｔｐｓ：／／ｇｉｔｈｕｂ．ｃｏｍ／ｒｅａｃｔｉｓ／ｒｅｄｕｘ
グリッドは、次の３つのコンポーネントから構成されるａｇ－ｇｒｉｄというオープンソースライブラリによってレンダリングされる。
１．ａｇ－ｇｒｉｄ（ｈｔｔｐｓ：／／ｇｉｔｈｕｂ．ｃｏｍ／ｃｅｏｌｔｅｒ／ａｇ－ｇｒｉｄ）
２．ａｇ－ｇｒｉｄ－ｅｎｔｅｒｐｒｉｓｅ（ｈｔｔｐｓ：／／ｇｉｔｈｕｂ．ｃｏｍ／ｃｅｏｌｔｅｒ／ａｇ－ｇｒｉｄ－ｅｎｔｅｒｐｒｉｓｅ）
３．ａｇ－ｇｒｉｄ－ｒｅａｃｔ（ｈｔｔｐｓ：／／ｇｉｔｈｕｂ．ｃｏｍ／ｃｅｏｌｔｅｒ／ａｇ－ｇｒｉｄ－ｒｅａｃｔ）
１２－ＤＳＥＯ
動的ＳＥＯ
Ｗｉｘコード－ＳＥＯサブシステムの説明
Ｗｉｘサイトの「通常の」ＳＥＯレンダラは、サイトを表す静的ＪＳＯＮデータを取得し、それを使用して検索ボット向けにサイトの簡易バージョンをレンダリングする（クライアントサイドで実装される通常のレンダリングロジックを使用せずに）。
Ｗｉｘコードはユーザがサイトを動的に変更する機能を導入するため、これらの変更を含む方法でサイトをレンダリングできる異なる／追加のメカニズムが必要とされており、これは、動的ページルーティングおよび任意のユーザロジックを含み得る。
ＳＥＯサブシステムの主要なサブコンポーネント
・Ｗｉｘ ＳＥＯレンダラからＲＰＣ要求を受信し、処理のために利用可能なワーカーにディスパッチするディスパッチャサービス（「クラウドＳＥＯディスパッチャ」）
・レンダリング要求を処理する「クラウドＳＥＯワーカー」のグリッド。
各ワーカーは、（実行中のユーザコードなどを含む）実際の処理を行うクライアントコード（別名「Ｍｉｎｉ Ｓａｎｔａ」）の実行に使用されるヘッドレスＣｈｒｏｍｅブラウザを実行し、
サイトを表す静的データ構造に適用する一連の変更として結果を生成する。
・利用可能なワーカーを追跡し、構成の変更と同期させる管理サービス（「クラウドＳＥＯライフサイクル」）。
レンダリングフロー
通常のＳＥＯレンダラは、サイトがＷｉｘコード対応であることを認識すると、レンダリングに関連するデータを使用して「クラウドＳＥＯディスパッチャ」を呼び出し、次を応答として期待する。
・サイトのＪＳＯＮに適用する差分（ｍａｓｔｅｒＰａｇｅ＋現在のページ）
・動的ページルーティングの場合、レンダリングするページのｐａｇｅＩＤ＋レンダリングするＳＥＯメタデータ
「クラウドＳＥＯディスパッチャ」は、レンダリングタスクを利用可能な「クラウドＳＥＯワーカー」のうちの１つに渡す。
ワーカーは、管理されているヘッドレスＣｈｒｏｍｅインスタンスに、レンダリングするサイトのパラメータによりＭｉｎｉ Ｓａｎｔａのレンダリング関数を呼び出すことにより、サイトをレンダリングするように指示する。
レンダリング関数は、サイトをレンダリングするコードを実行するが、画面に結果を表示する代わりに、次を計算して出力する。
１． 静的サイトの初期データ構造とユーザコードの実行後のランタイムデータ構造との差分。
２． 動的ページ情報。レンダリングするページと、レンダリング結果に追加するＳＥＯメタデータ。
これらの結果の差分は、Ｗｉｘの「通常の」ＳＥＯレンダラまでの呼び出しのチェーンに戻り、これにより最初の静的データに適用され、検索エンジンクローラに送り返される最終ＨＴＭＬをレンダリングする。
１３Ａ－ＣＦＮ
計算関数
Ｗｉｘコード－計算関数
要約
Ｗｉｘサイトの場合、ユーザは、標準のＨＴＴＰプロトコルを介してサイトのウェブインターフェースとして公開される関数を記述する機能を有し得る。
この機能は、例えば、ウェブフックを介したサードパーティアプリケーションへの登録や、ウェブサイトのＲＥＳＴ ＡＰＩの公開など、サーバ間の組み込みに役立つ。
関数の追加
ＷｉｘコードＩＤＥを介して、ユーザは計算関数を追加する機能を有することができ、この機能は、コードを記述するための専用ページを開く。関数の名前は、ウェブサイトアドレスに関連するウェブパスプレフィックスを表し、これにより、ＨＴＴＰプロトコルを使用して関数を呼び出すことができる。
例えば、ｃｏｍｐｕｔｅという名前の関数は、ｈｔｔｐ［ｓ］：／／ｍｙｓｉｔｅ．ｃｏｍ／＿ａｐｉ／ｅｎｄｐｏｉｎｔｓ／ｃｏｍｐｕｔｅ／．．．というＵＲＬを介してアクセスできる。
ユーザはまた、場合により、関数を使用できるＨＴＴＰメソッド（ＧＥＴ／ＰＯＳＴ／ＰＵＴ／ＤＥＬＥＴＥ）を定義することもできる。コードは、ユーザのサイト専用スペースの下にあるＶＦＳと呼ばれるマルチテナントサービスに格納される。
ユーザは、ＵＲＬ、クエリパラメータ、ヘッダ、ペイロード、ＨＴＴＰメソッドなど、処理に使用できるＨＴＴＰ要求情報を取得する。
ユーザは、ステータスコード、ペイロード、ヘッダの部分でＨＴＴＰ応答を生成できる。
関数の実行
関数がＨＴＴＰアクセスに利用可能になり、Ｗｉｘコードウェブサーバ（ディスパッチャ）に対してＨＴＴＰ要求が呼び出された後、関数定義の存在をテストするために最初の検証が実行される。関数が存在しない場合、ステータス４０４（見つかりません）が返される。関数が存在する場合、コードは、そこで実行されている基本アプリケーションサーバ（ＥＬＭ）を介して、分離されたドッカーコンテナで実行される。
公開前のテストおよびデバッグ
計算関数の開発段階で、ＷｉｘコードＩＤＥを介して提供されるテストＨＴＴＰ ＵＲＬを介して関数をテストできる。既に公開されているか、現在開発中の関数実行のログを表示することもできる。
１３Ｂ－ＣＦＮ
計算関数－詳細
Ｗｉｘコード－計算関数
概要
このドキュメントでは、ＨＴＴＰを介してＡＰＩとしてウェブエンドポイントを公開するための機能要件および技術仕様の提案を概説する。
この文書は研究論文に基づいている。
機能要件
認証なしでのウェブアクセスのためのメソッドを公開する機能
・サポートされているＨＴＴＰメソッドを定義する機能：ＰＯＳＴ、ＧＥＴ、ＰＵＴ、ＤＥＬＥＴＥ（同じパス上）
・要求のＨＴＴＰメソッド、パス、ヘッダ、クエリパラメータ、およびボディを抽出（読み取り）する機能
・応答のＨＴＴＰステータスコード、ヘッダを書き込む機能
○要求のＨＴＴＰアクセプトヘッダを定義する機能があると好都合である
○応答のＨＴＴＰコンテンツタイプヘッダを定義する機能があると好都合である
・データへの不正アクセスは、データレイヤにより処理（実施）されるべきである
ウェブ ＡＰＩ ＨＴＴＰ仕様
メソッドがウェブアクセスのために公開されると、メソッドは次の仕様で公開される。
ＵＲＩ
無料サイト
公開サイト：ｈｔｔｐｓ：／／｛ｕｓｅｒ ｎａｍｅ｝ｗｉｘｓｉｔｅ．ｃｏｍ／＿ａｐｉ／ｅｎｄｐｏｉｎｔｓ／｛ｓｉｔｅ ｎａｍｅ｝／＊
開発：ｈｔｔｐｓ：／／｛ｕｓｅｒ ｎａｍｅ｝ｗｉｘｓｉｔｅ．ｃｏｍ／＿ａｐｉ－ｄｅｖ／ｅｎｄｐｏｉｎｔｓ／｛ｓｉｔｅ ｎａｍｅ｝／＊
プレミアムサイト
公開サイト：ｈｔｔｐｓ：／／｛ｕｓｅｒ ｄｏｍａｉｎ｝／＿ａｐｉ／ｅｎｄｐｏｉｎｔｓ／＊
開発：ｈｔｔｐｓ：／／｛ｕｓｅｒ ｄｏｍａｉｎ｝／＿ａｐｉ－ｄｅｖ／ｅｎｄｐｏｉｎｔｓ／＊
サイトルートへの／＿ａｐｉ／ｅｎｄｐｏｍｔｓ／（および／＿ａｐｉ－ｄｅｖ／ｅｎｄｐｏｉｎｔｓ／）という相対パスは、ユーザ定義ＡＰＩ全体へのルートエントリポイントになる。このエントリポイントをＡＰＩルートとして呼び出す。
ユーザの視点からは、このＵＲＬは永続的なものになる。ＵＲＬが変更されるユースケースは次のとおりである。
・無料サイトにおいて－ユーザがサイト名を変更
・プレミアムサイトにおいて－ユーザがドメインを変更
・ユーザがＡＰＩルートの後の内部サブパスを変更したとき。
・サイト移転－ドメイン名が変更され得る
・プレミアムへのアップグレード－ドメインの購入／既存のドメインの割り当て
全対全－ＡＰＩの後方互換性はもっぱらユーザの役割のようである。
安全性
ＵＲＬは、ユーザのサイトと同じドメインにある。これらのＵＲＬにブラウザを介してアクセスし、ユーザが意図しない安全でないコードを記述すると、潜在的なセキュリティリスクが発生する可能性がある。
以下を使用して、ＣＳＲＦおよびＸＳＳ攻撃に対処できる。
・ＣＳＲＦ－ブラウザユーザエージェントにクッキー／ヘッダ検証を使用する
・ＸＳＳ－オプトアウトまたはホワイトリストを定義するオプションを備えた状態で、デフォルトでユーザのドメインにコンテンツセキュリティポリシー機能を使用する
ＳＳＬを使用すると、セキュリティをさらに向上させることができる。
要求
・許可されるＨＴＴＰメソッド：エンドポイントの定義による
・関数のコードは、要求のボディ、ヘッダ、クエリパラメータ、ＩＰを抽出する役割を果たす。
応答
・応答のステータスコード：エンドポイントのコードの役割
・適切な形式で応答のボディを提供するのはエンドポイントのコードの役割である
・応答ヘッダも提供することができる
Ｗｉｘコード設計
はじめに
一般的な方向性は、パブリックサイトスクリプトで使用されるウェブモジュールを、ＨＴＴＰコンシューマ向けにウェブを介してパブリックに公開されるメソッドの定義と区別することである。後者を計算関数と呼ぶことにする。共有コードをパブリックスクリプトから使用する必要がある場合、より簡素な設計および実装が可能になると同時に、その結果のデフォルトの形式は、そのままウェブ計算関数の公開に使用することはできず、なんらかの操作が必要となる。
また、サイトのプレゼンテーションレイヤ（パブリックスクリプト）とはまったく関係のないウェブ計算関数を定義することもできる。
例えば、ｇｉｔｈｕｂウェブフックをリッスンするウェブ計算関数は、データを解析し、データベースコレクションに情報を保存し、同じコレクションからのデータを提示する動的ページがある。ここにはパブリックサイトのスクリプトは含まれていない。
場所
計算関数のコードを専用のＪＳファイルに格納する。ユーザは計算関数を定義できる－そしてＵＩはすべての計算関数のコードが置かれるファイルを開く。
そのファイルのコードが大きくなる可能性がある場合は、この態様を再検討する必要が
あり得る。
計算関数を定義する方法
計算関数には２つの態様がある。
１．設計時の態様－ユーザが計算関数を定義し、ＨＴＴＰメソッド、受け入れる要求コンテンツタイプ、生成する応答コンテンツタイプなど、様々な態様を構成する方法。
２．実行時の態様－このような計算関数が定義されたならば－適切なＨＴＴＰエンドポイントが公開されるべきであり、計算関数のコードの実行にリダイレクトするために呼び出されたとき、および既存の計算関数が削除されたときに、既存のＨＴＴＰエンドポイントを除去するべきである。当然のことながら、これは、サイトの公開後、またはユーザによる計算関数のテスト目的で公開する前にのみ利用可能にするべきである。
設計時の態様
・計算関数のプレフィックスごとにエクスポートされた関数を定義する
・関数には次のプレフィックスがある：ｇｅｔ＿、ｐｏｓｔ＿、ｐｕｔ＿、ｄｅｌｅｔｅ＿、ｕｓｅ＿
・プレフィックスの後の関数名は、ウェブエンドポイントのパスプレフィックスを表す
・すべきこと：新しい計算関数を定義する方法のＵＩの態様をまとめる必要が依然としてある
Figure 2024075645000102
／／ＵＲＬのためのすべてのＧＥＴ要求
／／ｈｔｔｐ［ｓ］：／／｛ｕｓｅｒ＿ｄｏｍａｉｎ｝／＿ａｐｉ／ｅｎｄｐｏｉｎｔｓ／ｅｘａｍｐｌｅ／＊はここにルーティングされる
／／ＵＲＬのためのすべてのＰＯＳＴ要求
／／ｈｔｔｐ［ｓ］：／／｛ｕｓｅｒ＿ｄｏｍａｉｎ｝／＿ａｐｉ／ｅｎｄｐｏｉｎｔｓ／ｋｕｋｕ／＊はここにルーティングされる
／／ＵＲＬのためにどのＨＴＴＰメソッドが呼び出されたかに関係なくすべてのＨＴＴＰ要求
／／ｈｔｔｐ［ｓ］：／／｛ｕｓｅｒ＿ｄｏｍａｉｎ｝／＿ａｐｉ／ｅｎｄｐｏｉｎｔ
ｓ／ｊｏｊｏ／＊はここにルーティングされる
他の却下された代替策については、付属書類Ａを参照されたい。
良い点：
・シンプルな定義、ＵＩにより容易に支援可能
・構成はコードに近い
・反映の必要がない
・現在パブリックに利用可能なＪＳの仕様を使用する
悪い点：
・ＨＴＴＰ呼び出しへの関数の動的バインディング－事前定義された構成が存在しない
・あいまいな定義が発生し得る－例えば、同じエンドポイントでｇｅｔ＿とｕｓｅ＿
○文書化する必要がある単純な優先順位アルゴリズムによって解決できる。特定のメソッドはｕｓｅ＿＊よりも優先される
・一部の文字はプレフィックスの一部にすることができない（例えば、「－」という文字）
○ＪＳ関数名に配置することがサポートされていないすべての文字
再検討：ｗｉｘインフラストラクチャのリダイレクトレベルによっては、途中でいくつかの内部ヘッダが追加される場合がある。これは、要求ヘッダの提供を回避することで解決できる。一方、機密ヘッダがサービスに転送されるような場合は、おそらく通信プロトコルのセキュリティ問題であり、なんとしても回避する必要があり、関連するプロトコルを再設計することで解決できる。
ユーザランタイムは今日も安全ではない環境と見なされているため、ユーザコンテナに機密情報を保持したり、渡したりすることはない。ユーザがアクセスできないようにしたいものがあれば、ディスパッチ中にそれを削除できる。
要求および応答のデータ構造
ルータ機能に関して、要求オブジェクトおよび応答オブジェクトのデータ構造を統一するよう努めている。
Figure 2024075645000103
／／プレミアムＷｉｘサイトのドメインまたは無料ＷｉｘサイトのＵＲＬ
／／パートで分解されたＡＰＩルートへの相対パス
／／関数がアクセスされたＵＲＬ全体
／／元のクライアントＩＰ
／／このオブジェクトはクエリパラメータ名のキー／値およびそのそれぞれ値を有する
／／このオブジェクトはヘッダのキー／値およびそのそれぞれ値を有する
／／要求のボディ
／／”ＧＥＴ”、”ＰＯＳＴ”、．．．
／／応答のステータスコードを表す整数の数値
／／ルータの応答関数、例えばｏｋ（）、ｆｏｒｂｉｄｄｅｎ（）、ｎｏｔＦｏｕｎｄ（）などをここで再利用する場合がある
／／応答のボディ
／／このオブジェクトはヘッダのキー／値およびそのそれぞれ値を有する
応答のためのファクトリ
／／応答ファクトリからｒｅａｄｙ応答がある
／／ｗｉｘ－ｃｏｍｐｕｔｅ－ｆｕｎｃｔｉｏｎｓ．ｊｓを含む。これは以下の関数を公開する。
／／一般的な応答
／／２００ ＯＫ応答
／／２０１ Ｃｒｅａｔｅｄ応答
／／４０４ Ｎｏｔ Ｆｏｕｎｄ応答
／／５００ Ｉｎｔｅｒｎａｌ Ｓｅｒｖｅｒ Ｅｒｒｏｒ応答
／／４００ Ｂａｄ Ｒｅｑｕｅｓｔ応答
／／４０３ Ｆｏｒｂｉｄｄｅｎ応答
実行時の態様－実行のためのマッピング
注意－各サイトにｃｏｍｐｕｔｅ－ｆｕｎｃｔｉｏｎｓ．ｊｓというファイルがあり、エンドポイントのＵＲＬから関数へのマッピングは、関数のコード自体と共に配置されている。
サイトをＷｉｘコード計算関数にマッピングする
・ＵＩを介して計算関数を作成すると、／ｃｏｍｐｕｔｅ－ｆｕｎｃｔｉｏｎｓ．ｊｓというパスのエレメンタリに、関連するサイトコンテキストの下のファイルが作成される
Figure 2024075645000104
ドメインからサイトｌＤを取得する簡単な方法はないようである。どのｇｒｉｄＡｐｐＩｄを起動するべきかを理解するために、３つのＲＰＣ呼び出しがある。
しかしながら、ｍｅｔａＳｉｔｅＩｄ／ｓｉｔｅＩｄ／ｄｏｍａｉｎが変更された場合、これら３つのＲＰＣ呼び出しをキャッシュすることを勧める。キャッシュを更新する、または定期的なポーリングによってキャッシュを更新するイベントが必要であり、これは結果整合性を示す（イベントが万全であることに頼ることはできないため、キャッシュ更新の代替策において）。出願人らの理解では、ｍｅｔａＳｉｔｅＩｄの変更またはドメインの変更のイベントはない。
ドメイン→ｇｒｉｄＡｐｐＩｄをキャッシュすることが提案されている。ｇｒｉｄＡｐｐＩｄは保存後に変更される可能性があるため、保存するたびにキャッシュを無効にする。このイベントは既にｗｉｘコードで扱われている。パブリッシュイベントをリッスンしていた場合、それが存在する方が良い。
ドメイン名／無料サイト名に変更がある場合－新しいドメインはキャッシュにないため、まずこの新しいドメインのフロー全体を再度実行してキャッシュする。
キャッシュは、最終接触時間に基づいたエビクションポリシーを有するべきである。
実行時の態様－プレビュー対公開
ユーザが計算関数を開発するとき－公開する前にウェブエンドポイントに「開発モード」を提供するべきではないだろうか。
新しい関数の場合－関数のコードがデータを操作する場合に役立つ。ユーザは、新しいコードが既存のデータを破損しないことを確認したいため、公開前にコードをテストすることを望む。加えて、計算関数が既に公開されており、例えば新しいプロトコルをサポートするために、ユーザが更新する必要がある場合、新しい関数のコードが期待どおりに実行しているようになると確信できるまで、関数の既存の機能を壊したくない。
この機能をどのように提供するべきであろうか。つまり、現在公開されているウェブエンドポイントと並行して動作する更新された関数をウェブに公開するという機能をどのように提供するべきであろうか。
アルゴリズム
・エディタクライアントがロードされると、そのＳＣＡＲＩがＡＰＩディスパッチャサービスに送信される（ＩＤＥサーバ経由）
・ＡＰＩディスパッチャサービスには、テスト用のドメイン→ｇｒｉｄＡｐｐＩｄのマッピングがある
○エディタセグメント（テスト）とパブリックセグメント（公開サイトＡＰＩアクセス）とを分離してみる。
○このｇｒｉｄＡｐｐＩｄは、エディタで現在開発されているバージョンを表し、公開後に変更が発生していない場合は、公開されたバージョンでも、新しく開発されたバージョン（保存されていないバージョン）でもよい。
・ｃｌｏｎｅＣｏｄｅＡｐｐ／ｄｕｐｌｉｃａｔｅＣｏｄｅＡｐｐ／ｃｒｅａｔｅＡｐｐのｗｉｘコードサービスの呼び出しがあるたびに、新しく生成されたｇｒｉｄＡｐｐＩｄは、ＡＰＩディスパッチャサービスに伝播される
・現在開発されているバージョンへのアクセスは、ＵＲＩセクションに記載されている開発ＵＲＩを介して行われる。
Figure 2024075645000105
そして、ａｐｉ－ｄｅｖの要求がＡＰＩディスパッチャにより受信されると、ドメインごとにｇｒｉｄＡｐｐＩｄのキャッシュを取得する。存在しない場合、公開されたサイトと同様のプロトコルにフォールバックし、最後に保存されたバージョンのｇｒｉｄＡｐｐＩｄをキャッシュする。
注意：エディタを開いているときにドメインが変更されると、問題が発生する可能性がある。そのようなイベントが存在する場合はリッスンし、それに応じてキャッシュを更新するか、制限を宣言する必要がある。
別の可能な代替策としては、エディタのロード時に、クライアントによって送信されたｗｉｘコードｉｎｓｔａｎｃｅＩｄ→ｇｒｉｄＡｐｐＩｄをキャッシュし（ドメインの解決なし）、実際のａｐｉ－ｄｅｖ要求で、上図のように同様のフローでドメインを解決し、およびドメイン→ｇｒｉｄＡｐｐＩｄもキャッシュする。
次に、ｃｌｏｎｅＣｏｄｅＡｐｐ／ｄｕｐｌｉｃａｔｅＣｏｄｅＡｐｐが発生すると、
前のｇｒｉｄＡｐｐＩｄで両方のキャッシュを更新する（ｇｒｉｄＡｐｐＩｄによる逆インデックスもある）。
これにより、「ドメインの変更」問題も解決される。
これはいくらか複雑なメカニズムのようである。制限を設けて、テストの前に保存するように要求してはどうだろうか。または、ＡＰＩをテストするための他の「オンデマンド」イベント、例えばＡＰＩをテストするなど？
デバッギング
ウェブフックでのハッカソンの苦痛の１つは、バックエンドコードにデバッグ機能がないことであった。機能を追加する必要があり、これは製品の未解決の問題である。
好ましい解決策
ユーザは、こちらに似たｃｏｎｓｏｌｅ．ｌｏｇ出力の連続的なストリームのためのウェブエンドポイントを有する。
［ｈｔｔｐｓ：／／ｗｅｂｔａｓｋ．ｉｏ／ｄｏｃｓ／ａｐｉ＿ｌｏｇｓ］
このことは慎重に検討する必要があるが、これは大量にリソースを消費するものになり得る。
他の代替策
・ロギングＡＰＩを提供し、サイトごとにローリングログファイルを用意し、これはユーザがエディタを介してダウンロードできる。
・特別なＵＩを開発モードで開くと、それらのログを印刷される
○実際には、これは上記の好ましい解決策に追加され得る
・開発者はヘッダ、例えばｘ－ｄｅｂｕｇを提供でき、それに応じて要求に関するデバッグ情報を保持する一意のＵＲＬを含む応答ヘッダを受け取る。サイトごとに最大５０個のＵＲＬである。情報は５分間メモリに保持される
○マシンごとに２００のエレメントリがあることを考えると、これがエレメントリのインメモリに保持されている場合、メモリに関して問題はないはずである。
付属書類
却下された設計時の態様の代替策
代替策１：ほぼｊａｘ－ｒｓ ＡＰＩからのコピー／ペースト
＠ｄｅｃｏｒａｔｏｒｓを使用できればいいのであるが、利用できるのは、次のｊａｖａｓｃｒｉｐｔの仕様であるＥＳ８のようである。
Ｂａｂｅｌトランスパイラは、いくつかの実験モードでサポートしている。
その後、反映を使用して、これらすべての計算関数メソッドを検索し、これらを構成に応じてマッピングできる。
Figure 2024075645000106
 ／／＠ｐｏｓｔであってもよい
／／ウェブエンドポイントはＧＥＴ ＨＴＴＰメソッドのために公開される
／／それは例えば以下のＵＲＬにおいてである。
／／ｈｔｔｐｓ：／／ｍｙｄｏｍａｉｎ．ｃｏｍ／＿ａｐｉ／ｅｎｄｐｏｉｎｔｓ／ｅｘａｍｐｌｅ／ｐａｔｈ
／／要求のためにアプリケーション／ＪＳＯＮコンテンツタイプを期待する
／／期待される応答のコンテンツタイプを定義する
良い点：
・明確で簡単な宣言
悪い点：
・要求のアクセプトおよび応答のコンテンツタイプヘッダのこのようなマッピングは、例えばワイルドカードが使用されている場合、ディスパッチャにとって難しいようである。放棄するべきかもしれない
・ファイナライズされていない仕様の使用（現在ステージ２－ｈｔｔｐｓ：／／ｇｉｔｈｕｂ．ｃｏｍ／ｔｃ３９／ｐｒｏｐｏｓａｌ－ｄｅｃｏｒａｔｏｒｓ）
・関連するマッピングを見つけるために反映を必要とする
代替策２：計算関数の構成がコードと別個に格納される
マッピングがユーザによって宣言される特別なメソッドを、事前定義された名前で提供できる。
Figure 2024075645000107
／／ｃｏｎｆｉｇは以下のメソッドを有する
／／ｃｏｎｆｉｇ．ｒｅｇｉｓｔｅｒ（ｍｅｔｈｏｄ，ｐａｔｈ，ｆｕｎｃｔｉｏｎＮａｍｅ）
／／実行するためにＨＴＴＰメソッド、パス、関数をマップする
／／関数は以下のシグネチャのものであることが期待される
／／ｆｕｎｃｔｉｏｎ ｓｏｍｅＦｕｎｃｔｉｏｎ（ｒｅｑｕｅｓｔ，ｒｅｓｐｏｎｓ
ｅ）
／／正確なパスマッピング
／／ワイルドカードパスマッピング。すべての／ｋｕｋｕのサブパスがこの関数にマップされる
良い点：
・非常に簡単な宣言
・反映の必要がない
・現在パブリックに利用可能なＪＳの仕様を使用する
悪い点：
・関数名が文字列として宣言され、タイプミスが発生し得る
・構成はメソッド自体にはほど「遠い」
代替策３：Ｅｘｐｒｅｓｓに似た構成
例えばＷｉｘＣｏｍｐｕｔｅＦｕｎｃｔｉｏｎｓなどの計算関数のレジストラとして機能するグローバルオブジェクトがいくつかある。
Figure 2024075645000108
／／正確なパスマッピング
／／パスおよびすべてのその子孫
良い点：
・簡単な定義、Ｅｘｐｒｅｓｓに似たＡＰＩ
・構成はコードに近い
・反映の必要がない
・現在パブリックに利用可能なＪＳの仕様を使用する
悪い点：
・グローバルオブジェクトを公開する
・あいまいな定義が発生し得る－なんらかの優先順位アルゴリズムが必要
代替策３．１：Ｅｘｐｒｅｓｓに似た構文を有する構成関数
実行するためのＨＴＴＰメソッド、パス、および関数を構成するためのＥｘｐｒｅｓｓに似たパターン。
Figure 2024075645000109
／／ｃｏｎｆｉｇは以下のメソッドを有する：ｇｅｔ，ｐｏｓｔ，ｕｓｅ
／／ｃｏｎｆｉｇ．ｇｅｔ（ｐａｔｈ，ｆｕｎｃｔｉｏｎ）
／／実行するためにＨＴＴＰメソッド、パス、関数をマップする
／／ｕｓｅ使用時は任意のＨＴＴＰメソッドが関数を呼び出す
／／正確なパスマッピング
／／ワイルドカードパスマッピング。すべての／ｋｕｋｕのサブパスがこの関数にマップされる
良い点：
・簡単な定義、Ｅｘｐｒｅｓｓに似たＡＰＩ
・構成はコードに近い
・反映の必要がない
・現在パブリックに利用可能なＪＳの仕様を使用する
悪い点：
・あいまいな定義が発生し得る－なんらかの優先順位アルゴリズムが必要
１４－ＷＤＢ
Ｗｉｘ ＤＢ
概要
ドックストアは、データを管理するためのＲＥＳＴｆｕｌ ＡＰＩを公開する一般的なマルチテナントドキュメントスタイルのデータサービスである。すべてのテナントは、いくつかの個別の仮想データベースを持つことができる。サービスはまた、テナントのデータベースを管理したり、場合によりテナントを無効にしたりするための、管理サーバ間（ユーザ向けではない）ＡＰＩを有する。
ストレージモデル
データの格納に使用される基礎となるデータベースはＭｏｎｇｏＤＢであり、サービスはシャーディング目的で複数の物理ＭｏｎｇｏＤＢデータベースをサポートする。
仮想／物理データベースマッピング
最初の要求時および認証チェックを通過した後、各テナント仮想データベースはサービスが動作している物理ＭｏｎｇｏＤＢデータベースのうちの１つに割り当てられ、その時
点から、そのテナントのデータベースのすべての到来する要求はその物理データベースに対して実行される。
仮想テナントデータベースから物理データベースへのマッピングは管理データベースで維持され、ホットマッピングレコードはＬＲＵベースのインメモリキャッシュに保持される。
仮想データベースモデル
各テナント仮想データベースには、１つまたは複数のドキュメントのコレクションを含めることができる。各仮想コレクションは、１つの物理ＭｏｎｇｏＤＢコレクションにマップされる。コレクションのマッピングは、シンプルなネームスペーシングシステムを使用して行われる。各物理コレクションには、＜ｔｅｎａｎｔＩｄ＞＠＜ｖｄｂ－ｎａｍｅ＞＠＜ｃｏｌｌｅｃｔｉｏｎ－ｎａｍｅ＞という名前が付けられる。したがって、要求が到来すると、認証チェックを通過した後、テナントＩＤ、ターゲットデータベース、およびコレクション名が解決され、物理コレクション名が構築されてアクセスできるようになる。
物理データベース割り当て
新しいテナントデータベースを導入する場合、永続的なターゲット物理データベースを割り当てる必要がある。物理データベースの選択は、現在のデータベースサイズに基づいて行われる。バックグラウンドタスクは、定期的に実行され、サービスが動作するように構成されているすべてのアクティブなデータベースから統計を収集するようにスケジュールされている。統計値はインメモリデータ構造に格納されるため、新しいデータベースを割り当てるときに、最小のデータベースをターゲットとしてすぐに選択できる。
１５－＄ＷＡＰＩ
＄Ｗ ＡＰＩ
＄Ｗ ＡＰＩ
＄Ｗ ＡＰＩは、ユーザがコードを使用してビューアコンポーネントと対話できるようにする方法である。ＳＤＫは、ユーザコード／拡張機能が実行されているワーカーとランタイム（別名ビューア）との間で使用される内部通信レイヤをラップするために使用される。以下は、論理アーキテクチャを表す図である。
Figure 2024075645000110
 必要性：
ＲＭＩの内部モデルは、システムの一部のみを制御および修正したいユーザにとっては複雑すぎ、ドキュメント化されておらず、実行に必要なプロプライエタリ情報が含まれている。＄Ｗ ＳＤＫはこれをラップし、要素を見つけて操作するより一般的なパターンにラップしたものを変換する。
コーディングパターン：
＄ｗ ＳＤＫでサポートされるコーディングパターンには、次の２つのパートが含まれる。
１．ページライフサイクルイベント：ライフサイクルメソッドを使用すると、ＳＤＫを使用したコードが、事前定義された段階においてトリガされる。これらの段階では、ＳＤＫが利用可能であり、コードは外部データのロード、コンポーネントの初期化、イベント登録などの様々なタスクを実行できる。現在、単一のメソッドが利用可能であり、これは、ページが提示される前に発生し、ＰａｇｅＬｏａｄと呼ばれる。ｊａｖａｓｃｒｉｐｔにｐｒｏｍｉｓｅを返すことにより、コードはすべての非同期情報（ｗｉｘデータまたは外部サービスからの外部データなど）がロードされるまでページの提示を延期できる。
２．選択：＄ｗはページのグローバルコンテキストを表す。同様のコンテキストオブジェクト、すなわちリピータアイテムを描画するときの＄ｉｔｅｍが存在し得る。コンテキストを使用して、ユーザは、文字列クエリを使用して要素を選択する。セレクタは通常のＣＳＳセレクタに似ているが、わずかな違いがある。選択すると、単一の要素または複数の要素が返され得る。例えば：
＄ｗ（’＃ｍｙＥｌｅｍｅｎｔ’）－これはｍｙＥｌｅｍｅｎｔ ＩＤを持つ要素を選択する
セレクタには次のタイプがある。
○ＩＤセレクタ。ページの一意のＩＤを使用して選択する。
○タイプセレクタ。コンポーネントのタイプを使用して選択する。
○タイプのアレイセレクタ
○ロールセレクタ。これは、独自の事前定義された名前を使うことを選択するためにコントローラによって使用される。要素は、コントローラによって与えられてＩＤおよび複数のロールを有することができる。
３．要素の操作：要素への参照が取得されると、要素はそれを操作するメソッドを提供する。要素の非表示や表示など、一部のメソッドはすべての要素で利用可能である。一部のメソッドは、特定の要素でのみ利用可能である。完全なリストはＳＤＫ ｄｏｃｕｍｅｎｔａｔｉｏｎで提供されている。
４．イベント登録：各要素は、事前定義されたイベントのセットをサポートする。ＳＤＫを使用しているコードは、これらのイベントに登録し、発生時に呼び出されるコールバックメソッドを提供できる。コールバック中に、選択および操作が可能である。

Claims (29)

  1. ウェブサイトの複数のウェブページに投入されるデータセットを含むバックエンドデータベースを更新するための非一時的コンピュータ可読媒体であって、前記コンピュータ可読媒体が、少なくとも１つのプロセッサにより実行された場合に、
    ユーザインターフェースを介して複数のデータ要素を受信するステップであって、前記データ要素が少なくとも１つのデータ要素の１つまたは複数のグループに編成され、各グループがウェブサイトの個別のウェブページに表示するためのものである、ステップと、
    前記少なくとも１つのデータ要素のグループをデータベースに格納するステップと、
    複数の仮想ウェブページを生成するステップであって、各仮想ウェブページが、対応する実際のウェブページが稼働する前における前記対応する実際のウェブページのプレビューであり、前記対応する実際のウェブページのそれぞれが前記データベースを更新するための機能を備えて設計されていない、ステップと、
    前記複数の仮想ウェブページのうちの個別のページに少なくとも１つのデータ要素の各グループを表示するステップと、
    ユーザが前記複数の仮想ウェブページからの仮想ウェブページを編集できるように編集ツールを表示するステップと、
    前記仮想ウェブページの前記編集を前記データベースのための更新に変換するステップと、
    前記データベースに前記更新を格納するステップと、
    前記仮想ウェブページに関連付けられた対応する実際のウェブページのライブビュー中に、前記プレビュー中に前記仮想ウェブページに対して前記更新を行った状態で前記対応する実際のウェブページを表示できるようにするステップと、
    を前記少なくとも１つのプロセッサに実行させる命令を含む、非一時的コンピュータ可読媒体。
  2. 前記複数の仮想ウェブページのそれぞれが、前記ユーザインターフェースのエディタインターフェースに関連付けられたフレーム内に表示可能である、請求項１に記載の非一時的コンピュータ可読媒体。
  3. 前記ステップが、前記複数の仮想ウェブページのそれぞれを個別かつ動的に表示するために、前記ユーザが前記複数の仮想ウェブページにわたってナビゲートできるようにするユーザ選択可能機能を表示するステップをさらに含む、請求項１に記載の非一時的コンピュータ可読媒体。
  4. 前記ステップが、前記ユーザが前記複数の仮想ウェブページからの特定の仮想ウェブページを前記特定の仮想ウェブページの識別子に基づいて選択できるようにするユーザ選択可能機能を表示するステップをさらに含む、請求項１に記載の非一時的コンピュータ可読媒体。
  5. 前記特定の仮想ウェブページの前記識別子が、前記特定の仮想ウェブページに関連付けられたデータ要素に基づく、請求項４に記載の非一時的コンピュータ可読媒体。
  6. 前記ステップが、前記複数の仮想ウェブページのそれぞれに一意のＵＲＬを関連付けるステップをさらに含む、請求項１に記載の非一時的コンピュータ可読媒体。
  7. 前記複数の仮想ウェブページのそれぞれが、前記複数の仮想ウェブページのそれぞれの前記一意のＵＲＬを参照するサイトマップに基づいて生成される、請求項６に記載の非一時的コンピュータ可読媒体。
  8. 前記編集ツールが、前記データベースに前記格納された少なくとも１つのデータ要素のグループに対する編集を受信するように構成される、請求項１に記載の非一時的コンピュータ可読媒体。
  9. 前記編集ツールが、前記複数の仮想ウェブページの属性に対する編集を受信するように構成される、請求項１に記載の非一時的コンピュータ可読媒体。
  10. 前記編集ツールが、前記複数の仮想ウェブページを生成するために使用されるコードに対する編集を受信するように構成される、請求項１に記載の非一時的コンピュータ可読媒体。
  11. 前記編集ツールが、前記複数の仮想ウェブページを生成するために使用される実際のコードを表すスケルトンコードの複数のセグメントを表示するように、また前記実際のコードに対する編集に変換される前記スケルトンコードに対する編集を受信するように構成される、請求項１に記載の非一時的コンピュータ可読媒体。
  12. 前記データ要素が、外部ソースから前記ユーザインターフェースを介して受信される、請求項１に記載の非一時的コンピュータ可読媒体。
  13. 動作が、
    前記複数の仮想ウェブページに関連付けられたソフトウェアベースのルータにアクセスすることと、
    受信したＵＲＬの１つまたは複数のセグメントに基づいて前記複数の仮想ウェブページのそれぞれの異なるバージョンを生成するように前記ソフトウェアベースのルータを構成することと、
    をさらに含む、請求項１に記載の非一時的コンピュータ可読媒体。
  14. 少なくとも１つのデータ要素の各グループのサブセットがリピータ機能により編成され、前記リピータ機能が少なくとも１つのデータ要素の各グループの前記サブセットの１つまたは複数の表示されたインスタンスを生成する、請求項１に記載の非一時的コンピュータ可読媒体。
  15. 前記対応する実際のウェブページの前記ライブビューが前記１つまたは複数のインスタンスを含む、請求項１４に記載の非一時的コンピュータ可読媒体。
  16. ウェブサイトの複数のウェブページに投入されるデータセットを含むバックエンドデータベースを更新するためのコンピュータ実施方法であって、前記方法が、
    ユーザインターフェースを介して複数のデータ要素を受信するステップであって、前記データ要素が少なくとも１つのデータ要素の１つまたは複数のグループに編成され、各グループがウェブサイトの個別のウェブページに表示するためのものである、ステップと、
    前記少なくとも１つのデータ要素のグループをデータベースに格納するステップと、
    複数の仮想ウェブページを生成するステップであって、各仮想ウェブページが、対応する実際のウェブページが稼働する前における前記対応する実際のウェブページのプレビューであり、前記対応する実際のウェブページのそれぞれが前記データベースを更新するための機能を備えて設計されていない、ステップと、
    前記複数の仮想ウェブページのうちの個別のページに少なくとも１つのデータ要素の各グループを表示するステップと、
    ユーザが前記複数の仮想ウェブページからの仮想ウェブページを編集できるように編集ツールを表示するステップと、
    前記仮想ウェブページの前記編集を前記データベースのための更新に変換するステップ
    と、
    前記データベースに前記更新を格納するステップと、
    前記仮想ウェブページに関連付けられた対応する実際のウェブページのライブビュー中に、前記プレビュー中に前記仮想ウェブページに対して前記更新を行った状態で前記対応する実際のウェブページを表示できるようにするステップと、
    を含む、コンピュータ実施方法。
  17. 前記複数の仮想ウェブページのそれぞれが、前記ユーザインターフェースのエディタインターフェースに関連付けられたフレーム内に表示可能である、請求項１６に記載のコンピュータ実施方法。
  18. 前記複数の仮想ウェブページのそれぞれを個別かつ動的に表示するために、前記ユーザが前記複数の仮想ウェブページにわたってナビゲートできるようにするユーザ選択可能機能を表示するステップをさらに含む、請求項１６に記載のコンピュータ実施方法。
  19. 前記ユーザが前記複数の仮想ウェブページからの特定の仮想ウェブページを前記特定の仮想ウェブページの識別子に基づいて選択できるようにするユーザ選択可能機能を表示するステップをさらに含む、請求項１６に記載のコンピュータ実施方法。
  20. 前記特定の仮想ウェブページの前記識別子が、前記特定の仮想ウェブページに関連付けられたデータ要素に基づく、請求項１６に記載のコンピュータ実施方法。
  21. 前記複数の仮想ウェブページのそれぞれに一意のＵＲＬを関連付けるステップをさらに含む、請求項１６に記載のコンピュータ実施方法。
  22. 前記複数の仮想ウェブページのそれぞれが、前記複数の仮想ウェブページのそれぞれの前記一意のＵＲＬを参照するサイトマップに基づいて生成される、請求項２１に記載のコンピュータ実施方法。
  23. 前記編集ツールが、前記データベースに前記格納された少なくとも１つのデータ要素のグループに対する編集を受信するように構成される、請求項１６に記載のコンピュータ実施方法。
  24. 前記編集ツールが、前記複数の仮想ウェブページの属性に対する編集を受信するように構成される、請求項１６に記載のコンピュータ実施方法。
  25. 前記編集ツールが、前記複数の仮想ウェブページを生成するために使用されるコードに対する編集を受信するように構成される、請求項１６に記載のコンピュータ実施方法。
  26. 前記編集ツールが、前記複数の仮想ウェブページを生成するために使用される実際のコードを表すスケルトンコードの複数のセグメントを表示するように、また前記実際のコードに対する編集に変換される前記スケルトンコードに対する編集を受信するように構成される、請求項１６に記載のコンピュータ実施方法。
  27. 前記データ要素が、外部ソースから前記ユーザインターフェースを介して受信される、請求項１６に記載のコンピュータ実施方法。
  28. ウェブページに投入されるデータセットを含むバックエンドデータベースを更新するために前記ウェブページを動的に編集できるようにするシステムであって、前記システムが、
    複数のウェブページに表示するための複数のデータ要素を格納するように構成されたオンラインデータベースであって、前記データ要素が、少なくとも１つのデータ要素の１つまたは複数のグループに編成され、各グループがウェブサイトの個別のウェブページに表示するためのものであり、各個別のウェブページが前記オンラインデータベースを更新するための機能を持たない、オンラインデータベースと、
    少なくとも１つのプロセッサであって、
    少なくとも１つのデータ要素のグループに基づいて生成された第１のウェブページの編集可能なバージョンを表示するインターフェースを提供するための命令をブラウザにリモートで提供し、前記インターフェースによりユーザが前記少なくとも１つのデータ要素を編集でき、
    前記インターフェースを介して受信した、前記第１のウェブページの前記編集可能なバージョンに対する編集を、前記オンラインデータベースのための更新に変換し、
    前記オンラインデータベースに前記更新を格納し、
    前記第１のウェブページのライブビュー中に、前記第１のウェブページの前記編集可能なバージョンに対して前記更新を行った状態で前記第１のウェブページを表示できるようにする、
    ように構成される、少なくとも１つのプロセッサと、
    を備える、システム。
  29. 前記少なくとも１つのプロセッサが、ウェブページの複数の個別の編集可能なバージョンを生成するようにさらに構成され、ウェブページの個別の編集可能なバージョンはそれぞれ、前記インターフェースのエディタインターフェースに関連付けられたフレーム内に表示可能である、請求項２８に記載のシステム。
JP2024040504A 2017-07-24 2024-03-14 仮想ウェブページのプレビュー中におけるデータベースの編集 Pending JP2024075645A (ja)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US201762536403P 2017-07-24 2017-07-24
US62/536,403 2017-07-24
US201862702278P 2018-07-23 2018-07-23
US62/702,278 2018-07-23
PCT/IB2018/001028 WO2019038588A1 (en) 2017-07-24 2018-07-24 EDITING A DATABASE WHEN PREDICTING A VIRTUAL WEB PAGE
JP2020503801A JP2020530610A (ja) 2017-07-24 2018-07-24 仮想ウェブページのプレビュー中におけるデータベースの編集

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2020503801A Division JP2020530610A (ja) 2017-07-24 2018-07-24 仮想ウェブページのプレビュー中におけるデータベースの編集

Publications (1)

Publication Number Publication Date
JP2024075645A true JP2024075645A (ja) 2024-06-04

Family

ID=65014202

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2020503801A Pending JP2020530610A (ja) 2017-07-24 2018-07-24 仮想ウェブページのプレビュー中におけるデータベースの編集
JP2024040504A Pending JP2024075645A (ja) 2017-07-24 2024-03-14 仮想ウェブページのプレビュー中におけるデータベースの編集

Family Applications Before (1)

Application Number Title Priority Date Filing Date
JP2020503801A Pending JP2020530610A (ja) 2017-07-24 2018-07-24 仮想ウェブページのプレビュー中におけるデータベースの編集

Country Status (9)

Country Link
US (11) US10209966B2 (ja)
EP (2) EP4235461A3 (ja)
JP (2) JP2020530610A (ja)
AU (2) AU2018319444B2 (ja)
BR (1) BR112019024309A2 (ja)
CA (1) CA3060362A1 (ja)
ES (1) ES2970458T3 (ja)
IL (1) IL271915A (ja)
WO (1) WO2019038588A1 (ja)

Families Citing this family (55)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8671352B1 (en) 2013-05-07 2014-03-11 Axure Software Solutions, Inc. Variable dimension version editing for graphical designs
US9158656B1 (en) * 2014-07-15 2015-10-13 American Express Travel Related Services Company, Inc. Systems and methods for progressively launching websites
US10209966B2 (en) 2017-07-24 2019-02-19 Wix.Com Ltd. Custom back-end functionality in an online website building environment
US20190065487A1 (en) * 2017-08-22 2019-02-28 Salesforce.Com, Inc. Filter logic in a dynamic page previewer
US11392664B1 (en) * 2017-08-29 2022-07-19 Massachusetts Mutual Life Insurance Company Dynamic web application based on events
GB201804904D0 (en) * 2018-03-27 2018-05-09 Palantir Technologies Inc Code correction
JP2019211827A (ja) * 2018-05-31 2019-12-12 ファナック株式会社 支援装置
CN109213486A (zh) * 2018-08-20 2019-01-15 北京百度网讯科技有限公司 用于生成用户定制的可视化组件的方法和装置
US10592589B1 (en) 2018-08-21 2020-03-17 Axure Software Solutions, Inc. Multi-view masters for graphical designs
US10691428B2 (en) * 2018-10-24 2020-06-23 Sap Se Digital compliance platform
WO2020100081A1 (en) 2018-11-14 2020-05-22 Wix.Com Ltd. System and method for creation and handling of configurable applications for website building systems
US10757009B2 (en) 2018-11-20 2020-08-25 Amazon Technologies, Inc. Global-scale connectivity using scalable virtual traffic hubs
US11579908B2 (en) 2018-12-18 2023-02-14 Vmware, Inc. Containerized workload scheduling
JP2022100419A (ja) * 2019-04-23 2022-07-06 株式会社ラキール 情報処理システム、情報処理装置、情報処理方法及びプログラム
US11134028B2 (en) 2019-04-26 2021-09-28 NM Nevada Trust Devices, systems and methods for optimizing workload performance of user facing web applications during high load events
CN110362299B (zh) * 2019-06-14 2020-06-26 杭州古德微机器人有限公司 一种基于blockly和树莓派的在线图形化编程***及其使用方法
US11349839B2 (en) * 2019-06-28 2022-05-31 Google Llc Systems and methods using modular user interfaces for managing network permissions
CN110286896B (zh) * 2019-06-28 2023-03-31 百度在线网络技术（北京）有限公司 可视化编辑方法、装置、设备及存储介质
US11635990B2 (en) 2019-07-01 2023-04-25 Nutanix, Inc. Scalable centralized manager including examples of data pipeline deployment to an edge system
US11501881B2 (en) 2019-07-03 2022-11-15 Nutanix, Inc. Apparatus and method for deploying a mobile device as a data source in an IoT system
US11457009B2 (en) * 2019-07-17 2022-09-27 Infiltron Holdings, Inc. Systems and methods for securing devices in a computing environment
US10789195B1 (en) * 2019-07-17 2020-09-29 Capital One Services, Llc Article, device, and techniques for serverless streaming message processing
CN110389807B (zh) * 2019-07-23 2022-10-25 北京字节跳动网络技术有限公司 一种界面翻译方法、装置、电子设备及存储介质
US11132418B2 (en) * 2019-08-01 2021-09-28 Kindest, Inc. Systems and methods for generating floating button interfaces on a web browser
US11172014B2 (en) * 2019-08-21 2021-11-09 Open Text Sa Ulc Smart URL integration using serverless service
US11727083B2 (en) * 2019-09-13 2023-08-15 Oracle International Corporation System and method for automatic selection for dynamic site compilation within a cloud-based content hub environment
US11372947B2 (en) * 2019-09-13 2022-06-28 Oracle International Corporation System and method for automatic selection for dynamic site compilation within a cloud-based content hub environment
US11645047B2 (en) 2019-09-13 2023-05-09 Axure Software Solutions, Inc. Focused specification generation for interactive designs
US11853806B2 (en) 2019-09-27 2023-12-26 Cloudflare, Inc. Cloud computing platform that executes third-party code in a distributed cloud computing network and uses a distributed data store
US11853752B2 (en) * 2019-09-30 2023-12-26 EMC IP Holding Company LLC Migration of web applications between different web application frameworks
US10997341B1 (en) * 2019-12-12 2021-05-04 Salesforce.Com, Inc. System editing plugin
AU2020100253A4 (en) * 2020-02-21 2020-03-26 Soul & Wolf Pty Ltd Automation of CMS Development for a Website or Web Application
US11023558B1 (en) 2020-04-03 2021-06-01 International Business Machines Corporation Executing functions on-demand on a server utilizing web browsers
CN111625222B (zh) * 2020-05-26 2023-08-04 北京互金新融科技有限公司 前端代码的线上验证***及验证方法
US11553030B2 (en) * 2020-06-01 2023-01-10 Microsoft Technology Licensing, Llc Service worker configured to serve multiple single page applications
US11848084B1 (en) * 2020-07-23 2023-12-19 Express Scripts Strategic Development, Inc. Automated on-demand generation of custom physical labels for medication containers
US11204975B1 (en) * 2020-08-10 2021-12-21 Coupang Corp. Program interface remote management and provisioning
US11762531B2 (en) * 2020-10-28 2023-09-19 Axure Software Solutions, Inc. Stateful widget container management for interactive designs
US11321412B1 (en) * 2020-11-04 2022-05-03 Capital One Services, Llc Customized navigation flow
US11726764B2 (en) 2020-11-11 2023-08-15 Nutanix, Inc. Upgrade systems for service domains
US11665221B2 (en) 2020-11-13 2023-05-30 Nutanix, Inc. Common services model for multi-cloud platform
US11271987B1 (en) * 2020-11-26 2022-03-08 Digital.Ai Software, Inc. Universal webhook connectivity via multi-step HTTP transformation
CN112596719B (zh) * 2020-12-25 2024-07-05 中国农业银行股份有限公司 一种生成前后端代码的方法和***
US11175972B1 (en) 2021-02-24 2021-11-16 Contentful GmbH Application framework for integrating APPs for editing content of a content management system
US11736585B2 (en) 2021-02-26 2023-08-22 Nutanix, Inc. Generic proxy endpoints using protocol tunnels including life cycle management and examples for distributed cloud native services and applications
US11824773B2 (en) 2021-03-30 2023-11-21 Amazon Technologies, Inc. Dynamic routing for peered virtual routers
US11907402B1 (en) * 2021-04-28 2024-02-20 Wells Fargo Bank, N.A. Computer-implemented methods, apparatuses, and computer program products for frequency based operations
CN113176878B (zh) * 2021-06-30 2021-10-08 深圳市维度数据科技股份有限公司 自动查询方法、装置和设备
US11558448B1 (en) * 2021-09-22 2023-01-17 International Business Machines Corporation Sparse information sharing system
US11562043B1 (en) * 2021-10-29 2023-01-24 Shopify Inc. System and method for rendering webpage code to dynamically disable an element of template code
US11989255B2 (en) * 2021-12-30 2024-05-21 Monday.com Ltd. Client-side sorting and updating of paginated data obtained from a server
US11922116B2 (en) * 2022-04-11 2024-03-05 Contentful GmbH Annotations in a content model of a content management system
US20240211528A1 (en) 2022-12-27 2024-06-27 Wix.Com Ltd. System, method, and computer program product for securely enabling rendering of a hybrid website interface based on trusted and untrusted code components
US20240220710A1 (en) 2022-12-30 2024-07-04 Wix.Com Ltd. System and method for integrated temporal external resource allocation
US12021743B1 (en) 2023-03-27 2024-06-25 Amazon Technologies, Inc. Software-defined multi-network-segment gateways for scalable routing of traffic between customer-premise network segments and cloud-based virtual networks

Family Cites Families (139)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6247032B1 (en) * 1997-06-19 2001-06-12 International Business Machines Corp. Automated system and method for approving web site content
WO2000050969A2 (en) * 1999-02-26 2000-08-31 Henry Haugland Mass generation of individual virtual servers, virtual web sites and virtual web objects
US7596606B2 (en) * 1999-03-11 2009-09-29 Codignotto John D Message publishing system for publishing messages from identified, authorized senders
US6636242B2 (en) * 1999-08-31 2003-10-21 Accenture Llp View configurer in a presentation services patterns environment
US7289964B1 (en) * 1999-08-31 2007-10-30 Accenture Llp System and method for transaction services patterns in a netcentric environment
US6728762B1 (en) * 2000-01-04 2004-04-27 International Business Machines Corporation System and method for browser definition of workflow documents
US8065399B2 (en) * 2000-04-17 2011-11-22 Circadence Corporation Automated network infrastructure test and diagnostic system and method therefor
US20020065851A1 (en) * 2000-06-02 2002-05-30 Watson Emerson C. System and method for creating a website
US6732332B1 (en) * 2000-08-28 2004-05-04 Und Aerospace Foundation Automated web site creation system
US6901424B1 (en) * 2000-10-10 2005-05-31 Markettools, Inc. System and method for creating a sample pool for a web-based survey
US20020099738A1 (en) * 2000-11-22 2002-07-25 Grant Hugh Alexander Automated web access for back-end enterprise systems
JP2002202937A (ja) * 2000-12-28 2002-07-19 Ibi Kk ウェブサイト自動作成装置、ウェブサイト自動作成システム、ウェブサイト自動作成方法、及び、記録媒体
US20020165936A1 (en) * 2001-01-25 2002-11-07 Victor Alston Dynamically branded web sites
JP2004530191A (ja) * 2001-02-22 2004-09-30 アクセンチュア グローバル サービスィズ ゲーエムベーハー ウェブ・サービスで構成された、インタネット・ホスティング・ビジネス・アプリケーションの開発システム
US8601492B2 (en) * 2001-03-31 2013-12-03 Siebel Systems, Inc. User interface for multi-channel communication
US7546576B2 (en) * 2001-06-15 2009-06-09 Lightsurf Technology, Inc. Software framework for web-based applications
US7000218B2 (en) * 2001-06-29 2006-02-14 International Business Machines Corporation System and method for developing custom programmable tags
US6985939B2 (en) * 2001-09-19 2006-01-10 International Business Machines Corporation Building distributed software services as aggregations of other services
US7178108B1 (en) * 2001-12-28 2007-02-13 Sprint Communications Company L.P. System and method for development, maintenance and modification of multiple web sites
JP2004005527A (ja) * 2002-03-28 2004-01-08 Yosuke Hiratsuka 階層型サイト情報作成プログラム
JP2004062402A (ja) * 2002-07-26 2004-02-26 Fujitsu Ltd タイムアウト管理システム、タイムアウト管理サーバ、およびタイムアウト管理プログラム
CA2406876A1 (en) * 2002-10-04 2004-04-04 Ibm Canada Limited-Ibm Canada Limitee Method and apparatus for managing a collection of portlets in a portal server
US7240077B1 (en) * 2002-12-30 2007-07-03 Amazon.Com, Inc. Web site content change management
US7062506B2 (en) * 2003-01-24 2006-06-13 The Cobalt Group, Inc. Staged publication and management of dynamic webpages
US7613687B2 (en) * 2003-05-30 2009-11-03 Truelocal Inc. Systems and methods for enhancing web-based searching
US9778919B2 (en) * 2003-06-27 2017-10-03 Adobe Systems Incorporated Dual context interaction with a content object for facilitating content creation and software development
US20040268238A1 (en) * 2003-06-30 2004-12-30 Peiya Liu Systems and methods for processing documents using an XML-based process flow description language
US7308643B1 (en) * 2003-07-03 2007-12-11 Google Inc. Anchor tag indexing in a web crawler system
US7403491B2 (en) * 2004-04-15 2008-07-22 Alcatel Lucent Framework for template-based retrieval of information from managed entities in a communication network
JP2006146506A (ja) * 2004-11-18 2006-06-08 Image:Kk Ｗｅｂサイト更新システム、Ｗｅｂサイト更新方法およびＷｅｂサイト更新プログラム
US8019749B2 (en) * 2005-03-17 2011-09-13 Roy Leban System, method, and user interface for organizing and searching information
US7689663B2 (en) * 2005-03-24 2010-03-30 Hewlett-Packard Development Company, L.P. Embedded web-based management method
US7536641B2 (en) * 2005-04-29 2009-05-19 Google Inc. Web page authoring tool for structured documents
US7734644B2 (en) * 2005-05-06 2010-06-08 Seaton Gras System and method for hierarchical information retrieval from a coded collection of relational data
US7734722B2 (en) * 2005-06-02 2010-06-08 Genius.Com Incorporated Deep clickflow tracking
CA2622315C (en) * 2005-08-17 2017-02-21 Wideport.Com Inc. Automatic website generator
US8117531B1 (en) * 2005-09-23 2012-02-14 Google Inc. Interpreted language translation system and method
US8301997B2 (en) * 2006-01-10 2012-10-30 International Business Machines Corporation System and method for serving multiple data objects and formatting functions in a single request
GB2434947B (en) * 2006-02-02 2011-01-26 Identum Ltd Electronic data communication system
US20070220419A1 (en) * 2006-03-10 2007-09-20 Web.Com, Inc. Systems and Methods of Providing Web Content to Multiple Browser Device Types
US7974956B2 (en) * 2006-07-21 2011-07-05 Yahoo! Inc. Authenticating a site while protecting against security holes by handling common web server configurations
US20080071929A1 (en) * 2006-09-18 2008-03-20 Yann Emmanuel Motte Methods and apparatus for selection of information and web page generation
US20090210631A1 (en) * 2006-09-22 2009-08-20 Bea Systems, Inc. Mobile application cache system
GB0622823D0 (en) * 2006-11-15 2006-12-27 British Broadcasting Corp Accessing content
US20080133647A1 (en) * 2006-11-17 2008-06-05 Mehrak Hamzeh System and method for delivering web content to a mobile network
US9524353B2 (en) * 2007-02-09 2016-12-20 Nokia Technologies Oy Method and system for providing portions of information content to a client device
US20080243852A1 (en) * 2007-03-26 2008-10-02 International Business Machines Corporation System and Methods for Enabling Collaboration in Online Enterprise Applications
US8499237B2 (en) * 2007-03-29 2013-07-30 Hiconversion, Inc. Method and apparatus for application enabling of websites
EP2151064B1 (en) * 2007-05-03 2015-06-24 3Dlabs Inc., Ltd. Method for remotely configuring user interfaces for portable devices
US8838728B2 (en) * 2007-05-22 2014-09-16 Nokia Corporation Method, system, apparatus, network entity and computer program product for providing a user with an editable webpage
US10019570B2 (en) * 2007-06-14 2018-07-10 Microsoft Technology Licensing, Llc Protection and communication abstractions for web browsers
US8181246B2 (en) * 2007-06-20 2012-05-15 Imperva, Inc. System and method for preventing web frauds committed using client-scripting attacks
US8577835B2 (en) * 2007-06-28 2013-11-05 Salesforce.Com, Inc. Method and system for sharing data between subscribers of a multi-tenant database service
US8584094B2 (en) * 2007-06-29 2013-11-12 Microsoft Corporation Dynamically computing reputation scores for objects
US7779161B2 (en) * 2007-07-24 2010-08-17 Hiconversion, Inc. Method and apparatus for general virtual application enabling of websites
US8464228B2 (en) * 2007-08-23 2013-06-11 Accenture Global Services Limited Binary library
US9268849B2 (en) * 2007-09-07 2016-02-23 Alexander Siedlecki Apparatus and methods for web marketing tools for digital archives—web portal advertising arts
US8387006B1 (en) * 2007-12-05 2013-02-26 Adobe Systems Incorporated System and method for authoring a web page to be run-time editable
WO2009082653A1 (en) * 2007-12-20 2009-07-02 Hsbc Technologies Inc. Automated methods and systems for developing and deploying projects in parallel
JP2009176296A (ja) * 2007-12-27 2009-08-06 Nippon Institute Of Agroinformatics Ltd Ｗｅｂ文書編集方法
US7886021B2 (en) * 2008-04-28 2011-02-08 Oracle America, Inc. System and method for programmatic management of distributed computing resources
US8341200B2 (en) * 2008-06-12 2012-12-25 Pomian & Corella, Llc Protecting a web application against attacks through shared files
MY154409A (en) * 2008-07-21 2015-06-15 Secure Corp M Sdn Bhd F Website content regulation
WO2010011792A2 (en) * 2008-07-22 2010-01-28 Widemile Inc. Method and system for web-site testing
JP5476709B2 (ja) * 2008-12-09 2014-04-23 富士通株式会社 Ｗｅｂページ編集プログラム及びＷｅｂページ編集装置
US9691170B2 (en) * 2009-03-18 2017-06-27 Shutterfly, Inc. Proactive creation of photo products
GB0909695D0 (en) * 2009-06-05 2009-07-22 Maxymiser Ltd On page console
US9883008B2 (en) * 2010-01-15 2018-01-30 Endurance International Group, Inc. Virtualization of multiple distinct website hosting architectures
US8438648B2 (en) * 2010-02-16 2013-05-07 Celartem, Inc. Preventing unauthorized font linking
US8850219B2 (en) * 2010-05-13 2014-09-30 Salesforce.Com, Inc. Secure communications
JP5841535B2 (ja) * 2010-07-25 2016-01-13 株式会社コアアプリ ファイル公開管理コンピュータプログラム、ファイル公開管理コンピュータシステム
US20120131645A1 (en) * 2010-11-18 2012-05-24 Harm Michael W User Scriptable Server Initiated User Interface Creation
US8839093B1 (en) * 2011-01-12 2014-09-16 Optimizely, Inc. Systems and methods for website optimization
US8910156B1 (en) * 2011-04-29 2014-12-09 Netapp, Inc. Virtual machine dependency
US8938791B2 (en) * 2011-06-10 2015-01-20 International Business Machines Corporation System and method to control display of a realm name
US8874593B2 (en) * 2011-07-01 2014-10-28 Salesforce.Com, Inc. Testing data silo
US8959427B1 (en) * 2011-08-05 2015-02-17 Google Inc. System and method for JavaScript based HTML website layouts
US8474056B2 (en) 2011-08-15 2013-06-25 Bank Of America Corporation Method and apparatus for token-based virtual machine recycling
US20130304604A1 (en) * 2011-11-02 2013-11-14 Michael Theodor Hoffman Systems and methods for dynamic digital product synthesis, commerce, and distribution
US20130117152A1 (en) * 2011-11-03 2013-05-09 Cbs Interactive, Inc. Javascript Widget Storefront
US8671417B2 (en) * 2011-12-12 2014-03-11 Microsoft Corporation Lightweight framework for web applications
US8793660B2 (en) * 2011-12-30 2014-07-29 Cellco Partnership Automated testing of programming code for a web service
DE102013202782A1 (de) 2012-02-20 2013-08-22 Wixpress Ltd Server-basiertes Webseiten-Designsystem, das ein dynamisches Layout und dynamischen Inhalt integriert
US10222926B2 (en) * 2012-03-19 2019-03-05 Citrix Systems, Inc. Systems and methods for providing user interfaces for management applications
US9430449B2 (en) * 2012-03-30 2016-08-30 Sdl Plc Systems, methods, and media for managing editable previews of webpages
US9262420B1 (en) * 2012-04-23 2016-02-16 Google Inc. Third-party indexable text
US20130346849A1 (en) * 2012-06-06 2013-12-26 Minds + Machines Automatic uploading and synchronization of media assets
US20140095463A1 (en) * 2012-06-06 2014-04-03 Derek Edwin Pappas Product Search Engine
US8943086B2 (en) * 2012-06-29 2015-01-27 Sap Se Model-based backend service adaptation of business objects
US20140047413A1 (en) * 2012-08-09 2014-02-13 Modit, Inc. Developing, Modifying, and Using Applications
US8522134B1 (en) * 2012-08-13 2013-08-27 Volusion, Inc. Methods and apparatus for in-line editing of web page content with reduced disruption of logical and presentational structure of content
US20140053060A1 (en) * 2012-08-17 2014-02-20 Launchbase, LLC Website development tool
US10585981B2 (en) * 2012-09-13 2020-03-10 Samir Issa Method of data capture, storage and retrieval through user created form templates and data item templates by executing computer-executable instructions stored on a non-transitory computer-readable medium
US9317490B2 (en) * 2012-09-19 2016-04-19 TagMan Inc. Systems and methods for 3-tier tag container architecture
US20140096038A1 (en) * 2012-09-28 2014-04-03 Interactive Memories, Inc. Method for Editing Font Size for Font Arranged in a Layout on an Electronic Interface using Real Time Visual Input
US11449952B2 (en) * 2012-10-01 2022-09-20 Oracle International Corporation Efficiently modeling database scenarios for later use on live data
US9195477B1 (en) * 2012-10-09 2015-11-24 Sencha, Inc. Device profiles, deep linking, and browser history support for web applications
US9185078B2 (en) * 2012-12-18 2015-11-10 Salesforce.Com, Inc. Systems, methods, and apparatuses for implementing cross organizational data sharing
US10089406B2 (en) * 2013-01-30 2018-10-02 Oracle International Corporation Generating web pages with integrated content
US9712593B2 (en) * 2013-02-04 2017-07-18 Oracle International Corporation Javascript API for WebRTC
US9307031B2 (en) * 2013-02-04 2016-04-05 Oracle International Corporation Generic model for customizing protocol behavior through javascript
CA3205266A1 (en) 2013-02-10 2014-08-14 Wix.Com Ltd. Third-party application communication api
CA3208976A1 (en) * 2013-03-14 2014-09-18 Wix.Com Ltd. Device, system, and method of website building by utilizing data lists
US9971790B2 (en) * 2013-03-15 2018-05-15 Google Llc Generating descriptive text for images in documents using seed descriptors
US20170147480A1 (en) * 2013-04-23 2017-05-25 Google Inc. Test script generation
US20150011338A1 (en) * 2013-07-02 2015-01-08 Jeremy Russotti Training device
US10362145B2 (en) * 2013-07-05 2019-07-23 The Boeing Company Server system for providing current data and past data to clients
US9836330B2 (en) 2013-07-16 2017-12-05 Hitachi, Ltd. Virtual resource management tool for cloud computing service
US9513885B2 (en) * 2013-08-22 2016-12-06 Peter Warren Web application development platform with relationship modeling
US20150058339A1 (en) 2013-08-26 2015-02-26 Go DaddyOperating Company, LLC Method for automating search engine optimization for websites
US9229702B1 (en) * 2013-08-28 2016-01-05 Lithium Technologies, Inc. Systems and methods for application plugin deployment for websites
US10853837B2 (en) * 2013-10-07 2020-12-01 Adobe Inc. Integrated testing, targeting and measuring of web site components
US9519525B2 (en) * 2013-11-14 2016-12-13 Dropbox, Inc. File-level commenting
US9817801B2 (en) 2013-12-04 2017-11-14 Go Daddy Operating Company, LLC Website content and SEO modifications via a web browser for native and third party hosted websites
US9607332B1 (en) * 2014-02-07 2017-03-28 Google Inc. Embedded web application gallery
MX359824B (es) 2014-02-11 2018-10-11 Wix Com Ltd Sistema para la sincronizacion de cambios en sitios web editados y aplicaciones interactivas.
CN106575248A (zh) * 2014-05-18 2017-04-19 周凯 性能测试***和方法
US9954936B2 (en) 2015-03-02 2018-04-24 International Business Machines Corporation Migrating legacy applications to a multi-tenant computing environment
EP3304338B1 (en) 2015-06-07 2024-03-06 Wix.com Ltd. System and method for the generation of an adaptive user interface in a website building system
US10726371B2 (en) * 2015-06-08 2020-07-28 Sap Se Test system using production data without disturbing production system
US10474489B2 (en) 2015-06-26 2019-11-12 Intel Corporation Techniques to run one or more containers on a virtual machine
US9864735B1 (en) * 2015-08-27 2018-01-09 Google Llc In-domain webpage editing
US10229214B2 (en) * 2015-12-31 2019-03-12 Ca, Inc. Dynamic web page navigation
US10148790B2 (en) * 2016-03-04 2018-12-04 Bank Of America Corporation Deployment of integrative HTML-based engine from an edge server
US10684839B2 (en) * 2016-06-15 2020-06-16 Red Hat Israel, Ltd. Plugin for software deployment
US10678995B2 (en) * 2016-08-12 2020-06-09 Netsuite, Inc. System and methods for control of content presented on web pages
US20180052809A1 (en) * 2016-08-16 2018-02-22 Microsoft Technology Licensing, Llc Inferring user interaction with an iframe
US10025924B1 (en) * 2016-08-26 2018-07-17 Parallels IP Holdings GmbH Taskless containers for enhanced isolation of users and multi-tenant applications
US10223078B2 (en) * 2016-09-29 2019-03-05 Ca, Inc. Application-type independent dynamic plug-in evaluation tool
US20180097820A1 (en) * 2016-10-03 2018-04-05 Adobe Systems Incorporated Managing content upload and content retrieval
US11537272B2 (en) * 2016-12-21 2022-12-27 Aon Global Operations Se, Singapore Branch Content management system extensions
US10250389B2 (en) * 2017-01-17 2019-04-02 Go Daddy Operating Company, LLC Script verification using a hash
US10671570B2 (en) * 2017-02-01 2020-06-02 Open Text Sa Ulc Web application open platform interface (WOPI) server architecture and applications for distributed network computing environments
US11003668B2 (en) * 2017-02-21 2021-05-11 Sap Se Programming language independent software testing environment
US20180309720A1 (en) * 2017-04-25 2018-10-25 Verisign, Inc. Systems, devices, and methods for automatic website generation and domain name suggestion
US10572361B2 (en) * 2017-04-28 2020-02-25 The Boeing Company Concurrent production use of a production enterprise system and testing of a modified enterprise system
US10209966B2 (en) 2017-07-24 2019-02-19 Wix.Com Ltd. Custom back-end functionality in an online website building environment
US10866935B2 (en) * 2017-08-18 2020-12-15 Benjamin J. Chung File management method
US20200057714A1 (en) * 2018-08-17 2020-02-20 Google Llc Testing data changes in production systems

Also Published As

Publication number Publication date
US10379820B1 (en) 2019-08-13
EP3593254A1 (en) 2020-01-15
CA3060362A1 (en) 2019-02-28
US20190149591A1 (en) 2019-05-16
US20190026443A1 (en) 2019-01-24
US10326821B2 (en) 2019-06-18
ES2970458T3 (es) 2024-05-28
US10397305B1 (en) 2019-08-27
JP2020530610A (ja) 2020-10-22
US20190026083A1 (en) 2019-01-24
WO2019038588A1 (en) 2019-02-28
US10331420B2 (en) 2019-06-25
EP4235461A2 (en) 2023-08-30
US10915300B2 (en) 2021-02-09
US20190026382A1 (en) 2019-01-24
US20190028531A1 (en) 2019-01-24
US20190026082A1 (en) 2019-01-24
US20210397776A1 (en) 2021-12-23
EP3593254B1 (en) 2023-08-02
US11106860B2 (en) 2021-08-31
US20190258459A1 (en) 2019-08-22
US10209966B2 (en) 2019-02-19
US20240220706A1 (en) 2024-07-04
US10521198B2 (en) 2019-12-31
US20190245910A1 (en) 2019-08-08
AU2024200221A1 (en) 2024-02-01
US10719300B2 (en) 2020-07-21
IL271915A (en) 2020-02-27
EP3593254A4 (en) 2021-01-20
US20190026296A1 (en) 2019-01-24
US11875104B2 (en) 2024-01-16
AU2018319444B2 (en) 2023-11-16
AU2018319444A1 (en) 2019-10-31
EP4235461A3 (en) 2023-11-15
BR112019024309A2 (pt) 2020-11-03

Similar Documents

Publication Publication Date Title
JP2024075645A (ja) 仮想ウェブページのプレビュー中におけるデータベースの編集
US20200257437A1 (en) Methods and systems for web content generation
Esposito Programming Microsoft ASP. NET MVC
Paz Beginning ASP. NET MVC 4
Ragupathi Learning ASP. NET Core MVC Programming
Manfield Joomla for Developers
Vogelsteller et al. Meteor: Full-Stack Web Application Development
Bowden Visualforce Development Cookbook
Prettyman et al. Interfaces, Platforms, and Three-Tier Programming
Robinson et al. Introducing Meteor
Hertel Aspects of AJAX
Latifi Architecture patterns in web applications and implementation of find local food

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20240415

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20240415

A871 Explanation of circumstances concerning accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A871

Effective date: 20240508

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20240702