JP2020530610A - 仮想ウェブページのプレビュー中におけるデータベースの編集 - Google Patents
仮想ウェブページのプレビュー中におけるデータベースの編集 Download PDFInfo
- Publication number
- JP2020530610A JP2020530610A JP2020503801A JP2020503801A JP2020530610A JP 2020530610 A JP2020530610 A JP 2020530610A JP 2020503801 A JP2020503801 A JP 2020503801A JP 2020503801 A JP2020503801 A JP 2020503801A JP 2020530610 A JP2020530610 A JP 2020530610A
- Authority
- JP
- Japan
- Prior art keywords
- website
- web page
- data
- code
- 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
Links
- 238000000034 method Methods 0.000 claims description 288
- 238000012360 testing method Methods 0.000 description 253
- 230000006870 function Effects 0.000 description 244
- 239000008186 active pharmaceutical agent Substances 0.000 description 99
- 230000004044 response Effects 0.000 description 87
- 230000008569 process Effects 0.000 description 68
- 238000011161 development Methods 0.000 description 62
- 238000003860 storage Methods 0.000 description 54
- 238000010586 diagram Methods 0.000 description 37
- 230000008859 change Effects 0.000 description 36
- 238000012545 processing Methods 0.000 description 30
- 230000009471 action Effects 0.000 description 28
- 230000007246 mechanism Effects 0.000 description 28
- 241001465754 Metazoa Species 0.000 description 25
- 238000004891 communication Methods 0.000 description 25
- 230000003993 interaction Effects 0.000 description 24
- 238000010276 construction Methods 0.000 description 23
- 230000000007 visual effect Effects 0.000 description 23
- 230000008676 import Effects 0.000 description 22
- 238000013507 mapping Methods 0.000 description 20
- 238000010411 cooking Methods 0.000 description 19
- 238000013515 script Methods 0.000 description 19
- 230000003068 static effect Effects 0.000 description 17
- 238000013461 design Methods 0.000 description 15
- 238000012544 monitoring process Methods 0.000 description 15
- 230000006399 behavior Effects 0.000 description 14
- 235000014510 cooky Nutrition 0.000 description 13
- 238000000926 separation method Methods 0.000 description 13
- 230000002085 persistent effect Effects 0.000 description 12
- 244000035744 Hura crepitans Species 0.000 description 11
- 238000004364 calculation method Methods 0.000 description 11
- 238000012986 modification Methods 0.000 description 11
- 230000004048 modification Effects 0.000 description 11
- 238000009877 rendering Methods 0.000 description 11
- 230000001960 triggered effect Effects 0.000 description 11
- 238000007726 management method Methods 0.000 description 10
- 230000000717 retained effect Effects 0.000 description 10
- 238000004422 calculation algorithm Methods 0.000 description 8
- 238000002955 isolation Methods 0.000 description 8
- 239000000463 material Substances 0.000 description 8
- 238000004458 analytical method Methods 0.000 description 7
- 230000000694 effects Effects 0.000 description 7
- 230000006978 adaptation Effects 0.000 description 6
- 230000008901 benefit Effects 0.000 description 6
- 238000006243 chemical reaction Methods 0.000 description 6
- 235000013305 food Nutrition 0.000 description 6
- 238000004519 manufacturing process Methods 0.000 description 6
- 241000282376 Panthera tigris Species 0.000 description 5
- 235000021185 dessert Nutrition 0.000 description 5
- 235000012054 meals Nutrition 0.000 description 5
- 230000003287 optical effect Effects 0.000 description 5
- HFHZKZSRXITVMK-UHFFFAOYSA-N oxyphenbutazone Chemical compound O=C1C(CCCC)C(=O)N(C=2C=CC=CC=2)N1C1=CC=C(O)C=C1 HFHZKZSRXITVMK-UHFFFAOYSA-N 0.000 description 5
- 230000003213 activating effect Effects 0.000 description 4
- 230000005540 biological transmission Effects 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 4
- 230000000737 periodic effect Effects 0.000 description 4
- 239000000047 product Substances 0.000 description 4
- 230000007704 transition Effects 0.000 description 4
- 238000010200 validation analysis Methods 0.000 description 4
- DBGIVFWFUFKIQN-UHFFFAOYSA-N (+-)-Fenfluramine Chemical compound CCNC(C)CC1=CC=CC(C(F)(F)F)=C1 DBGIVFWFUFKIQN-UHFFFAOYSA-N 0.000 description 3
- 235000001674 Agaricus brunnescens Nutrition 0.000 description 3
- 241000282461 Canis lupus Species 0.000 description 3
- VYZAMTAEIAYCRO-UHFFFAOYSA-N Chromium Chemical compound [Cr] VYZAMTAEIAYCRO-UHFFFAOYSA-N 0.000 description 3
- 235000019219 chocolate Nutrition 0.000 description 3
- 238000004590 computer program Methods 0.000 description 3
- 238000013480 data collection Methods 0.000 description 3
- 238000001914 filtration Methods 0.000 description 3
- 230000004927 fusion Effects 0.000 description 3
- 238000009434 installation Methods 0.000 description 3
- 230000002452 interceptive effect Effects 0.000 description 3
- 239000002245 particle Substances 0.000 description 3
- 235000013550 pizza Nutrition 0.000 description 3
- 238000009987 spinning Methods 0.000 description 3
- 230000026676 system process Effects 0.000 description 3
- 238000012546 transfer Methods 0.000 description 3
- 241000239290 Araneae Species 0.000 description 2
- 238000003491 array Methods 0.000 description 2
- 238000013475 authorization Methods 0.000 description 2
- 230000003542 behavioural effect Effects 0.000 description 2
- 235000020289 caffè mocha Nutrition 0.000 description 2
- 238000013479 data entry Methods 0.000 description 2
- 235000021186 dishes Nutrition 0.000 description 2
- 238000005538 encapsulation Methods 0.000 description 2
- 238000011156 evaluation Methods 0.000 description 2
- 238000007667 floating Methods 0.000 description 2
- 238000010348 incorporation Methods 0.000 description 2
- 208000015181 infectious disease Diseases 0.000 description 2
- 235000021184 main course Nutrition 0.000 description 2
- 239000003550 marker Substances 0.000 description 2
- 239000000203 mixture Substances 0.000 description 2
- 230000002688 persistence Effects 0.000 description 2
- 238000012552 review Methods 0.000 description 2
- 230000001932 seasonal effect Effects 0.000 description 2
- 238000012800 visualization Methods 0.000 description 2
- 230000003442 weekly effect Effects 0.000 description 2
- FMKJUUQOYOHLTF-OWOJBTEDSA-N (e)-4-azaniumylbut-2-enoate Chemical compound NC\C=C\C(O)=O FMKJUUQOYOHLTF-OWOJBTEDSA-N 0.000 description 1
- DHSSDEDRBUKTQY-UHFFFAOYSA-N 6-prop-2-enyl-4,5,7,8-tetrahydrothiazolo[4,5-d]azepin-2-amine Chemical compound C1CN(CC=C)CCC2=C1N=C(N)S2 DHSSDEDRBUKTQY-UHFFFAOYSA-N 0.000 description 1
- 235000002568 Capsicum frutescens Nutrition 0.000 description 1
- 229920000742 Cotton Polymers 0.000 description 1
- 241001417516 Haemulidae Species 0.000 description 1
- 206010020751 Hypersensitivity Diseases 0.000 description 1
- 208000002193 Pain Diseases 0.000 description 1
- 241000885184 Scaris Species 0.000 description 1
- 241001178520 Stomatepia mongo Species 0.000 description 1
- 230000003044 adaptive effect Effects 0.000 description 1
- 230000002776 aggregation Effects 0.000 description 1
- 238000004220 aggregation Methods 0.000 description 1
- 208000026935 allergic disease Diseases 0.000 description 1
- 230000007815 allergy Effects 0.000 description 1
- 230000001174 ascending effect Effects 0.000 description 1
- 230000004888 barrier function Effects 0.000 description 1
- 235000021152 breakfast Nutrition 0.000 description 1
- 239000003795 chemical substances by application Substances 0.000 description 1
- 238000005352 clarification Methods 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 239000000470 constituent Substances 0.000 description 1
- 238000013523 data management Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000013501 data transformation Methods 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 230000007613 environmental effect Effects 0.000 description 1
- 239000012467 final product Substances 0.000 description 1
- 239000012634 fragment Substances 0.000 description 1
- 238000013467 fragmentation Methods 0.000 description 1
- 238000006062 fragmentation reaction Methods 0.000 description 1
- 235000012020 french fries Nutrition 0.000 description 1
- 230000003116 impacting effect Effects 0.000 description 1
- 239000004615 ingredient Substances 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 230000000670 limiting effect Effects 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 239000008267 milk Substances 0.000 description 1
- 235000013336 milk Nutrition 0.000 description 1
- 210000004080 milk Anatomy 0.000 description 1
- 230000006855 networking Effects 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 230000036407 pain Effects 0.000 description 1
- 235000012830 plain croissants Nutrition 0.000 description 1
- 238000003825 pressing Methods 0.000 description 1
- 238000003672 processing method Methods 0.000 description 1
- 230000000644 propagated effect Effects 0.000 description 1
- ZLIBICFPKPWGIZ-UHFFFAOYSA-N pyrimethanil Chemical compound CC1=CC(C)=NC(NC=2C=CC=CC=2)=N1 ZLIBICFPKPWGIZ-UHFFFAOYSA-N 0.000 description 1
- 230000010076 replication Effects 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 238000005316 response function Methods 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 238000005096 rolling process Methods 0.000 description 1
- 238000013341 scale-up Methods 0.000 description 1
- 230000007480 spreading Effects 0.000 description 1
- 238000003892 spreading Methods 0.000 description 1
- 229950008418 talipexole Drugs 0.000 description 1
- 230000008685 targeting Effects 0.000 description 1
- 238000012384 transportation and delivery Methods 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
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
本出願は、2017年7月24日に出願された米国特許仮出願第62/536,403号および2018年7月23日に出願された米国特許仮出願第62/702,278号の優先権を主張するものであり、同仮出願は共に、その全体が参照により本明細書に組み込まれる。
は仮想マシンなど)で実行され得るカスタムバックエンド機能を開発することを含む。
によりウェブサイトへの要求を処理するために使用される。ウェブサイトまたはウェブページの新しいインスタンスをコールドスタートするこのようなプロセスは、大幅な処理遅延および結果として生じるユーザエクスペリエンスにおける待ち時間を伴う。
フロントエンドとバックエンドとの両方のプラグインを分離できる一方で、ウェブサイト所有者およびユーザがそのようなプラグインを依然としてアップロードおよび利用できるようにする必要がある。
テップと、を含み得る。
一意のコードがない汎用ウェブサイトサーバコードを実行する、ことと、特定のウェブサイトにアクセスする要求を受信することであって、特定のウェブサイトが汎用ウェブサイトサーバコードを含むプラットフォーム上に構築されている、ことと、特定のウェブサイトが複数のウェブサーバ実行インスタンスのうちの1つにより既にホストされているか否かを判定することと、要求された特定のウェブサイトが複数のウェブサーバ実行インスタンスのうちの1つによってまだホストされていないと判定された場合に、汎用ウェブサイトサーバコードを実行する複数のウェブサーバ実行インスタンスのうちの第1のインスタンスに要求を差し向けることと、汎用ウェブサイトサーバコードを実行する複数のウェブサーバ実行インスタンスのうちの第1のインスタンスに、少なくとも1つの第2の記憶場所からの要求されたウェブサイトに一意の追加のウェブサイト固有コードを投入することと、汎用ウェブサイトサーバコードと要求されたウェブサイトに一意の投入されたウェブサイト固有コードとの両方の組み合わせにより、複数のウェブサーバ実行インスタンスのうちの第1のインスタンスを介して要求に応答することと、を含む動作を実行するように構成された少なくとも1つのプロセッサをさらに備え得る。
ト固有コードが、要求されたウェブサイトに一意のバックエンドコードを含む。
少なくとも1つの共通データベースにおいてライブデータに関連付けられる、ステップと、少なくとも1つの共通データベースに格納されたライブデータにアクセスするステップと、ウェブサイトデプロイ環境でウェブサイトをレンダリングするために、アクセスしたライブデータを使用するステップと、ウェブサイトがウェブサイトデプロイ環境で稼働している間に、ウェブサイトでテストを実行する要求を受信するステップと、少なくとも1つの共通データベースにおいて、要求に応答して1セットのテストデータにアクセスするステップであって、1セットのテストデータが、それぞれのライブデータ要素に対応する1つまたは複数のテストデータ要素を含み、1セットのテストデータが、ウェブサイトデプロイ環境においてアクセス可能ではない、ステップと、ウェブサイトがウェブサイトデプロイ環境で動作している間に、非公開ウェブサイトテスト環境においてウェブサイトによりテストデータとライブデータとの両方のセットが同時に使用されるように、非公開ウェブサイトテスト環境においてウェブサイトを並行してテストするステップと、を含み得る。
に関連付けられたデータ要素に基づく。
少なくとも1つの個別のウェブページに関連付けられ、複数のグループのそれぞれがさらに、複数のスクロール可能な仮想ウェブページを構成するために、ブラウザによって実行可能なフロントエンドコードおよびブラウザからリモートのバックエンドサーバによって実行可能なバックエンドコードのうちの少なくとも1つによって利用可能である、オンラインデータベースと、少なくとも1つのプロセッサであって、ブラウザに関連付けられたユーザが、データベースにデータ要素を追加できるように、また追加された各データ要素を複数のグループのうちの少なくとも1つに関連付けできるように、またフロントエンドコードおよびバックエンドコードのうちの少なくとも1つを修正できるようにするためのインターフェースを表示するための第2の命令をブラウザにリモートで提供し、ユーザによる追加されたデータ要素、追加されたデータ要素と複数のグループのうちの少なくとも1つとの関連付け、ならびにフロントエンドコードおよびバックエンドコードのうちの少なくとも1つの修正に基づいて、複数のスクロール可能な仮想ウェブページを生成するための第3の命令を実行し、複数のスクロール可能な仮想ウェブページが、少なくとも1つのプロセッサによって独立して生成され、かつユーザによって独立して編集されるように構成され、対応する最終的なウェブページの生成前に複数のスクロール可能な仮想ウェブページを表示するように構成されたプレビューインターフェースを表示するための第4の命令をブラウザにリモートで提供し、プレビューインターフェースは、ユーザが、少なくとも1つのデータ要素の複数のグループのそれぞれに基づいて、複数のスクロール可能な仮想ウェブページにわたって選択的にスクロールすることができるように、また対応する最終ウェブページが稼働される前に、少なくとも1つのデータ要素のグループが対応する最終ウェブページにどのように表示されるかを視覚化することができるようにする、ように構成された少なくとも1つのプロセッサと、を備え得る。
ードおよびブラウザからリモートのバックエンドサーバによって実行可能なバックエンドコードのうちの少なくとも1つによって利用可能である、ステップと、ブラウザに関連付けられたユーザが、データベースにデータ要素を追加できるように、また追加された各データ要素を複数のグループのうちの少なくとも1つに関連付けできるように、またフロントエンドコードおよびバックエンドコードのうちの少なくとも1つを修正できるようにするためのインターフェースを表示するための第2の命令をブラウザにリモートで提供するステップと、ユーザによる追加されたデータ要素、追加されたデータ要素と複数のグループのうちの少なくとも1つとの関連付け、ならびにフロントエンドコードおよびバックエンドコードのうちの少なくとも1つの修正に基づいて、複数のスクロール可能な仮想ウェブページを生成するための第3の命令を実行するステップであって、複数のスクロール可能な仮想ウェブページが、少なくとも1つのプロセッサによって独立して生成され、かつユーザによって独立して編集されるように構成される、ステップと、対応する最終的なウェブページの生成前に複数のスクロール可能な仮想ウェブページを表示するように構成されたプレビューインターフェースを表示するための第4の命令をブラウザにリモートで提供するステップであって、プレビューインターフェースは、ユーザが、少なくとも1つのデータ要素の複数のグループのそれぞれに基づいて、複数のスクロール可能な仮想ウェブページにわたって選択的にスクロールすることができるように、また対応する最終ウェブページが稼働される前に、少なくとも1つのデータ要素のグループが対応する最終ウェブページにどのように表示されるかを視覚化することができるようにする、ステップと、を含み得る。
ージのそれぞれにわたって、ユーザが選択的にナビゲートできるように構成され、ナビゲーションインターフェースが複数の動的ウェブページのネイティブ要素ではない。
プラグインサーバにおけるバックエンドプラグイン機能コードの実行を可能にする分離メカニズムを含み得る。
)と、のリポジトリであり得る。
ジェットおよび他のツールを表すコードの抽象化として表すことができる。構築ツール121は、システムのすべてのユーザに提供されるパブリックデフォルトツールと、特定のウェブサイトまたはユーザにのみ提供されるプライベートツールと、を含み得る。プライベートツールは、ユーザまたはウェブサイトのためにカスタマイズされたパブリックツールまたは新しいツールを含み得る。プライベートツールは、ウェブサイトを構築するシステムのユーザまたはサードパーティベンダによって作成されてもよい。構築ツール121は、異なるユーザグループが構築し、異なるユーザグループが所有する複数のウェブサイト間で共有されてもよい。構築ツール121はまた、既存の構築ツール121のコードを編集することによりカスタマイズされ得る(例えば、ボタンのスタイルシートを更新して、新しいボタンの新しいスタイルシートを作成する)。カスタム構築ツールは、元の構築ツール121と共にシステムエリアデータベース122に格納され得る。
どの他の要素からさらに構成されてもよい。
選択できるようにする。
析を実行して、定義されたソフトウェアルータのどれを使用するかを判定する。そのような分析は、受信したURLに基づいて、URL関連付けDB220に含まれる定義に基づいて、または追加情報または条件(システム環境条件など)に基づいて判定を行うことができる。
クエンド127はいくつかの実施形態ではデータベースエントリを作成または更新する。同様に、別の例として、ブログまたはソーシャルメディアインターフェースへのテキストの投稿を、データフック330に関連付けられたデータ更新とすることができる。データフック330はまた、API呼び出しを介してプログラムでバックエンド127に制御を渡すために使用され得る。例えば、定期的な時間ベースのアクショントリガ310は、削除または非アクティブとしてマークされる期間よりも古いデータベース内のエントリをもたらし得る。
でのウェブサイト123とのユーザ対話に続く内部イベントに基づいて制御を渡すように機能し得る。例えば、データバインディングルータフック350は、ユーザがルーティング先のページにアクセスするパーミッションを持っているか否かを確認するために、上記のようにページへのルーティングを判定する前に機能を実行するために登録され得る。データフック330は、場合により、同じトリガ310に関してデータバインディングルータフック350の前または後に実行できる。例えば、ウェブサイト123に接続されたデータベースに対してクエリを実行した後に、アクティブではなくなったエントリを除外するためにデータフック330が実行される場合がある(例えば、商店のウェブサイトは、データベースクエリ検索結果から販売されなくなった製品をフィルタリングする場合がある)。よって、本システムは、フックの様々な組み合わせの動作、およびフックの相互連鎖をサポートできる。
クス可能なウェブページ125を表示する。この例示的な図において、フロントエンド126は、ページのコンテンツ(例えば、テキスト、グラフィックス、ウィジェットなど)を視覚的に編集するためにWYSIWYGエディタを使用して示されている。いくつかの実施形態では、フロントエンド126はコードとして直接編集され得る。いくつかの実施形態では、構築ツール121は、統合インターフェース410内のユーザインターフェースセクションである。さらなる実施形態では、構築ツール121は、オンラインエディタインターフェース243のメニュー項目によってアクセスされ得る。いくつかの実施形態では、構築ツール121から選択された特定のウェブサイト構築ツールは、統合インターフェース410のフロントエンド126セクションにおいてドラッグアンドドロップされ得る。インデックス可能なウェブページ125のフロントエンド126は、構築ツール121の視覚的な構成を示している。
に基づいて構築ツール121内の選択されたツールのスケルトンコードを自動的に生成する。例えば、図5に関連して上述したように、スケルトンコードは、マウスクリック、ホバー、コンテンツ選択などのイベントに関連付けられ得る。
のアクションをもたらす期間タイマー、データベースの更新などを含み得る。
かの実施形態では、本明細書で説明するように、スタンバイコンテナまたは他の仮想コンピューティングリソースのプールには、すべての関連する非サイト固有コードが提供され得るが、ユーザ固有またはサイト固有コードは提供されない。次いで、本システムは、特定のウェブサイトに関するサーバへの要求をライブポートでリッスンし得る。特定のウェブサイトに関連付けられたライブコンテナまたは他の仮想コンピューティングリソースがある場合、本システムはそれに接続し得る。それ以外の場合、本システムは、プールのスタンバイコンテナを使用し、要求されたサイト固有のコンテンツをプールに投入してもよいし、そのようなコンテンツをロードするようにプールに命令してもよい。所与のサイトのサイト固有のコンテンツがロードされると、コンテナは所与のサイトに関連付けられたコンテナのプールに加わる。本明細書で説明するように、投入されたサイトレベルのコンテンツは、実際のサイトページを含んでも含まなくてもよい。そのようなサイトページ情報は、例えば、実際のブラウザ対応ページマテリアル(例えば、HTML、CSS、およびJavaScript(登録商標)コードのコレクション)、クライアントサイドもしくはサーバサイドのコード(WBSビューアモジュールなど)によりブラウザ対応マテリアルに変換される基礎となるサイト定義データ(例えば、XMLファイルまたはJSON表現を使用する)、またはフロントエンドもしくはバックエンドコード(例えば、クライアント、サーバ、またはその両方で実行するためにページによって呼び出されるJavaScriptコード)であり得る。
ドシステム800と連携し得るが、エディタ自体がオンデマンドシステム800の上位のレイヤとして機能でき、その機能および決定(例えば、到来する要求を処理するための実行インスタンスの割り当て)に直接影響しないことを明確にしておきたい。
用ウェブサイトサーバコード824を有し得る。これはまた、例えば、同じ垂直マーケットアプリケーションフレームワーク(例えば、レストランやホテル)に基づいた複数のサイトにも適用され得る。あるいは、異なるウェブサイトが独自の汎用ウェブサイトサーバコード824を持っていてもよく、これは、各ウェブサイト内のすべてのウェブページに関連し得る。
様のウェブサーバ実行インスタンスにコピーされ得る。このようにして、汎用ウェブサイトサーバコード824ならびに任意のウェブサイト固有コード833〜834は、共通システム、ウェブフレームワーク、ライブラリ、コンポーネントおよびプラグイン、ならびに個別化された要素を含むウェブサイトまたはページを提供するために組み込まれ得る。
様に、以前の使用情報に基づいた上述のような予測を使用して、予想されるトラフィックが少ない場合にインスタンスをシャットダウンできる。ウェブサーバ実行インスタンスマネージャ950は、プロキシサーバ840に判定を委譲することにより、利用可能なインスタンス822セットにより多くのインスタンスを追加する、および/または使用中のインスタンス821のインスタンスを非アクティブとしてマークする判定を行うことができる。プロキシサーバ840は、上記のように、使用中のインスタンス821および利用可能なインスタンス822からウェブサーバ実行インスタンスを追加するか除去するかを判定するのに役立つ状態テーブル941を含むことができる。状態テーブル941は、特定の使用中のインスタンス821および利用可能なインスタンス822をそれらの現在のステータス、履歴ステータス、または予測される将来のステータスに関連付ける情報を維持し得る。このようなステータス情報は、ホストしている、将来ホストする可能性がある、または過去にホストした特定のウェブサイトまたはページを識別し得る。さらに、状態テーブル841は、さらなる情報(例えば、使用中のインスタンス821および利用可能なインスタンス822がウェブサイトまたはページをホストしている時間、使用中のインスタンス821および利用可能なインスタンス822が非アクティブである時間など)を含み得る。
る。オンデマンドシステム800は、要求されているウェブサイトまたはページが、使用中のインスタンス821の1つまたは複数のウェブサーバ実行インスタンスによって現在処理されているか否かを確認することにより、要求を処理する。上述のように、これは、使用中のインスタンス821自体の問い合わせ、プロキシサーバ840の問い合わせ、または使用中のインスタンス821を監視する別のサービスからのレポートの取得を含み得る。ルックアップテーブルまたは状態テーブルを参照することにより、使用中のインスタンス821の現在の動作(またはその欠如)を確認することもできる。いくつかの実施形態では、単一のサーバが複数のウェブサイトまたは同じサイトの複数のクライアントにサービスを提供し、特定のサーバへのトラフィック負荷およびアクティビティが追跡され、追加の要求に応答するために使用するサーバを判定する際に考慮される。
マネージャ950は、要求の処理に失敗した後、ウェブサイト123に関する要求を転送して、ウェブサイト123に関する要求を処理するウェブサーバ実行インスタンスが利用可能でないことを指示する。
要求を開始するクライアントコードは、追加のパラメータまたは情報をネットワーク要求に追加して、投入モジュールがそのような適応を実行できるようにする。追加情報は、直接(例えば、追加されたURLまたは他の要求パラメータとして)または間接的に(例えば、追加要求、データベースへの事前の格納、または他の方法を介して利用可能)追加され得る。
たはプロセス1223を介して複数のウェブサイトを提供できる。いくつかの実施形態では、ウェブサーバ実行インスタンス826は、それに専用のまたは利用可能な1セットのコンテナ1221、仮想マシン1222、およびプロセス1223のリソースを有することができる。複数のコンテナ1221、仮想マシン1222、およびプロセス1223は、複数のウェブサイトを提供できる。いくつかの実施形態では、複数のウェブサイトを提供するウェブサイト実行インスタンス826の変形は、複数のウェブサイトを提供し得る単一のコンテナ1221、仮想マシン1222、またはプロセス1223を含むことができる。複数のウェブサイトを提供するコンテナ1221、仮想マシン1222、およびプロセス1223は、複数のウェブサイトのサイト固有コードをコピーして、様々なウェブサイト要求を処理する必要がある。
00によりホストされるウェブサイト1311へのアクセス要求の数に基づいてプロキシサーバ840により定期的に更新される。負荷監視部1310の負荷テーブルは、他のウェブサイトの使用統計に基づいて更新され得る。例えば、マルチメディアが多いウェブサイトの場合、使用統計情報には、ユーザにより使用されるデバイスの環境に基づいてビデオおよびオーディオを異なる形式に変換することを含むウェブサイト要求を処理するメモリおよびプロセッササイクルの使用量が含まれ得る。使用中のインスタンス821のウェブサーバ実行インスタンスは、ホストしているウェブサイトの負荷が軽くなると、利用可能なインスタンス822に移動される。同様に、ウェブサイトの負荷が大きくなると、利用可能なインスタンス822のウェブサーバ実行インスタンスは使用中のインスタンス821とマークされ、負荷の大きいウェブサイトのウェブサイト固有コードがこれらのウェブサーバ実行インスタンスに投入される。
ウェブサイトおよびそのデータにアクセスできる。開発者/設計者1540は、ウェブサイト開発デバイス140上のウェブブラウザ141を介してウェブサイト123にアクセスできる。いくつかの実施形態では、開発者/設計者1540は、ウェブ閲覧デバイス130上のウェブブラウザ131を使用することにより、デプロイ環境1510内のウェブサイト123にアクセスすることができる。ウェブ閲覧デバイス130と開発デバイス140とは同じデバイスであってもよいことに留意されたい。
スするすべての要求は、最初にテストデータ1620に送信され得る。テストデータ1620は、ライブデータ1610に要求を転送する前に、テストデータ1620自体で処理され得るデータ要素アクセス要求を除外することができる。
する方法2000を示すフローチャートである。
ストされているウェブサイトに関連付けられたデータ要素にアクセスする要求の種類を判定する。この判定により、様々な種類の要求が処理される。データ要求は、開発者/設計者1540がURLを入力してインデックス可能なウェブページを要求した場合に、開発者/設計者1540によりテストされているウェブサイトに関連付けられたデータ要素にアクセスする読み出し要求であり得る。いくつかの実施形態では、データ要求は、データ要素を追加するための書き込み要求であり得る。例えば、ウェブサイト123をテストする開発者/設計者1540は、データグループ210に追加する新しいデータ要素の作成を要求するインデックス可能なウェブページ125上でフォームを送信できる。データ要求は、開発者/設計者1540によってテストされているウェブサイトに関連付けられたデータ要素のコンテンツを変更する更新要求であり得る。データ要求は、開発者/設計者1540によってテストされているウェブサイトに関連付けられたデータ要素を除去する削除要求であり得る。
5にアクセスする開発者/設計者1540は、テストデータ1620の削除済みとしてマークされたデータ1740のデータ要素1741に関する要求を送信して、「データ要素が見つかりません」というメッセージを返すことができる。
たと追加の列にマークを付けることを含む。テスト環境1620からテストデータ1620の挿入済みとしてマークされたデータ1730に挿入されたデータ要素には、デプロイ環境1610での要求ではアクセスできない。例えば、開発者/設計者1540によるウェブサイト123を介してのデータ要素1752を更新する要求により、データ要素1732がテストデータ1620の挿入済みとしてマークされたデータ1730に挿入される。
ための方法2400を示すフローチャートである。図24に示すように、削除が要求されたデータ要素は、ライブデータ1610に提示されてもよいし、テスト環境を介して以前に追加されていてもよく、挿入済みとしてマークされたデータ1730に存在する。
合、ランダムな列が選択され、昇順または降順で並べ替えされる。いくつかの実施形態では、並べ替えに使用される列に主キーが追加される。
る最も若いデータ要素2550を持つ。
実施形態では、実際のウェブページのそれぞれは、データベースを更新する機能を備えて設計されていないが、仮想ウェブページはその機能を備えて設計されていてもよい。例として、ホテル予約サイトは、特定のホテルで利用可能な5つの異なるタイプの部屋(シングルベッド、ダブルベッドなど)のための5つの異なる仮想ページテンプレートを維持することができる。仮想ページテンプレートのそれぞれを、独自のデータ要素グループ(すなわち、所与のタイプの部屋のためのレコード)に関連付けることができ、よって、各部屋は、プレビューモード中に仮想ウェブページとして表示可能および編集可能であり得る仮想ウェブページを有し得る。
構成可能である。ウェブページのそれぞれは、データ要素を格納するデータベースから異なるデータをプルするように構成され得る。例えば、JavaScriptの実装では、ウェブページに関する到来する要求が、要求に関する情報(例えば、URL、どこから到来したか、誰から到来したかなど)を含むオブジェクトに関連付けられ得る。ソフトウェアベースのルータは、この情報を処理し、表示するウェブページ(場合により仮想ウェブページ)とそれに含めるデータ要素を決定できる。
、データベースにおけるデータおよびコンテンツの収集および格納、動的ページの作成、ユーザに相対するウィジェットおよびアプリの実装、データ要素のレイアウトの繰り返し、ソフトウェアベースのルータの構成などに関連し得る。いくつかの実施形態では、ステップ2622において、スケルトンコードセグメントが生成されて、ウェブページに関連付けられたコードに対するユーザ編集を容易にし得る。例えば、スケルトンコードは、より粒度の細かいソースコードに関連付けられた機能の高レベルの抽象化であってもよく、これは、ウェブページに上記の様々な種類のフロントエンドおよびバックエンド機能を実装できる。スケルトンコードは、編集インターフェースを介してユーザに表示されてもよく、ユーザがこれを編集することができる。次いで、スケルトンコードに対するユーザ編集は、個々のウェブページに関連付けられたより粒度の細かい実際のコードの編集に変換され得る。上記のページ属性およびページデータ/フィールドコンテンツの編集に関しては、システムは、ウェブページテンプレート2704(サイトエリアデータベース124に格納され、公開前の開発変更のサンドボックス化の対象となり得る)または仮想ページインスタンス(仮想ページインスタンス適応データベースに格納され得る)に対する編集をサポートし得る。これについては、以下のステップ2630および2634の説明でさらに詳しく説明する。
ドに対するこのような編集は、仮想ウェブページのデータ要素をホストする同じデータベースまたは別のコードデータベースに格納され得る。
わち、所与のウェブページテンプレート2704のインスタンス)との両方を表示するために使用され得る。プレビューインターフェース3010で閲覧するために生成された仮想ウェブページには、ナビゲーションインターフェース242が付随してもよい。プレビューインターフェース3010により、ナビゲーションインターフェース242がスクロール可能な機能を含むことができて、ユーザが、プレビューインターフェース3010で表示するために生成された複数の仮想ウェブページにわたってスクロールできる。ナビゲーションインターフェース242は、シーケンシャルナビゲーションおよび特定の仮想ウェブページへの直接アクセスの両方、ならびに検索による(例えば、特定の仮想ページを識別するために使用されるキーデータ項目の値を使用することによる)仮想ページ間のナビゲーションを可能にし得る。ナビゲーションインターフェース242は、特定の仮想ウェブページに直接アクセスすることができ、選択的に閲覧するためにブックマークされた仮想ウェブページをサポートすることができる。例えば、プレビューインターフェース3010に表示されている仮想ウェブページは、最初、最後、前または次の仮想ウェブページへのリンクを伴う場合がある。WBS100はまた、単なる直線的な構成だけでなく、仮想ページの他の構成もサポートしてもよい。例えば、WBS100は、「ツリーの上のレベルに移動する」または「現在のページより下のレベルを展開する」などの追加オプションを使用してナビゲートされ得る仮想ページの階層構成をサポートすることができる。
する。リピータは、データグループ210のデータグループサブセット3213に直接関連付けられ得る。例えば、リピータを使用して、テキストおよび画像の5つの異なるグループを作成できる。各グループは、同じ比率およびレイアウトでテキストおよび画像を自動的に配置できる。それにもかかわらず、いくつかの実施形態では、テキストおよび画像の実際のコンテンツは、各グループで異なり得る。
オンラインエディタインターフェース243を表示するウェブブラウザにさらなる命令を提供することができる。このようにして、既存のグループを補足または編集して、異なるまたは追加の要素を含めることができる。ユーザはステップ3420を繰り返すことができ、いつでも戻ってデータ要素をさらに追加できる。同様に、このステップは、削除や更新など、データ要素に対して追加の操作を実行するための命令を含み得る。例えば、ユーザはステップ3410、3420、および3430の間を循環することもできるし、ステップ3430に進むこともできる。
13をホストする複数のホスティングサーバ3510にわたって共有されてもよい。
ウェブサイトにアクセスできるが、許可されたグループの一部ではないウェブサイトへのアクセスは許可されていない。ユーザは、例えば、特定のウェブサイトの所有者であるか、登録ユーザであるか、認証されているかなどに基づいて、アクセス権が定義され得る。
できるようにすることにより、安全な通信チャネルが提供される。このようなハブは、例えば、システムクライアント、システムサーバ、またはその両方に常駐することができる。通信を開始するサブ領域の一意の識別子を確認することによっても、安全な通信を確立することもできる。例えば、getId()メソッド呼び出しを使用して、通信メッセージの発信元サブ領域IDを識別し、許可リストまたはマッピングに含まれているか否かを判定できる。
310オプションにアクセスできる。パーミッション4310は、ウェブページのコンテンツ、フォームへのデータ入力、ページのユーザにより生成されたコンテンツ、登録メンバーに限られるコンテンツ、登録メンバーのみが完了できるフォーム、および特定のユーザ(例えば、管理者)のみがアクセスできる特定のプライベートデータに対処し得る。
に対する画像の位置を変更したり、ハイパーリンクを変更したり、フィールドのサイズを変更したりすることにより、これらのインスタンスのレイアウトおよび外観をさらに編集できる。さらに、上述のように、インスタンスの各要素はデータベースの異なる部分に接続できる。例えば、要素4724の3つの組み合わせは、データベースからそれぞれ抽出すべきコンテンツに対応するデータベース内の異なる列にそれぞれリンクすることができる。このようにして、要素4724の3つの組み合わせは共通のレイアウトを有するが、それぞれが異なるテキストまたはグラフィックコンテンツを有する。
登録商標)、C、C++、アセンブリ言語、または任意のそのようなプログラミング言語、ならびにデータ符号化言語(XML、JSONなど)、クエリ言語(SQLなど)、プレゼンテーション関連言語(HTML、CSSなど)およびデータ変換言語(XSLなど)を使用して設計され得る。そのようなソフトウェアセクションまたはモジュールのうちの1つまたは複数を、コンピュータシステム、非一時的なコンピュータ可読媒体、または既存の通信ソフトウェアに組み込むことができる。
ウェブサイトホスティングおよびウェブサイト構築システムのためのオンデマンドウェブサーバ実行インスタンス
もくじ
ウェブサイトおよびステートレスサービングアーキテクチャ 1
本発明のシステム 2
従来のシステムおよび本発明のシステムのユースシナリオ 3
WBSコンテキストにおける本発明のシステムの使用 5
使用されている頭字語 6
1.ユーザがウェブサイトと対話する場合、ユーザは、通常、BEコードやウェブサーバとやり取りするのではなく、クライアントサイドページ、ウェブアプリケーション、およびクライアントマシン/ブラウザで実行されるFEコードと多くの時間対話する。しかしながら、このクライアントサイドのウェブサイト/アプリケーションは、依然として複数のHTTP(または他の)サーバ要求を行う。これらには、例えば次のものが含まれ得る。
1.1.ページをロードするために行われた最初のHTTP要求。これは、さらなるHTTP要求をトリガして、さらなるページ要素(含まれている画像やスクリプトなど)をロードし得る。
1.2.セッション中のHTTP要求。例えば、フィールドのための値を選択するとき、ページはHTTP要求を行って、所与のフィールドのための1セットの可能な値を取得する。
1.3.ユーザが入力したフォームの送信など、データ関連のHTTP要求。
1.4.BE機能をアクティブ化するBE関連のHTTP要求。これは、ウェブサイトを提供するシステムまたは外部(サードパーティ)ウェブサービスを使用して実行され得る。
2.このコンテキストにおける「サーバ」は、実際の物理サーバを指す場合もあるが、
VMやコンテナ(ドッカーとしても知られる)などの他のウェブサイトサーバ実行インスタンスを指す場合もある。本文書を通して説明されているHTTP要求はまた、HTTPS要求または任意の他のネットワーク要求を指す場合もある。
3.ユーザは、要求を行ってから最初の応答を受信するまでのシステム(クライアント+サーバ+通信媒体)の応答が非常に迅速であることを期待している。応答時間は、多くの場合、「要求を受信してから最初の応答バイトを送信するまでのサーバサイドの時間」として測定される(通常は100ミリ秒以下と期待される)。サーバサイドの時間の測定を用いるのは、変動しやすいネットワーク転送時間を考慮から外すためである。
4.実際に応答を完了するには、かなりのさらなる時間がかかる場合がある。例えば、新しいページをロードするとき、ユーザはブラウザにページがすぐに表示され始めることを期待するが、ページのロードにはかなりのさらなる時間がかかる場合があり、ユーザはページが完全にロードされていなくてもページの操作を開始する場合もある。
5.これらに対してサーバシステム(通常は複数のサーバまたはサーバファームで構成される)は、ステートレスまたはステートフルシステム/プロトコルを使用して応答し得る。HTTPプロトコルは本質的にステートレスであるが、ステートフルサーバの使用はプロトコル外の技法(URLの書き換えや非表示のフォームフィールドなど)を使用して実装され得ることに留意されたい。
6.ステートフルシステムは、通常、クライアントが事前に割り当てられたサーバとやり取りするときに使用される。このようなサーバは連続的なセッションコンテキストを提供できるが、この構成をスケールアップするのは非常に困難である。なぜなら、サーバが(1人または複数の)ユーザに連続的に関連付けられている必要があり、次のHTTP要求の到着を待機してアイドル状態または部分的にアイドル状態になり得るためである。
7.ステートレスシステムでは、各HTTP要求は、単一のページからのものでさえも、異なるサーバ(またはサーバ実行インスタンス)によって処理され得る。異なるHTTP要求に対する異なるサーバ間での「ジャンプ」はユーザに気づかれることはなく、これらの異なるサーバは、応答に必要な外部リソース(データベースサーバなど)に透過的にアクセスできる。
8.ステートレスシステム、すなわちステートレスサーバを使用するシステムには多くの利点がある。特に、到来する要求はシステム内の任意の(ステートレス)サーバに差し向けられるために、システムは高度にスケーラブルであり、切れた接続に対して特別な処理を行う必要はない。
9.既存のシステムの(複数の)ステートレスサーバは完全に交換可能である必要があるため、特定のウェブサイトまたは関連するページに適合させることはできない。よって、このような構成は、単純で静的なウェブサイトに適している。サイト固有のBEコード(場合によりユーザ提供コードを含む)、サイト固有のコンポーネント、またはサイト固有のプラグインを必要とする複雑なウェブサイトを提供する場合、この構成はうまく機能しない。
10.本明細書で説明されるように、本発明のシステムは、(サイトのための特定のプラグインおよびサーバサイドのユーザ提供コードを含む)特定のサイトのために構成されたウェブサーバインスタンスを実行し、かつこの実行を、タイムアウトなしで、またユーザが許容できる合計時間枠内でHTTP要求に応答するのに十分な速さで行う、ドッカーコンテナ(またはウェブサイトサーバ実行インスタンス)の高速ブートを含む。
11.通常、新しい仮想マシンの起動には数分かかる。新しいドッカーコンテナの起動には依然として2〜3秒かかる。これらの時間は両方とも許容可能ではない。
12.本開示のシステムでは、すべての関連するサイト固有ではないコードを含むが、ユーザ/サイト固有のコードを含まないスタンバイコンテナのプールが提供され得る。
13.本システムは、特定のウェブサイトのためのサーバに接続する要求をライブポートでリッスンし得る。特定のウェブサイトに関連付けられているライブコンテナがある場
合、本システムはそれに接続し得る。それ以外の場合は、上記プールからのスタンバイコンテナを使用し、要求されたサイト固有のコンテンツをプールに投入するか、そのようなコンテンツをロードするように命令することができる。所与のサイトのためのサイト固有のコンテンツがロードされると、コンテナは所与のサイトに関連付けられたコンテナのプールに加わる。
14.このようなステートレスコンテナインスタンスは、HTTP要求をロードしている元のページを処理したインスタンスとなることなく、特定のHTTP要求(例えば、データ確認を含む)を処理することができることに留意されたい。
15.投入されたサイトレベルのコンテンツは、実際のサイトページを含んでいても含んでいなくてもよい。このようなサイトページ情報は、例えば次のとおりであり得る。
15.1.実際のブラウザ対応のページマテリアル(例えば、HTML、CSS、およびJSコードのコレクション)。
15.2.クライアントサイドまたはサーバサイドのコード(WBSビューアモジュールなど)によってブラウザ対応マテリアルに変換される基礎となるサイト定義データ(例えば、XMLファイルまたはJSON表現)。
15.3.フロントエンド/バックエンドコード、例えば、クライアント、サーバ、またはその両方で実行するためにページによって呼び出されるJavaScriptコード。
16.サイトが所与の期間(15分など)アクティブでない場合、本システムはスタンバイコンテナをドロップし得る。
17.ユーザの状態を保持し、ユーザが(連続的なコンテキストを有する)単一のセッション内で作業しているというユーザの感覚を保つために、クライアントサイドストレージ(例えば、ブラウザのローカルストレージ、クッキーなど)とサーバサイドのストレージ(例えば、サーバDBへの保存)との組み合わせを使用して永続的コンテキストが保持される。
18.次の典型的なユースシナリオを仮定する。
18.1.ユーザがブラウザにURLページを入力し、ページのロードを要求する。ロードされたページは、データ入力フォームを含み、かなりの量の関連する(サイトレベル固有の)FEおよびBEコードを有する。ページおよびそのサイトレベルで関連付けられたFEコードを取得するために、HTTP要求がサーバに対して行われる一方で、BEコードはサーバにロードされるが、クライアントには送信されない。サイトはまた、独自のUI、FEコード、およびBEコードを持ついくつかのコンポーネント(ディスプレイウィジェットなど)を使用する。
18.2.ユーザは10分間にわたってフォームに入力し、通常、<form>HTMLタグを有するローカルページを実行するブラウザでローカルに作業する。これはまた、Ajax呼び出しまたはFetch呼び出し、またはHTTP要求を開始できるJavaScriptもしくはHTMLセットアップを使用して行うこともできる。
18.3.フォームは、サーバに送信されるいくつかの要求をこの間に行い得る(例えば、所与のフィールドに関するDBからの許可された値のリストを取得する)。これらの要求のそれぞれが、実際のDBアクセスおよび情報収集を行うサーバサイドBEスクリプトをアクティブにする(例えば、コード内のDBアクセスクレデンシャルをクライアントに送信することを回避するため)。このような要求は、HTTP要求として実装されてもよいし、異なるメカニズムを使用して実装されてもよい。
18.4.ユーザがフォームを送信すると、フォームはFEスクリプトによって確認される。次いで、フォームはサーバに送信され、関連するBEコードを実行するサーバプロセスをアクティブにし、これにより(例えば)フォームがデータベースに保存され得る。
19.上記のシナリオでは、ユーザのアクティビティは、HTTP要求または他のメカ
ニズムを使用して、10分間にわたる間に(例えば)20個の要求を生成し得る。これらの要求の多くは、サイト固有のBEスクリプトまたはコンポーネント固有のBEスクリプト(サイトで使用されるコンポーネント用)をアクティブにする。
20.従来のステートレス/ステートフル技術は、このシナリオを次のように処理する。
20.1.ステートフルサーバを使用する場合、場合により中間要求(上記の「フィールドXのための値のリストを取得する」など)を処理することを除いて、何もしていなくても、10分後になる場合がある記入を終えたフォームの送信まで、フォームを含むページを最初に提供したサーバは実行し続けなければならない。
20.2.従来のステートレスサーバ技術は、(所与のサイトに固有のコードを含む)特定のHTTP要求ごとにサーバを、またはVMやコンテナでさえも適時にコールドスタートすることはできなかった。よって、特定のBE機能を持たないサイトをサポートするか、フォーム入力セッション中ずっと特定のサーバインスタンスを実行し続けなければならなかった(よって、実際にはステートレスではない)。
21.本発明の技術を使用すると、ステートレスサーバインスタンス(例えば、コンテナ)が割り当てられて、特定のHTTP要求のそれぞれ(ページのロード、フィールドXのための値のリストの取得、記入されたフォームのDBへの保存)を処理する。これにより、サーバ時間の使用量が、10分間のフォーム入力セッションの間中である代わりに、(例えば)20個の要求処理時間(例えば、20×200ミリ秒=4秒)になる。割り当てられたサーバは、(サイト固有の要素が投入された)新しいコンテナまたは既存の利用可能なサイト適応コンテナであり得る。
22.よって、同じユースシナリオにおいて、本発明のシステムでは、使用するサーバリソースを従来のシステムよりも大幅に少なくでき、サーバを必要とするのは10分ではなく(10分のほとんどの時間、サーバインスタンスはアイドル状態であるが、特定のユーザからの要求を依然として待機している)4秒だけである。
23.これにより、ウェブサイトホスティングプロバイダは、非常に少量のリソース(サーバ、コンテナなど)を使用して同じレベルのサービスを提供できる。
24.ちなみに、ユーザはフォームに対してローカルで作業しているため、ユーザがブラウザウィンドウを閉じて再び開くと、通常は(部分的に入力されたフォームではなく)空のフォームが表示される。本発明のシステムは、フォームのコンテンツをブラウザのローカルストレージに保持できるAPIを提供し得る。よって、ユーザが部分的に入力されたフォームウィンドウを閉じて再び開くと、再び開かれたフォームには以前に入力された値が含まれる。これはまた、ブラウザが完全に閉じている場合にも機能する。
25.同様に、BEタスクは、例えば、(サーバサイドの)サーバDBにコンテキスト情報を保存することにより、またはクライアントにより維持され、かつ後続のBE呼び出しに渡される情報を提供することにより、相互にコンテキスト情報を依然として提供できる。このような情報は、セッション期間のみであっても、(例えば、ブラウザのローカルストレージを使用して)必要に応じて存在し続けるのであってもよい。
26.また、特定のコンポーネントコードおよび関連するFE/BEスクリプトの投入は、通常、特定のページレベルの粒度ではなくサイト全体(すなわち、サイト内のすべてのページで使用されるすべての特別なコンポーネントおよびスクリプト)に対して行われることにも留意されたい。このように、このサイトに関する新しいHTTP要求が(同じユーザまたは他のユーザから)到着するたびに、投入されたコンテナがサイト内のあらゆるページで再利用され得る。
27.しかしながら、本システムは、一方では投入される「マテリアル」の量に応じて、他方ではその使用パターンに応じて、異なるレベルの粒度を実装し得る。よって、本システムは、(例えば)ページ、ページグループ(すなわち、サイトセクション)、サイト、またはサイトグループの投入粒度レベルを実装し得る。例えば、多数のサイトが非常に類似しており、共通の関連コンポーネントおよびスクリプトを使用する場合、サイトグループのケースが関連し得る。このように、サイトグループに固有のコンテンツが投入され
たコンテナを再利用して、1つのサイトだけでなく、グループ内の任意のサイトへの要求を処理できる。
28.オンラインWBSは2つの使用モードを有することを特徴とする。
28.1.サイトの編集−サイト定義(例えば、XML/JSONデータ、またはDBレコード、または実際のHTMLページマテリアル)は、通常、サーバサポートのあるブラウザで実行される視覚的エディタアプリケーションによって編集される。このようなサイトは、FEコードおよびBEコード(エディタで編集可能でもあり得る)、ならびにサイトに必要な特定のコンポーネント(例えば、サードパーティアプリケーション)を含み得る。エディタはまた、プレビューモードでサイトを呼び出すこともできる。エディタはまた、外部ユーザが使用するためにあるバージョンのサイトを公開する公開操作もサポートし得る。
28.2.RT(ランタイム)モード−必要に応じてFEまたはBEコードをアクティブにしながら、システムがユーザに公開されたサイトを提供する。
29.上述の本発明のシステムは、システムの編集モードおよびRTモードの両方で使用され得る。
30.編集モードで動作する場合。
30.1.編集されたサイトコンテキストは以下を含む。
30.1.1.完全なサイト定義(ページ、コンポーネント、および関連データ)は、通常、エディタクライアントによってクライアントサイドのメモリ内構造として保持される(例えば、JSON表現として)。
30.1.2.サイトのFEコード。
30.1.3.サイトのBEコード。
30.2.実際のエディタコード(クライアントにロードされるエディタFEコードおよびサーバで実行されるエディタBEコード)は、システムの(コンテナにプリロードされた「一般セクション」における)一般的なコードの一部である。
30.3.サイトのJSON/FEサイトコード/BEサイトコードはDBに保持される(ユーザが明示的に保存する場合)。
30.4.FE/BEコードの一時的な保存は限られているため、ユーザは「移動」先のコンテナを介して同じコードの編集を続行できる。このことは、サイトのFE/BEコードはサイトのJSONコードの一部ではないために必要とされる。
31.プレビューを実行するときに使用することができ、さらにエディタが(大きい場合がある)サイトコード全体をロードしなくてもよいように、サイトコードはDBに保持されるが、編集中または現在のページに関連する関連セクションのみであることに留意されたい。
32.ランタイムモードで動作する場合、本システムは通常のウェブサイトの提供について上述したように動作する。WBSは、(WBSで編集されるすべてのサイトで必要とされる)ビューアモジュールを有することができ、このようなモジュールは、起動されたサーバ/コンテナインスタンスにプリロードされたシステムの一般的なコードの一部である。
33.よって、本発明のシステムは、編集およびRTの両方でWBSにより使用され得る。
BE:バックエンド
FE:フロントエンド
VM:仮想マシン
WBS:ウェブサイト構築システム
サイト構造サイドバーを使う
Wixコードリソースセンターにアクセスし、さらに学びましょう。
サイト構造サイドバーには、ページ、ライトボックス、ファイル、データベースコレクションなど、サイトを構成するすべてのファイルが表示されます。このサイドバーを使用すると、以下に詳述するように、サイトに影響を与える様々なアクションを実行できます。
・サイドバーを非表示にするには、エディタの左下にある非表示アイコンをクリックします。
・サイドバーを表示するには、エディタの左下にある表示アイコンをクリックします。
サイドバーのページセクションには、サイトの通常ページ、動的ページ、およびルータページのすべてが一覧表示されます。通常ページは、ページセクションのタイトルのすぐ下に表示されます。動的ページおよびルータページはサブグループに表示されます。
サイトの通常ページは、ページセクションのタイトルのすぐ下に表示されます。ページの設定を変更するには、ページ名にカーソルを合わせると表示される設定アイコンをクリックします。サイトのホームページ以外の任意のページを動的ページとして設定できます。
新しい動的ページをグループに追加するには、セクション名にカーソルを合わせると表
示される設定アイコンをクリックします。
URLやSEOデータなどのページの設定を変更するには、動的ページ名にカーソルを合わせると表示される設定アイコンをクリックして、動的接続を除去して動的ページを通常ページにするか、動的ページを削除します。
ルータを作成してある場合、そのルータのプレフィックスに関連付けられているすべてのページが一緒に同じセクションにグループ化されます。例えば、myrouterというプレフィックスでルータを作成した場合、セクションの名前はMyrouter Pages(Router)になります。
個々のルータページには、ルータのコードで使用されるデフォルト名が付けられます。必要に応じて名前を変更できます。ページ名はページ訪問者には見えません。
ルータのプレフィックスおよびrouters.jsファイルに実装されている関連する関数の名前を変更するには、または新しいページをルータに追加するには、ルータセクション名にカーソルを合わせたときに表示される設定アイコンをクリックします。
ページの設定を変更したり、名前を変更したり、削除したり、ルータから除去して通常のページにするには、ルータページ名にカーソルを合わせたときに表示される設定アイコンをクリックします。
新しいルータを追加するには、ページセクションヘッダにカーソルを合わせると表示されるプラスアイコンをクリックします。
サイトのページにライトボックスを追加してある場合、サイドバーのライトボックスセクションに表示されます。このセクションは、サイトに少なくとも1つのライトボックスを追加した場合にのみ表示されます。
新しいライトボックスを追加するには、エディタの[追加]メニューを使用します。
サイドバーで既存のライトボックスを選択すると、エディタはライトボックスモードに入ります。
サイドバーのパブリックセクションには、サイトからパブリックにアクセスできるファイルが含まれます。パブリックで使用するJavaScriptファイルおよびテキストファイルを作成することができ、これらのファイルをフォルダに整理できます。ページおよびサイトコードもパブリックにアクセス可能ですが、パブリックセクションには表示されません。
ページおよびサイトコードを編集するには、コードパネルを使用します。
新しいファイルまたはフォルダをパブリックセクションに追加するには、セクション名にカーソルを合わせると表示されるプラスアイコンをクリックします。
新しいファイルや新しいフォルダを追加したり、フォルダを削除したりするには、フォルダ名にカーソルを合わせると表示される設定アイコンをクリックします。
ファイル名を変更したりファイルを削除したりするには、ファイル名にカーソルを合わせると表示される設定アイコンをクリックします。
サイドバーのバックエンドセクションには、サイトからパブリックにアクセスできないファイルが一覧表示されます。バックエンドセクションは、サーバサイドで実行するコードを配置する場所です。バックエンドで使用するJavaScriptファイル、ウェブモジュール、およびテキストファイルを作成することができ、これらのファイルをフォルダに整理できます。
サイトのバックエンドセクションには、2つの特別なJavaScriptファイルが存在する場合があります。data.jsファイルにはデータフックのためのコードが含まれ、routers.jsファイルにはルータおよびデータバインディングルータフッ
クのためのコードが含まれます。
新しいファイルまたはフォルダをバックエンドセクションに追加するには、セクション名にカーソルを合わせると表示されるプラスアイコンをクリックします。
新しいファイルや新しいフォルダを追加したり、フォルダを削除したりするには、フォルダ名にカーソルを合わせると表示される設定アイコンをクリックします。
ファイル名を変更したりファイルを削除したりするには、ファイル名にカーソルを合わせると表示される設定アイコンをクリックします。
新しいコレクションを追加するには、セクション名にカーソルを合わせると表示されるプラスアイコンをクリックします。
コレクションに基づいて新しい動的ページを追加したり、コレクションのパーミッションを更新したり、コレクションを除去したりするには、コレクション名にカーソルを合わせると表示される設定アイコンをクリックします。
動的ページについて
ライトボックスについて
データベースコレクションについて
ルータについて
データバインディングルータフックについて
コードパネルを使う
・Wixコードリソースセンターにアクセスし、さらに学びましょう。
・この記事を全画面表示するにはここをクリックしてください。
エディタの下部に表示されるコードパネルでサイトのコードを編集します。コードパネルには、特別なツールバーとサイトの様々な要素のためのコードを含む2つのタブとがあります。また、コードを使用する方法や場所に応じて、いずれかのタブに任意の他のコードを追加することもできます。
ヒント:
コードパネルをページの下部から上にドラッグするだけで開くことができます。
エディタ内の要素は、特定のページまたはサイトのすべてのページに表示できます。特定のページのみに関連するコードを追加することも、すべてのサイトページに関連するコードを追加することもできます。コードパネルの左側にはページおよびサイトの2つのタブがあります。
・ページ:ページタブには、特定のページに表示される要素のためのコードが含まれています。プロパティパネルを使用して要素にイベントを追加すると、そのイベントのコードは自動的にページタブに配置されます。特定のページのみに関連するコードがある場合は、ここに追加します。
・サイト:ある要素がすべてのサイトページに表示され、サイト全体で一貫性のある機能をその要素に対して追加するには、そのコードをサイトタブに追加します。プロパティパネルを使用してすべてのページに表示される要素にイベントを追加すると、そのイベントのコードは自動的にサイトタブに配置されます。サイトのすべてのページに関連するコードがある場合は、ここに追加します。
すべてのページに表示される要素があり、1つのページに固有のコードをその要素に対して追加する場合は、そのページのページタブにコードを追加します。
特定の要素を選択する
Wixコードでは、標準のJavaScriptを使用してコーディングできます。また、Wixコードには、ページ上の要素を選択するための特定の構文または規則のセットがあり、それは次のとおりです。
jQueryをご存知であれば見慣れたものであるはずです。ご存知でなくても、知っておくべきなのは次のことになります。
要素を選択するには、
1.$wと入力します。
2.要素名を括弧および引用符で囲みます。
3.要素名の前にハッシュタグを付けます。
注意:
引用符は、単一引用符も二重引用符も使用できます。
//すべきこと:ページに関連するコードをここに記述します。
上下の矢印キーを使用して目的の要素を選択し、Enterキーを押します。あるいは、リスト内の要素をクリックすることもできます。要素への参照は、必要なすべての構文と共にコードに追加されます。
ヒント:
・Ctrl+スペースを押せばいつでもコード補完ポップアップを表示できます。
・要素名では大文字と小文字とが区別されます。「#Button1」は「#button1」と同じではありません。
・パブリックにnew.jsファイルを追加すると、最後にアクセスしたページの要素がコード補完によりリストされます。
要素名を見るには、要素にカーソルを合わせるか要素を選択します。プロパティパネルで任意の要素の名前を変更できます。
名前で複数の要素を選択するには、上記と同じ構文を使用して要素を参照し、次のよう
に各要素をカンマで区切ります。
特定の種類のすべての要素を選択するには、次のように、ハッシュタグなしで要素の種類名を使用します。
要素の種類名は、WixコードAPIに表示される要素名です。
Wixコードに直接関連するオートコンプリートに加えて、コードパネルには標準のJavaScriptテンプレートおよびキーワードのためのオートコンプリートも含まれています。例えば、「for」という単語を入力すると、オートコンプリートリストには「for文」のテンプレートおよび「for」というキーワードが含まれます。各テンプレートには、標準JavaScript APIへのリンクが含まれており、そこで詳細な情報を参照できます。
JavaScriptテンプレートを選択すると、テンプレートの完全な構文がコードパネルに追加されます。例えば、「for文」を選択すると、次のテンプレートがコードに追加されます。
後は、ループ内で実行するコードを追加するだけです。
>onReadyに関する高度な情報
ページがブラウザに読み込まれると、ページの読み込みが終わる前にページのコードが実行される場合があります。その場合、ページが読み込まれる前にコードがページ内の要素を参照しようとしたときにエラーが発生する可能性があります。
//すべきこと:ページに関連するコードをここに記述します。
これが必要になるのは、$wセレクタを使用して独自にコードを追加する場合だけです。プロパティパネルを使用して関数に追加したコードは、ページが読み込まれた後にのみ実行されます。
エディタ内のすべての要素には、プロパティ、メソッド、およびイベントハンドラがあり、これらを使用して、要素を使ったり、サイトに機能を追加したりできます。
要素を選択した後にピリオドを入力すると、これらのアイテムの全一覧が表示されます。
//すべきこと:ページに関連するコードをここに記述します。
上下の矢印キーを使用して目的のアイテムを選択し、Enterキーを押します。必要な構文が要素セレクタの後に追加されます。オプションの下には、機能の簡単な説明が表示されます。「続きを読む」リンクをクリックすると、さらなる情報が表示されます。
オートコンプリートポップアップには、要素で呼び出すことができる標準のJavaScriptメソッドも含まれています。
プロパティには、要素に関する情報が含まれています。これらの一部は読み取り専用ですが、値を設定できるものもあります。
例えば、テキスト要素にはisVisibleプロパティがあり、要素が実際に画面上に表示されるか否かを返します。このプロパティは読み取り専用です。テキスト要素には、テキスト要素の現在のテキストを含むtextプロパティもあります。これは、読み取りおよび設定の両方が可能なプロパティです。
メソッドは、要素に対してアクションを実行します。
例えば、ボタン要素には、サイトにボタンが表示されないようにするhideメソッドがあります。
一部のメソッドには、アクションの発生の仕方に影響する追加オプションがあります。例えば、次のように括弧内で指定することにより、hideメソッドにアニメーションを追加できます。
ここでも、すべてのオプションを知るには、WixコードAPIを見る必要があります。
イベントハンドラは、要素がユーザアクション(イベント)に応答できるようにします。要素にイベントハンドラを追加する場合、イベントが発生したときに何を実行するかを指定することも必要になります。
例えば、「ツアーに参加する」というボタンがある場合を考えます。訪問者がボタンにカーソルを合わせると、テキストが「さあ行こう」に変わるように機能を追加しようとしています。その場合、次のようなコードをサイトに追加することになります(コードの各部分を説明するコメントを追加してあります)。
//onMouseInはイベントハンドラです。
//コールバック関数はここから始まります。
//これは、イベントが発生したときに実行されるコードです。
//コールバック関数はここで終わります。
プロパティパネルを使用してイベントハンドラを要素に追加することもできることをお忘れなく。イベントハンドラを手動で追加する特別な理由がない限り、プロパティパネルを使用することをお勧めします。
コードパネルでコードを書いているときに、警告やエラーが表示される場合があります。警告は黄色で表示され、エラーは赤で表示されます。これらは、関連するコードの下に色付きの波線が表示される形で、また行番号の左側にアイコンが表示される形を取ります。
警告またはエラーメッセージを表示するには、アイコンにカーソルを合わせます。
コードにおける警告は、変更した方がいいかもしれないコードに注意を促す情報メッセージです。警告はコードの実行を停止することはなく、多くの場合安全に無視できます。警告は黄色の三角形および黄色の波線で引かれた下線で表示されます。
//ここに関数をコーディングします
よくある警告メッセージは「return」の後に不要な「else」がある場合に現れます。これは、次のコーディングパターンを使用する場合に最もよく発生します。
//何かをする
//他の何かをする
someConditionがtrueの場合、関数は戻ります。つまり、someConditionがtrueの場合にコードの実行を停止するのにelseは必要ないということです。
この警告は安全に無視することもでき、コードを次のパターンに変更することもできます。
//何かをする
//他の何かをする
コードにエラーがあるということは、コードが適切に機能しないことを意味します。エラーの種類によっては、コードが期待どおりに機能しなかったり、まったく実行されなかったりする場合があります。サイト訪問者が使用できるようにサイトを公開する前に、コード内のすべてのエラーを必ず修正してください。
次に示すのは、コードにエラーが見つかることがある一般的な状況です。
・エラーメッセージ:「#text1」は有効なセレクタではありません(上の画像を参照)
注意:検索と置換機能を使用して、コード全体にわたってこのエラーを修正できます。
・エラーメッセージ:「インポート」および「エクスポート」は最上位レベルでのみ表示されます。
APIモジュールをインポートする場合、モジュールが使用される前にコードの最上位にimport文が表示される必要があります。つまり、次のように関数内にモジュールをインポートすることはできません。一般的に、あらゆる変数宣言および関数定義の前に、コードの最初の行にすべてのimport文を配置することをお勧めします。
・場合によっては、エラー表示は実際の誤りの箇所で表示されずに、誤りによりエラーが生じる最初の行に表示されます。例えば、ページコードの関数のうちの1つで終わり波括弧(})を忘れた場合、コードのちょうど次の行でエラーが発生する可能性が高くなります。以下に示すコードでは、6行目に終わり波括弧がありませんが、エラーは8行目まで発生しません。
Wixコードでは、Wixメディアマネージャに保存した画像をコードで使用できます。srcなどの画像プロパティを含む要素を使う場合、ポップアップウィンドウが開き、
コードは公開されたサイトで実行されますが、公開する前にコードをテストして、期待どおりに動作することを確認することをお勧めします。
公開する前にコードをテストするには、サイトをプレビューします。サイト内のコードは、プレビューモードでも、公開バージョンとまったく同じように実行されます。公開されたサイトでコードをデバッグすることもできます。
保存すると、対応するコードがサイトのそのバージョンと共に保存されます。サイト履歴に移動して、サイトの保存したバージョンに戻すと、そのバージョンで保存されたコードも復元されます。
WixコードでJavaScriptを使う
Wixコードを使用してコードをテストおよびデバッグする
データベースコレクションについて
Wixコードリソースセンターにアクセスし、さらに学びましょう。
サイトのデータベースはいくつかのコレクションで構成されています。各コレクションは、スプレッドシートのようなデータのテーブルと考えることができます。テーブルの各行は、コレクション内のアイテムを表します。テーブルの各列はフィールドを表します。したがって、各アイテムには、コレクションの列によって定義されるフィールドが含まれます。
例えば、次のコレクションには4つのフィールドおよび5つのアイテムが含まれています。
1.サイト構造サイドバーで、データベースセクション名にカーソルを合わせて、プラスアイコンをクリックします。
2.コレクションに名前を付けます。後で名前を変更できないことにご注意ください。
3.デフォルトでは、「サイトコンテンツ」コレクションパーミッションプリセットが選択されています。これにより、誰でもコンテンツを見ることができますが、作成者だけがコンテンツを追加、修正、および削除できます。ドロップダウンをクリックして、別のプリセットを選択したり、カスタムパーミッションを定義したりすることができます。パーミッションは後で更新できます。
4.完了したら、[コレクションを作成]をクリックします。
データベースのそれぞれのコレクション内には、データのサンドボックスバージョンおよびライブバージョンが存在します。
エディタのコンテンツマネージャでサンドボックスバージョンを編集し、ダッシュボードでライブバージョンを編集します。画面上部の[ライブデータの編集]リンクをクリックすると、ダッシュボードのコンテンツマネージャに移動します。
コレクションの各フィールドには、フィールド名、フィールドキー、およびフィールドタイプがあります。
フィールド名は、コンテンツマネージャの列の先頭に表示されるラベルです。フィールド名は、エディタでページ要素をデータセットに接続するときにも使用されます。
例えば、テキスト要素をコレクションからのフィールドに接続するときは、テキスト接続パネルのフィールド名を使用します。
コンテンツマネージャで新しいフィールドを追加するときに、フィールド名を指定します。フィールドの作成後にフィールド名を変更すると、そのフィールドへのすべての接続が更新されます。
フィールドキーは、データAPIまたはデータセットAPIを使用してコード内のフィールドを参照するときに使用されます。
例えば、データAPIを使用してアイテムを挿入するには、フィールドキーを使用します。
コンテンツマネージャで新しいフィールドを追加すると、フィールド名に基づいてフィールドキーが自動的に作成されます。必要に応じて独自のフィールドキーを指定できます。
重要:
フィールドの作成後にフィールドキーを変更することはできません。
フィールドタイプは、フィールドに含まれるデータの種類を定義します。コンテンツマネージャで新しいフィールドを追加するときに、次のフィールドタイプのうちの1つを選択します。フィールドタイプのサポートおよび制限についてはこちらをお読みください。
・参照
・テキスト
・画像
・ブーリアン
・数値
・日付および時刻
・リッチテキスト
・URL
・文書
フィールドタイプは、コレクションのフィールドにページ要素を接続するときにも使用されます。特定の入力要素は、関連するフィールドタイプのフィールドにのみ接続できます。例えば、テキスト要素をテキストまたはURLフィールドに接続できますが、画像フィールドには接続できません。
コンテンツマネージャでは、間違ったフィールドタイプの新しい値を追加することはできませんが、CSVファイルからインポートされたデータまたはコードを介して追加されたデータは検証されません。例えば、数値フィールドにテキスト値をインポートできます。この場合、コンテンツマネージャにエラーが表示されます。
参照フィールドタイプを使用して、参照コレクションのプライマリフィールドからアイテムを選択します。詳しくは、「参照フィールドを作成するには」を参照してください。
注意:
すべてのデータベースコレクションにはプライマリフィールドがあり、コンテンツマネージャではフィールド名の横にあるロックアイコンで示されます。デフォルトでは、タイトルフィールドはプライマリフィールドですが、コレクション内の任意の他のテキストフィールドを、IDシステムフィールドを除くプライマリフィールドに設定できます。
参照フィールドに情報を入力する場合、参照したコレクションのプライマリフィールドの値から選択します。参照したコレクションのプライマリフィールドを変更すると、参照フィールドに表示される値は、新しいプライマリフィールドの値と一致するように変化します。各アイテムがプライマリフィールドで一意の値を有するようにすることをお勧めします。
詳しくは、「参照フィールドについて」を参照してください。
すべてのデータベースコレクションには、次に示すデフォルトフィールドが含まれています。これらは編集できず、デフォルトでは非表示になっています。
IDフィールドの値は、データAPIを使用してアイテムを追加するとき、またはCSVファイルから新しいデータをインポートするときに割り当てることができます。後で変更することはできません。それ以外のすべての場合で、これらのフィールドの値は自動的に生成され、変更できません。
動的ページを作成すると、動的ページがデータをプルするコレクションに新しいフィールドが追加されます。このフィールドには、動的ページのプレフィックスとページにバインドされるデータを判定するフィールドの値とを含む計算されたURLが含まれます。
例えば、タイトルフィールドに基づいて料理コレクションからのアイテムを表示する動的アイテムページがあるとします。コレクションには、/Dishes/pizzaおよび/Dishes/checkenなどのURLを持つ料理(タイトル)というフィールドがあります。
訪問者が動的ページに行くと、ページのURLに一致するURLを持つコレクションのすべてのアイテムがページのデータセットにバインドされます。
動的アイテムページの場合、各アイテムには一意のURLがあります。動的カテゴリペ
ージの場合、複数のアイテムがURLを共有します。
計算フィールドのコンテンツを編集することはできません。しかしながら、動的ページのURLを変更すると、それに応じてコレクション内のURLも変更されます。コレクションに基づいて複数の動的ページを作成する場合、コレクションには動的ページごとに1つの計算されたフィールドを持ちます。
詳しくは、「計算されたフィールドについて」を参照してください。
パーミッションモデルを使用すると、コレクション内のデータの操作を許可されている訪問者と許可されている操作とを管理できます。
パーミッションはコレクションごとに設定されます。どのユーザロールがどのアクションを実行できるかを判定するパーミッションを割り当てます。例えば、コメントコレクションに関してサイトメンバに作成パーミッションを付与しながらも、別のコレクションではアイテムを作成できないようにすることができます。
詳しくは、「データベースコレクションのパーミッションについて」を参照してください。
コレクションからCSVファイルにデータをエクスポートでき、CSVファイルからコレクションにデータをインポートできます。
下記の記事をご参照ください。
・サンドボックスとライブデータについて
データベース構造を使えるようにする
フィールドタイプを変更する
参照フィールドについて
コレクションのパーミッションについて
コンテンツマネージャにコレクションデータをインポートするには
サンドボックスデータとライブデータについて
コレクションからフィールドを削除する
計算されたフィールドについて
動的ページについて
コンテンツマネージャでコレクションデータをエクスポートするには
ルータについて
Wixコードリソースセンターにアクセスし、さらに学びましょう。
Wixコードを使用することにより、サイトに到来する要求を処理する場合に完全に管理を行えるルータを作成できます。これを行うには、指定されたプレフィックスを持つすべての到来する要求を受け取るようにルータを設定し、そのプレフィックスを持つ要求を受け取ったときに実行するロジックを定義します。実行するアクション、返す応答、要求をルーティングする場所、ページに渡すデータを決定します。
ルータを使用して次のことができます。
・任意のデータソースからのコンテンツを使用して動的ページを表示する。
・URLをカスタマイズして、より意味のあるものにし、SEOの結果を改善する。
・ユーザを認証し、ユーザ専用のコンテンツを表示する。
・カスタムHTTP応答コードを返す。
ルータのAPI参照はこちらを参照してください。
ルータを作成する場合、指定したURLプレフィックスに基づいて、どの要求をルータ
で処理するかを選択します。そのURLプレフィックスを持つすべての到来する要求が、処理のためにルータに送信されます。URLプレフィックスはまた、ルータ名としても使用されます。
プレフィックスは、次の例で太字で示されているURLの一部です。
・プレミアムサイト:https://domain.com/prefix/category/item
・無料サイト:https://user.wixsite.com/yoursite/prefix/category/item
ルーティングロジックはrouters.jsファイルで定義されます。このファイルは、サイト構造サイドバーのバックエンドセクションにあります。ルータへのエントリポイントである2つの主な機能があります。
これらは、次の規則にしたがって命名されます。
・<router prefix>_router(request)
・<router prefix>_sitemap(sitemapRequest)
router()関数では、定義されたプレフィックスを持つページ要求が送信されます。ルータは、到来する要求に関する情報を含むWixRouterRequestオブジェクトを受け取ります。次に、関数は要求の処理方法を決定し、適切なWixRouterResponseを返します。通常、router()関数は、表示するページ(存在する場合)とページに渡すデータとを決定します。次に、forbidden()関数、notFound()関数、ok()関数、redirect()関数、またはsendStatus()関数を使用して応答が送信されます。
sitemap()関数では、サイトマップ要求が処理されます。この関数を使用して、検索エンジンがルータのページへのリンクを確実に見つけられるようにします。各WixSitemapEntryには、URL、タイトル、名前など、ページに関する情報が含まれています。
sitemap()関数はまた、アイテムプレビューウィジェットに入力するためにも使用され、プレビューモードでURLを切り替えることができます。
router()関数は、ルーティング先のページにデータを送信することを選択できます。フロントエンドページコードでそのデータにアクセスするには、wix−windowモジュールのgetRouterData()関数を使用します。
ルータを作成する
ルータを作成する
ルータを作成することにより、サイトに到来する要求を処理する場合に完全に管理できます。
この記事では、ルータを機能させるために記述する必要があるかコードを説明します。ルータとは何か、またルータを作成するべき理由についての詳細は、「ルータについて」を参照してください。
ルータを追加するには:
1.サイト構造サイドバーのページセクションヘッダにカーソルを合わせると表示されるプラスアイコンをクリックし、[ルータを追加する]を選択します。
2.ルータのURLプレフィックスを入力し、[コードの追加と編集]をクリックします。指定されたURLプレフィックスを持つすべての到来する要求が、処理のためにルータに送信されます。
ルータを追加する場合には:
・ルータのrouter()関数およびsitemap()関数は、単純なルーティングシナリオのサンプルコードと共にrouters.jsファイルに追加されます。routers.jsファイルは、サイト構造サイドバーのバックエンドセクションにあります。
・ページの下の新しいセクションもルータのために作成されます。セクションには、前に選択したプレフィックスを使用して名前が付けられ、始めるためのページが1ページ含まれています。例えば、ルータに「myRouter」という名前を付けた場合、myRouter−pageという名前のページを持つMyRouter Pages(Router)セクションが追加されます。
routers.jsファイルに追加されるサンプルコードには4つのパートがあります。
3.router()関数
4.sitemap()関数
ルータを作成するために使用される機能は、ルータAPIに含まれています。この機能を使用するには、これをインポートする必要があります。デフォルトでは、ok()関数とnotFound()関数、およびWixRouterSitemapEntryオブジェクトがインポートされています。
ルータAPIからの機能をさらに使用する場合は、それをimport文に追加する必要があります。
サンプルシナリオでは、ルータはpeopleDataという名前のオブジェクトに含まれる静的データを使用します。
ルータでは静的データを使用できますが、通常はサイトのデータベースまたは外部ソースからのデータを使用します。そのデータを取得するためのコードをどこで記述するかについては、後ほど説明します。
データをどこから取得するかに関係なく、データを処理するコードを記述するため、データは任意の方法で構造化できます。
ルータの作成時に指定したURLプレフィックスを持つすべての到来する要求は、処理のためにルータに送信されることに注意してください。router()関数で、これらの要求を処理します。
router()関数は、次の規則にしたがって命名されます。
そのため、ルータにmyRouterという名前を付けた場合、routers.jsファイルに追加されるコードは次のようになります。
//コードをルーティングします。
router()関数には、到来する要求に関する情報を含むWixRouterRequestオブジェクトを受け取る要求パラメータがあります。オブジェクトには、ルータに到達するために使用されるURL、要求の送信場所、要求の送信者に関する情報が含
まれています。
通常、router()関数は、表示するページ(存在する場合)とページに渡すデータとを決定します。次に、forbidden()関数、notFound()関数、ok()関数、redirect()関数、またはsendStatus()関数を使用して応答が送信されます。
router()関数のサンプルコードを見てみましょう。
//名前でアイテムデータを取得する
//SEOタグを定義する
//アイテムページをレンダリングする
//アイテムが見つからない場合は404を返す
router()関数は、要求のパスを解析して名前の値を引き出すことから始まります。
例えば、ユーザはhttps://mysite.com/myRouter/Ashをブラウズしてこのrouter()関数に到達できます。受信したWixRouterRequestオブジェクトのパスプロパティは、1つの要素[”Ash”]を持つ配列になります。ここでは名前の値は「Ash」です。
次に、router()関数は、受け取った名前に基づいてデータを取得します。
上記の例を続けると、peopleDataオブジェクトからAshの情報を引き出します。
したがって、データは次のようになります。
外部ソースからデータを取得する場合には、ここでそのデータを取得するための呼び出しを行います。
到来する要求に対応するデータの取得を試みた後、データが見つかったかどうかを確認します。
何も見つからなかった場合、ifはスキップされ、notFound()関数を使用して404エラーを返します。
探しているデータが見つかったと仮定して、ここでページのためのヘッダデータを準備します。
サンプルコードは、取得したデータオブジェクトのタイトルプロパティに基づいてタイトルおよび説明を作成します。また、noIndexをfalseに設定します。これは、検索エンジンがページをインデックスすべきであることを意味します。最後に、いくつかのメタタグプロパティも追加されます。
必要な情報を用いてHeadOptionsオブジェクトを作成できます。
ページのキーワードを含む文字列を使用して、HeadOptionsオブジェクトにキーワードプロパティを追加することもできます。
最後に、ok()関数を使用してWixRouterResponseオブジェクトを返します。
ここで、ユーザを「myRouter−page」という名前のルータページにルーティングし、取得したデータとそのページ用に構築されたseoDataとを渡します。
状況に応じて、router()関数からいくつかの異なる応答を返すことができます。これまで、notFound()関数およびok()関数が使用されているのを見てきました。また、forbidden()関数を使用して403応答を返す、またはredirect()関数を使用して301もしくは302応答を返す、またはsendStatus()関数を使用して選択したステータスコードで応答を返すこともできます。
ok()関数を使用してWixRouterResponseで返されたデータを使用するには、wix−windowのgetRouterData()関数を使用します。
例えば、サンプルルータコードによって渡されたデータを取得し、それを使用して、作成されたmyRouter−pageページに個人の情報を表示できます。
まず、個人のタイトルおよび画像のためのプレースホルダとして機能するテキストおよび画像要素を追加する必要があります。
ページをプレビューすると、ページに配置したプレースホルダに、ページに渡されたデータからの情報が入力されていることがわかります。プレビューウィジェットを使用して、routers.jsファイルで定義されたpeopleDataオブジェクト内の人物のうちのいずれかのためのページの様子を確認できます。
プレビューウィジェットには、ルータのsitemap()関数によって返されるWixRouterSitemapEntryオブジェクトからのタイトル値が入力されます。
router()関数と同様に、sitemap()関数は、次の規則にしたがって命名されます。
そのため、ルータにmyRouterという名前を付けた場合、routers.jsファイルに追加されるコードは次のようになります。
//コードをルーティングします。
sitemap()関数には、到来する要求に関する情報を含むWixRouterSitemapEntryオブジェクトを受け取るsitemapRequestパラメータがあります。オブジェクトには、ルータに到達するために使用されるURL、ルータ内のページ、要求の送信者に関する情報が含まれています。
通常、sitemap()関数は、ルータが使用するデータのアイテムごとにWixRouterSitemapEntryオブジェクトを作成します。そのため、この例では、personDataオブジェクトの各人物のエントリを作成します。インデックスページや検索ページなど、他のページのエントリを含めることもできます。
//データをサイトマップエントリに変換します。
//Wixエディタにおけるページの名前
//ページの相対URL
//より良いSEOのために−Googleの助けとなるように
//サイトマップエントリを返します。
sitemap()関数はpeopleDataオブジェクトのキーを取得し、JavaScriptのmap()関数を使用してWixRouterSitemapEntryオブジェクトの配列を、キーごとに1つのオブジェクトとなるように作成します。各エントリには、pageNameプロパティ、urlプロパティ、およびtitleプロパティの値が与えられます。次に、配列はPromiseにラップされて返されます。
サイトマップエントリには、changeFrequecyプロパティ、lastModifiedプロパティ、およびpriorityプロパティを含むことができて、検索エンジンに各ページに関するより多くの情報を提供することもできます。
外部データでルータを使用している場合、sitemap()関数でそのデータを取得し、取得した各アイテムのサイトマップエントリを構築します。
ルータについて
SEOおよびルーティング
ルータページのSEO設定は、通常ページの設定とわずかに異なります。WixページのSEOについてはこちらをご覧ください。
通常ページの場合と同様に、ルータページのページタイトル、説明、ソーシャルネットワーク画像を定義できます。違いは、ルータページには静的データが含まれておらず、SEO情報を動的に設定する必要があるため、表示されたときに保持している実際のコンテンツを反映することです。
ルータページでSEOを設定するには2つのパートがあります。
・Googleがページについて学習するためのメタタグを作成する。
・Googleがページを見つけるのに使用するためのサイトマップを作成する。
ルータのrouter()関数を作成するときに、ルータのページにSEOメタタグを設定します。その関数内で、HeadOptionsオブジェクトを作成し、ok()関数を使用してルーティング先のページに渡します。
例えば、ルータを追加するときに提供されるサンプルコードにおいて、次のコードではルータによって取得されたデータを使用して、HeadOptionsオブジェクトを構築し、myRouter−pageという名前のページに渡します。
//ページのデータを取得します。
HeadOptionsオブジェクトには、router()関数で取得したデータを使用して、関連する値を設定できるいくつかのプロパティが含まれています。タイトルおよび説明のプロパティには、SEOの目的で使用されるページのタイトルおよび説明が含まれています。オブジェクトには、ページをインデックスするべきか否かをGoogleに伝えるnoIndexフラグを含めることもできます。追加のメタタグをmetaTagsプロパティに追加できます。
HeadOptionsオブジェクトにはキーワードプロパティを含めることもできますが、Googleはサイトのキーワードを無視します。
サイトのサイトマップは、Googleがサイトのすべてのページを見つけるために使用するものです。ルータに属さないサイト上のページは、サイトのサイトマップに追加されます。しかしながら、動的に異なるすべてのバージョンを含め、ルータで利用可能なページを完全に制御するため、Googleがそれらを見つけることができるように、ルータのプレフィックスに接続されるすべての可能なURLを含むサイトマップを作成する必要があります。
ルータのページをサイトのサイトマップに追加するには、ルータのためのsitemap()関数を作成します。その関数内で、ルータがルーティングできるURLごとにWixRouterSitemapEntryオブジェクトを作成します。各WixRouterSitemapEntryには、URL、タイトル、名前など、ページに関する情報が含まれています。また、コンテンツの変更頻度、最終変更日時、サイト内での相対的な優先度など、各ページに関する追加情報を追加することもできます。Googleはサイトマップエントリを使用して、サイト内のすべてのページを発見します。
例えば、ルータを追加するときに提供されるサンプルコードにおいて、次のコードでは
ルータによって取得されたデータを使用して、HeadOptionsオブジェクトを構築し、myRouter−pageという名前のページに渡します。
//データをサイトマップエントリに変換します。
//非同期Promiseにラップします。
サイトマップが適切に機能していることを確認するには、公開されたサイトからサイトマップを取得できます。ウェブブラウザで、公開されたサイトのURLに移動し、それに/sitemap.xmlを追加します。
例えば、プレミアムサイトの場合に、サイトの公開されたURLが次の場合、
https://mysite.com
次のURLに移動します。
https://mysite.com/sitemap.xml
無料サイトの場合に、サイトの公開されたURLが次の場合、
https://username.wixsite.com/site−name
次のURLに移動します。
https://username.wixsite.com/site−name/sitemap.xml
サードパーティサービスにアクセスする
Wixコードを使用して、サードパーティのウェブサービスにアクセスするコードを作成できます。サードパーティのサービスをクライアントサイドのコードから直接呼び出すことができます。しかしながら、APIキーの公開などのセキュリティ上の懸念がある場合は、バックエンドウェブモジュールからサービスを呼び出すことができます。
注意:
サイトがHTTPSサイトである場合、サービスからHTTPコンテンツを要求することはできません。無効な要求はエラーを引き起こします。これはブラウザの開発者ツールを使用して確認できます。要求を修正するには、HTTPSプロトコルを使用して要求されたリソースをHTTPSサイトから取得するか、サイトのSSLをオフにしてHTTPリソースを取得します。
>アドバンスト:サービスを呼び出すために利用可能なモジュール
例えば、サードパーティのサービスを呼び出して、為替交換レートを調べる場合を考えます。
この例では、次の要素を持つ単純なフォームを作成しました。
フォームを設定したら、ボタンのプロパティを設定して、onClickハンドラが次の関数を呼び出すようにできます。
この例では、フェッチ要求のための完全なURLを構築することから始めます。URLは、サービスのアドレスおよびいくつかのクエリパラメータで構成されます。簡単のために、常に米ドルを換算するため、基本パラメータの値はUSDにハードコードされます。シンボルパラメータの値は、フォームからプルされます。次に、関数は実際の要求を行います。応答を受信すると、渡されたシンボルの変換率をプルし、それをラベルのテキストとして設定します。
注意:
特定のCORS(オリジン間リソース共有)要求は、ブラウザから発信される場合に制限されます。通常、GET要求および特定のPOST要求は、サイトのパブリック、ページ、またはサイトコードから作成できます。他のすべての要求は、サイトのバックエンドコードから行う必要があります。無効な要求はエラーを引き起こします。これはブラウザの開発者ツールを使用して確認できます。CORSの制限によりフェッチ呼び出しで問題が発生している場合は、以下に説明するように呼び出しをバックエンドに移動します。
バックエンドからのサービス呼び出しは、2つのパートで行われます。まず、バックエンドウェブモジュールでサービス呼び出しを行うコードを記述します。これにより、APIキーの公開などのセキュリティ上の懸念が回避され、
例えば、サードパーティの気象サービスを呼び出して、ユーザが選択した都市の現在の天気を見つけることを考えます。
まず、気象サービスを呼び出してデータを取得する関数をバックエンドウェブモジュールに作成します。
この例では、wix−fetchからfetchをインポートすることから始めます。これはhttps要求を行うために使用されます。次に、天気を調べたい都市を取り込む新しい関数を作成します。関数は、フェッチ要求のための完全なURLを構築することから始まります。URLは、サービスのアドレスおよびAPIキーで構成されます。この例を機能させるには、<api key placeholder>を独自のAPIキーに置き換える必要があります。次に、関数は実際の要求を行います。応答を受信すると、温度データを引き出します。その温度データは、クライアントサイドの呼び出しによって受け取られます。
クライアントサイドでは、バックエンド関数を呼び出す場所と、返されるデータをどう処理するかを決定する必要があります。
この例では、次の要素を持つ単純なフォームを作成しました。
フォームを設定したら、ボタンのプロパティを設定して、onClickハンドラがバックエンドモジュールに記述した関数を呼び出すようにできます。
//フォームのページコード
ここではバックエンドで記述した関数をインポートすることから始めます。次に、ボタンのイベントハンドラでgetCurrentTemp関数を呼び出します。入力要素の値は、都市の引数として渡されます。関数の実行が終了したら、返された温度を表示するテキストラベルを設定します。
ウェブモジュールでフロントエンドからサーバサイドコードを呼び出す
動的ページ
記事
>動的ページについて
>動的ページが必要な場合とは
>動的ページタイプを選択するには
>動的アイテムページを追加するには
>動的カテゴリページを追加するには
>動的ページデータセット設定を使う
>動的ページをプレビューする
>動的ページにリンクする
>動的ページを削除する
>動的ページと通常ページとを変換するには
>動的ページURLを作成する
>動的ページおよび動的ページが表示するアイテムについて
>複数の動的ページURLを一意にする
>URLプレフィックスおよび動的ページのページグループ化について
>動的ページのためのSEO設定
>動的ページのためのページ情報設定
>モバイルビューで動的ページのためのページ設定を使う
>計算されたフィールドについて
動的ページについて
Wixコードリソースセンターにアクセスし、さらに学びましょう。
動的ページを作成する場合、繰り返し使用でき、毎回データベースコレクションからの異なるアイテムを表示する1つのページレイアウトを設計します。動的ページは表示されるたびに異なるアイテムを表示するため、通常ページとは異なります。通常ページはその
コンテンツをページ自体に保存しますが、動的ページのためのコンテンツはデータベースコレクションに保存されます。
動的ページは次のような場合に役立ちます。
・ページを複製し、各ページのコンテンツまたはデザインを手動で変更している場合。動的ページを使用すると、アイテムを一度に1つずつ表示する、またはグループで複数のアイテムを表示する1つのページを作成できます。
・エディタで何も変更せずに、またはサイトのデザインを変更せずに、サイトのコンテンツを編集する場合。
動的ページには2つの種類があります。
・動的アイテムページ:コレクション内の1つのアイテムを表示するように設計されたページ。
・動的カテゴリページ:同じ基準に一致するすべてのコレクション内の複数のアイテムを表示するように設計されたページ。これらのアイテムは、リピータ、ギャラリー、またはテーブルに表示されます。
レシピサイトを作成していることを考えます。新しいデータベースコレクションを作成すると、タイトルフィールドがコレクションに自動的に追加されます。このフィールドを使用してレシピの名前を保存するとします。食事フィールドをコレクションに追加し、レシピが朝食、昼食、夕食のいずれであるかを記載します。また、レシピが前菜、メイン、デザートのいずれであるかを記載するコースフィールドを追加します。
次に、各レシピを独自のページに表示できるようにサイトを設計します。
この例では、個々のレシピを表示するページは動的アイテムページであり、食事に基づいてすべてのレシピを表示するページは動的カテゴリページです。
コレクションのいくつかのコンテンツを見て、これがどのように機能するかを見てみましょう。
ここで、このコンテンツが動的アイテムページにどのように表示されるかを見てみましょう。
注意:
この例では、動的ページの能力を使用して何ができるかを説明します。それらの設定方法については、「動的アイテムページを追加するには」および「動的カテゴリページを追加するには」を参照してください。
コレクションから各アイテムを表示するには、動的アイテムページを作成します。これは次のようになります。
このレイアウトでは、実際のコンテンツが含まれている要素は見出し「レシピ」、「食事」、および「コース」のみであることに注意してください。これらの見出しの横(テキストに「<>」のついている部分)に表示されるコンテンツは、まだページに配置されていません。例えば、「<レシピのタイトル>」は、実際のレシピ名が表示されるテキストボックスのプレースホルダテキストに過ぎません。また、間にある画像は単なるプレースホルダ画像です(コレクションからの画像ではありません)。これらの要素が表示する実際のコンテンツは、コレクションから取得されます。
ここで、カップケーキレシピのこの動的アイテムページをプレビューしてみましょう。
プレースホルダのそれぞれがどのようにカップケーキレシピの具体的な情報に置き換えられたか、また画像がどのようにコレクションからのカップケーキ画像を表示しているか
に注目してください。
同じページでエッグベネディクトのレシピをプレビューし、プレースホルダのコンテンツの変更を確認できます。
ここで、このコンテンツが動的カテゴリページにどのように表示されるかを見てみましょう。
選択した基準に基づいて、レシピの異なるグループを表示する動的カテゴリページを作成できます。
提供されている食事に基づいてレシピを表示できるページを作成することを考えます。テーブルを使用して、それらのレシピを表示できます。
アイテムページと同様に、この動的カテゴリページには実際のコンテンツはありません。ランチレシピをプレビューしたときの様子を見てみましょう。
動的ページはコンテンツを動的に表示するため、通常ページにリンクするのと同じ方法で動的ページにリンクすることはできません。詳しくは、「動的ページにリンクする」を参照してください。
ヒント:
下記の記事をご参照ください。
・動的ページURLを作成する
・動的ページおよび動的ページが表示するアイテムについて
・動的ページURLを一意にする
動的ページURLを作成する
複数の動的ページURLを一意にする
データベースコレクションについて
動的ページおよび動的ページが表示するアイテムについて
動的ページにリンクする
データフックについて
データフックは、サイトのコレクションとの特定のやり取りの前後にコードを実行します。データフックを使用すると、やり取りの発生の直前または直後にやり取りをインターセプトできます。フックのコードは、やり取り自体に影響を与えるためにも使用できます。例えば、アイテムをコレクションに追加する前にアイテムをインターセプトして、最終検証を実行したり、実際にコレクションに入れるデータを微調整したりする場合があります。
一般的に、フックは、コレクションとのやり取りがページ要素によって開始されるか、データAPIを使用してプログラムで開始されるかに関係なく実行されます。しかしながら、サイトのバックエンドコードからのデータAPI呼び出しは、オプションのWixDataOptionsオブジェクトを渡し、それを使用して、その特定のやり取りでフックが呼び出されないようにします。
データのやり取りのライフサイクルには、フックできるいくつかの異なるポイントがあります。異なるフックは異なる引数を受け取り、異なる値を返します。詳しくは、「データAPI参照」を参照してください。
・item:現在のアイテム。例えば、beforeInsertでは、これは挿入されようとしているアイテムです。例えば、afterQueryで発生する可能性があるような多くのアイテムがある場合、フック関数はアイテムごとに1回繰り返し呼び出されます。
・itemId:現在のアイテムのID値。
・query:実行されるWixDataQueryオブジェクト。
・count:カウントにおけるアイテムの数。
・error:エラーオブジェクト。
データフックを使うには
データAPIを使う
データバインディングルータフックについて
動的ページのうちの1つに要求が到来すると、ルータは要求のURLを使用して、表示するページとページのデータセットにバインドするデータを決定します。データバインディングルータフックを追加して、特定のポイントでこのプロセスをインターセプトし、追加のロジックを挿入できます。いくつかのフックをルータページでも使用できます。
データバインディングルータフックはrouters.jsファイルで定義されます。このファイルは、サイト構造サイドバーのバックエンドセクションにあります。
フック関数は、次の規則にしたがって命名されます。
ルータプレフィックスは、動的ページを作成する際に選択するURLの最初の部分です。動的ページのURLは、ページの設定で確認できます。
例えば、/dishes/nameというURLのページがあり、beforeRouterフックを作成する場合、関数は次のようになります。
//関数コード
・beforeRouter
・customizeQuery
・afterRouter
・afterSitemap
フック関数の詳細については、「ルータAPI参照」を参照してください。
サイトのコレクションとの特定のやり取りの前後にコードを実行するデータフックを登録することもできます。登録した場合、データフックはcustomizeQuery()とafterRouter()との間で実行されます。
このフックは、ルータが要求されたページに移動する前にトリガされます。このフックを使用して、要求を異なるページにルーティングしたり、エラー応答を返したりできます。例えば、誰がページを要求しているかを確認し、ユーザの役割に基づいて、ルータに次のステップを続行させるか、エラータイプの応答コードを返すかを決定できます。
このフックは、ページのデータクエリが実行される前にトリガされます。このフックを使用して、ページのデータセットにバインドされるデータを判定するクエリをさらに調整または変更できます。例えば、ステータスフィールドがアクティブに設定されているアイテムのみを返すようにクエリをフィルタリングできます。
このフックは、ルータがデータをバインドした後、ページが表示される前にトリガされます。このフックを使用して、取得したデータに基づいてルータの応答を変更できます。例えば、ページの2つのバージョン、すなわち、縦長画像のためのページと横長画像のためのページとを持つことができます。データベースから画像をプルした後、画像の向きに対応するページを表示できます。
このフックは、サイトマップが作成された後にトリガされます。このフックを使用して、サイトマップ内のページのリストを修正できます。例えば、サイトマップに検索ページの情報を追加できます。
データバインディングルータフックを作成する
データバインディングルータフックを作成することにより、動的ページのデータがページにバインドされるプロセスをインターセプトできます。
この記事では、データバインディングルータを機能させるために記述する必要があるコードを説明します。データバインディングルータフックとは何か、またデータバインディングルータフックを作成するべき理由についての詳細は、「データバインディングルータフックについて」を参照してください。
データバインディングルータフックを追加するには、
1.サイト構造サイドバーで動的ページのうちの1つにカーソルを合わせると表示される設定アイコンをクリックし、[設定]をクリックしてページのページ情報設定を表示します。
2.[その他の機能]で、[フックの追加]をクリックして[フックの追加]ダイアログを表示します。
3.[フックの追加]ダイアログにおいて、追加するフックを選択し、[コードの追加と編集]をクリックします。
データバインディングルータフックを追加すると、選択したデータバインディングルータフックの関数スタブがrouters.jsファイルに追加されます。routers.jsファイルは、サイト構造サイドバーのバックエンドセクションにあります。
データバインディングルータフック関数は、次の規則にしたがって命名されます。
したがって、動的ページにmyPrefixというプレフィックスがある場合、beforeRouterフックのrouters.jsファイルに追加されるコードは次のようになります。
//コードをルーティングします。
登録できるフックを実行される順序で次にリストします。
・beforeRouter
・customizeQuery
・afterRouter
・afterSitemap
フック関数の詳細については、「ルータAPI参照」を参照してください。
サイトのコレクションとの特定のやり取りの前後にコードを実行するデータフックを登
録することもできます。登録した場合、データフックはcustomizeQuery()とafterRouter()との間で実行されます。
このフックは、ルータが要求された動的ページに移動する前にトリガされます。このフックを使用して、要求を異なるページにルーティングしたり、エラー応答を返したりできます。正しい応答を判定するためにページにバインドされるデータが必要な場合は、代わりにafterRouter()フックを使用します。
beforeRouter()フックは、到来する要求に関する情報を含むWixRouterRequestオブジェクトを受け取ります。オブジェクトには、ルータに到達するために使用されるURL、要求の送信場所、要求の送信者に関する情報が含まれています。
フックのボディ内で、必要なコードを記述できます。そこに記述するコードは、要求への応答方法を判定するのに役立ちます。
この関数は、ルータにルーティングを継続させる、またはHTTP応答コードで応答させるWixRouterResponseオブジェクトを返す必要があります。
ルータが同じデータで元々進んでいた同じページに進むようにするには、next()関数を使用して適切なWixRouterResponseを返します。
しかしながら、フックに到達する前に元々行っていた以外のことをルータに実行させる場合は、forbidden()関数、notFound()関数、redirect()関数、またはsendStatus()関数を使用してWixRouterResponseを返すことができます。
この例では、特定の要求が目的のターゲットにルーティングされるのを制限するフックを動的プレフィックスに作成します。
次のコードは、ウェブサイトのバックエンドセクションのrouters.jsファイルに配置されます。
データバインディングルータフックを作成するために使用されるフック機能は、ルータAPIに含まれています。この機能のうちのいくつかを使用するには、これをインポートする必要があります。
ここでは、forbidden()関数およびnext()関数をインポートします。
ルータAPIからの機能をさらに使用する場合は、それをimport文に追加する必要があります。
フック関数では、パスが文字列「admin」で始まるか否かを確認することから始めます。
ただし、パスが「admin」で始まる場合、どのタイプのユーザが要求を行っているかを確認します。
ユーザがサイトの所有者である場合は、フックによってインターセプトされる前に、ルータが移動していた場所に進むようにもう一度ルータに指示します。
しかし、ユーザがサイトの所有者ではない場合、403応答を返します。
このフックは、ページのデータクエリが実行される前にトリガされます。このフックを使用して、ページのデータセットにバインドされているデータを判定するクエリをさらに調整または変更できます。
customizeQuery()フックは、到来する要求に関する情報を含むWixRouterRequestオブジェクト、現在のルートを含む文字列、およびルーティングされるページのデータを取得するために使用されるクエリを含むWixDataQu
eryオブジェクトを受け取ります。
フックのボディ内で、必要なコードを記述できます。そこに記述するコードは、初期データを継続するか、何らかの方法で変更するかを判定するのに役立ちます。
関数は、ルーティングされるページに渡される最終データを取得するために使用されるWixDataQueryオブジェクトを返す必要があります。
ただし、ルータで異なるデータを使用する場合は、データAPIの関数を使用して現在のクエリを調整するか、新しいクエリを作成できます。
この例では、アクティブなユーザのみを見つけるために特定の要求が目的のターゲットに特定のルートのためのクエリをフィルタリングするフックを動的プレフィックスに作成します。
次のコードは、ウェブサイトのバックエンドセクションのrouters.jsファイルに配置されます。
クエリを作成するために使用される機能は、データAPIに含まれています。この機能のうちのいくつかを使用するには、これをインポートする必要があります。
フック関数では、ルートがユーザを表示する動的ページに移動しているか否かを確認することから始めます。
そこに行く場合は、「アクティブ」ユーザのみを取得するようにクエリを調整します。
それ以外の場合は、受け取った同じクエリを返します。
このフックは、ルータがデータをバインドした後、ページが表示される前にトリガされます。このフックを使用して、取得したデータに基づいてルータの応答を変更できます。
afterRouter()フックは、到来する要求に関する情報を含むWixRouterRequestオブジェクトおよびルータの応答に関する情報を含むWixRouterResponseオブジェクトを受信します。
フックのボディ内で、必要なコードを記述できます。そこに記述するコードは、初期応答を継続するか、別の応答に変更するかを判定するのに役立ちます。
この関数は、ルータにルーティングを継続させる、またはHTTP応答コードで応答させるWixRouterResponseオブジェクトを返す必要があります。
ルータが同じデータで元々進んでいた同じページに進むようにするには、応答パラメータで関数が受け取ったオブジェクトを返します。
しかしながら、フックに到達する前に元々行っていた以外のことをルータに実行させる場合は、ok()関数、forbidden()関数、notFound()関数、redirect()関数、またはsendStatus()関数を使用してWixRouterResponseを返すことができます。ルータが元々ルーティングしようとしていたページとは異なるページ上のルータからのデータを使用するには、[ok()]関数を使用してページを選択し、そのページに元の応答からのresponse.dataおよびresponse.headerを渡すことができます。このユースケースの例については、以下を参照してください。
この例では、2つのページのうちの1つにユーザをルーティングするフックを動的プレフィックスに作成します。ページの2つのバージョン、すなわち、水平方向の画像のためのページと垂直方向の画像のためのページとがあります。データベースから画像をプルした後、どの種類の写真を表示するかを確認し、画像の向きに対応するページにルーティングします。
次のコードは、ウェブサイトのバックエンドセクションのrouters.jsファイルに配置されます。
データバインディングルータフックを作成するために使用されるフック機能は、ルータAPIに含まれています。この機能のうちのいくつかを使用するには、これをインポートする必要があります。
ここでok()関数をインポートします。
ルータAPIからの機能をさらに使用する場合は、それをimport文に追加する必要があります。
フック関数では、応答ステータスがOKステータスであり、応答のルーティング先のページが水平方向の写真を表示するページであるかどうかを確認することから始めます。
他のステータスを見つけた場合、または応答しているページが2つのバージョンを持つページではない場合、単に元の応答を返します。
ただし、ルータが水平方向の画像を表示するページにルーティングしようとしている場合、ページに表示される画像の向きを確認します。それには向きを取得します。
写真の向きが送信先のページと一致しない場合、その向きと一致する別のページにルーティングし、元の応答からデータおよびヘッド情報を取得して、新しいページにも送信します。
しかし、写真の向きが送信先のページと既に一致している場合は、そのままの送信先に送信します。
このフックは、サイトマップが作成された後にトリガされます。このフックを使用して、サイトマップ内のページのリストを修正できます。
afterSitemap()フックは、到来する要求に関する情報を含むWixRo
uterSitemapRequestオブジェクト、およびサイトマップのエントリを含むWixRouterSitemapEntry配列を受け取ります。
フックのボディ内で、必要なコードを記述できます。そこに記述するコードは、初期サイトマップエントリを継続するか、何らかの方法で変更するかを判定するのに役立ちます。
関数は、サイトマップのすべてのエントリを含むWixRouterSitemapEntry配列を返す必要があります。
フックが受信したのと同じサイトマップエントリでルータを続行する場合は、関数がsitemapEntriesパラメータで受け取ったオブジェクトを返します。
ただし、ルータでサイトマップエントリを修正する場合は、標準のJavaScript配列処理方法を使用して、受信した配列のエントリを追加、除去、または修正できます。
この例では、サイトマップに検索ページを追加するフックを動的プレフィックスに作成します。サイトマップ関数は、検索ページのURLのみを公開することに注意してください。このURLにページを実際に実装するには、beforeRouter()フックを使用して、検索ページURLの要求を確認し、ユーザを検索ページにルーティングします。
次のコードは、ウェブサイトのバックエンドセクションのrouters.jsファイルに配置されます。
サイトマップエントリを作成するために使用される機能は、ルータAPIに含まれています。この機能のうちのいくつかを使用するには、これをインポートする必要があります。
ここでWixRouterSitemapEntryをインポートします。
フック関数では、要求のプレフィックスを取得することから始めます。
次に、検索ページの新しいエントリを作成します。
そして、新しいエントリをサイトマップエントリの配列に追加します。
最後に、エントリの配列をPromiseにラップして返します。
リピータに動的コンテンツを表示する
Wixコードリソースセンターにアクセスし、さらに学びましょう。
リピータは、同じレイアウトを使用して複数のアイテムを表示する要素です。好みのレイアウトを作成すると、各リピータアイテムはその同じレイアウトを使用して異なるコンテンツを表示します。
リピータアイテムはコンテナのように機能します。他の要素をリピータ要素にアタッチします。1つのリピータアイテムに加えた変更は、他のすべてのアイテムに自動的に反映されます。
注意:
リピータレイアウトを設計するときに、テキスト、画像、図形、ボックス、ボタン、ギャラリー、およびテーブルなどの要素を使用できます。
リピータを使用して静的コンテンツを表示できます。つまり、エディタにおいて各アイテムの各要素のコンテンツを手動で決定できます。
また、データベースコレクションからのコンテンツを動的に表示するには、リピータおよびそれにアタッチされた要素をデータセットに接続します。リピータには、コレクション内のアイテムごとに1つのアイテムが含まれ、各リピータアイテムは同じテンプレートを使用しますが、異なるコンテンツを表示します。データセット設定で一度に表示されるアイテムの数を制御します。
以下は、いくつかの可能性を示す例です。
次の図のように、すべてのレシピをコレクションに保存するレシピサイトがあるとします。図には、各料理の写真、料理法、提供するコースが含まれています。各レシピに関する情報を表示する動的アイテムページは既に作成されています。
2 チリコンカン メイン テキサス流メキシコ料理
3 チョコレートケーキ デザート グローバル
4 チョコレートケーキ乳成分不使用 デザート グローバル
5 チョコレートカップケーキ デザート グローバル
6 クレープ デザート フランス料理
7 クロワッサン サイド フランス料理
8 クロワッサンサンドイッチ メイン フランス料理
9 餃子 メイン 中国料理
10 エンチラーダ メイン テキサス流メキシコ料理
11 ファヒータ メイン テキサス流メキシコ料理
12 フレンチフライ サイド フランス料理
13 きのこのフジッリ メイン イタリア料理
14 ワカモレ サイド テキサス流メキシコ料理
ここで、リピータを使用してレシピをリストし、訪問者がリストをスクロールして興味のあるレシピを見つけることができるようにします。訪問者が料理の画像をクリックすると、そのアイテムの動的ページに移動します。以下の画像は、リピータがどのように見えるかを示しています。画像には、料理の写真、料理のタイトル、料理法、提供するコースが含まれています。写真はそのアイテムの動的ページにリンクしています。
ファヒータ フレンチフライ
メイン サイド
料理法:テキサス流メキシコ料理 料理法:フランス料理
きのこのフジッリ ワカモレ
メイン サイド
料理法:イタリア料理 料理法:テキサス流メキシコ料理
マカロン ナチョス
デザート メイン
料理法:フランス料理 料理法:テキサス流メキシコ料理
リピータアイテム内の既存の要素を移動し、不要な要素を除去します。また、新しい要素、具体的にはテキスト、画像、ボタン、ボックス、図形、ギャラリー、およびテーブルをリピータにアタッチすることもできます。
リピータの1つのアイテムのデザインまたは位置に加えた変更は、すべてのアイテムに自動的に反映されます。
以下の図は、エディタでのリピータの様子を示しています。リピータアイテムが2つしかないことに注意してください。リピータのサイズはデータセットから制御されるため、これ以上必要ありません。また、両方のリピータアイテムが同一であることに注意してください。
<料理の名前> <料理の名前>
<コース> <コース>
料理法:<料理法> 料理法:<料理法>
ヒント:
大きな要素を追加する場合、まずそれらをページに追加し、その後サイズを変更します。次に、それらをリピータ要素にドラッグします。[アイテムにアタッチ]が表示されたら、要素をドロップできます。
動的コンテンツを表示するには、リピータをデータセットに接続する必要があります。
リピータがデータセットに接続されると、関連するコレクションから情報を取得できます。また、表示したいアイテムの数に合わせてサイズを調整します。これは、データセット設定パネルの[表示するアイテムの数]フィールドで制御します。以下を参照してください。
次に、アタッチされた要素をデータセットに接続します。1つのアイテムのテンプレートに加えた変更は、すべてのアイテムに自動的に反映されることに注意してください。
各アイテムで同じのままであるラベルを使いたいとしましょう。それには、テキスト要素にテキストを入力してから、データセットに接続しないでおきます。
上記の例では、画像要素はコレクションの写真フィールドに接続され、そのレシピの動的アイテムページにリンクしています。<料理の名前>、<コース>、および<料理法>のテキスト要素は、コレクション内の対応するフィールドに接続されているため、動的コンテンツを表示できます。「料理法:」テキスト要素はどのデータセットにも接続されていないため、各リピータアイテムに同じテキストが表示されます。
各アイテムに異なる背景画像を表示させるには、リピータアイテムの背景画像をデータセットの画像フィールドに接続します。以下の図は、背景画像がレシピコレクションの写真フィールドに接続されている場合のリピータの様子を示しています。レシピの名前およびレシピの動的アイテムページへのリンクを表示するボタンを追加してあります。
ファヒータ フレンチフライ
きのこのフジッリ ワカモレ
マカロン ナチョス
デフォルトでリピータが表示するアイテムの数は、リピータに接続されているデータセットのデータセット設定によって制御されます。これはリピータ「ページ」と呼ばれます。
詳しくは、「ボタン接続パネルを使用する」を参照してください。
リピータはまた、参照フィールドを持つコレクションの関連アイテムを表示したり、あるデータセットを別のデータセットでフィルタリングした状況で関連アイテムを表示したりできます。これにより、各リピータアイテムが「マスタ」として機能する「マスタ−詳細」プレゼンテーションを作成できます。マスタ−詳細ページの作成に関するアイデアについては、こちらをご覧ください。
データセット設定を使う
テーブルまたはギャラリーに動的コンテンツを表示する
動的ページをプレビューする
Wixコードリソースセンターにアクセスし、さらに学びましょう。
動的ページを作成すると、エディタにプレビューパネルが表示されます。このパネルにはドロップダウンリストが含まれており、コレクションからプレビューするアイテムまたはカテゴリを選択できます。
ヒント:
プレビューパネルを閉じた場合に再度開くには、別のページに移動してからその動的ページに戻ります。
このドロップダウンリストには、この動的ページで表示できるコレクションからのアイテムのみが自動的に入力されます。動的アイテムページの場合、このリストにはコレクション内のすべてのアイテムが含まれます。動的カテゴリページの場合、このリストには、カテゴリページの作成に使用した基準に基づいて可能なすべての組み合わせが含まれます。
例えば、レシピサイトがあり、レシピのコースおよび食事をフィルタリングする動的カテゴリページを作成する場合、リストは次のようになります。
しかし、すべてのレシピのアイテムページのリストは次のようになります。
重要:
プレビューモードでは、管理者のパーミッションでサイトを表示しています。これはコンテンツの表示の仕方に影響し、サイト訪問者のエクスペリエンスと一致しない場合があります。
動的ページについて
Wixコードを使用してコードをテストおよびデバッグする
チェックリスト:コレクションのコンテンツと共にサイトを公開する
データを接続する
記事
>データセットとデータの接続について
>データセット設定を使う
>エディタでデータセットを使う
>Wixコードを使用して要素にリンクを追加する様々な方法を理解する
>Wixコードで要素にリンクを追加するには
>テーブルまたはギャラリーに動的コンテンツを表示する
>リピータに動的コンテンツを表示する
>テーブル接続パネルを使う
>あるデータセットを別のデータセットでフィルタリングする
>データセットによりフィルタを作成するには
>テキスト接続パネルを使う
>ボタン接続パネルを使う
>画像接続パネルを使う
>ビデオプレーヤ接続パネルを使う
>リピータ接続パネルを使う
>リピータアイテム接続パネルを使う
>カラム接続パネルを使う
>ページ接続パネルを使う
>データシートのフィルタリングと並べ替え
>ストリップ接続パネルを使う
>ボタンおよび画像のためのデータセットアクション
>現在ログインしているユーザに基づいてページをフィルタリングするには
データセットとデータの接続について
・Wixコードリソースセンターにアクセスし、さらに学びましょう。
・この記事を全画面表示するにはここをクリックしてください。
注意:
データセットはエディタに要素として表示されますが、公開されたサイトには表示されません。
データの接続は、ページ要素をデータベースコレクションに接続するプロセスです。これにより次のことが可能になります。
・サイトページにコレクションのコンテンツを表示する。
・ユーザ入力をキャプチャしてコレクションに保存する。
データセットは以下を制御します。
・要素での使用に利用可能なコレクション
・要素がコレクション内のコンテンツでできること(表示、追加、既存のものの修正)。これは、コレクションのパーミッションの影響も受けます。詳しくは、「データセットモードおよびコレクションパーミッションを使う」を参照してください。
・表示されたコンテンツがフィルタリングされているか並べ替えされているか
データセットは、ページ上の要素とコレクションとの間のブリッジまたはコネクタと考えることができます。まずデータセットをコレクションに接続し、次に要素をデータセットに接続します。これにより、次の図に示すように、要素がコレクションに接続されます。
同じデータセットに接続されているページ上のすべての要素は、データセットで定義されているようにコレクションのコンテンツで機能します。データセットは、コレクション内のどのアイテムが現在フォーカスされているかも追跡します。これは、コレクションのコンテンツの表示の仕方、およびユーザ入力のキャプチャの仕方に影響します。いくつかの例を見て、これがどのように機能するかを見てみましょう。
レストランのサイトで、訪問者がメニューのオプションをスクロールして閲覧できるようにする場合を考えます。メニューのすべてのアイテムのコレクションが用意できていて、それぞれのアイテムについて、次のものを表示しようとしています。
・料理の名前
・提供される場面
・前菜、メイン、またはデザートのいずれかである
・料理に関するアレルギー情報
・料理の写真
これらのアイテムを1つずつページに表示するように設計できますが、その前に、次のことをする必要があります。
・コレクション内の異なるアイテムを要素が表示するように、ページ上の要素を接続する。
コレクション内の特定のアイテムについては、すべての要素がその同じアイテムに対応する情報を表示している必要があります。
コレクション内の異なるアイテムを要素が表示するように、ページ上の要素を接続する。
要素をセットアップするには、ページに要素を追加して、[データに接続]アイコンを用いてそれらすべてを同じデータセットに接続します。また、コレクションからどのフィールドを表示するかを定義します。
訪問者が料理をスクロールできるボタンをページに追加する
訪問者がデータセット内の前または次のアイテムに移動できるように、ページにボタンを追加します。これらのボタンは、要素と同じデータセットに接続されている必要があります。
同期して変化するように要素を設定する
訪問者がページの前または次のボタンをクリックすると、すべての要素にコレクション内の同じアイテムに関するコンテンツが表示されます。これは、データセットが現在フォーカスされているアイテムを追跡し、同じデータセットに接続されているすべての要素が連携して動作するためです。要素の1つが現在フォーカスされているアイテムを変更すると、そのデータセットに接続されているすべての要素の要素が変更されます。
訪問者が無料の夕食にサインアップできるようにするレストラン用のフォームを作成するとします。ユーザ入力要素を使用して、訪問者から必要な情報を収集するようにフォー
ムを設定します。
ここでも、[データに接続]アイコンを使用して、各要素を同じデータセットに接続します。また、訪問者が各入力要素に入力したデータを保存するために使用するコレクション内のフィールドを定義します。
ヒント:
ユーザがコレクションに書き込みできるように、コレクションおよびデータセットのパーミッションを設定することをお忘れなく。
また、送信ボタンを作成する必要があります。フォームへの入力が完了したら、訪問者はこのボタンをクリックして、コレクションに情報を送信します。
このボタンは、ユーザ入力要素と同じデータセットに接続される必要もあります。
これは、データセットがコレクション内の現在のアイテムを追跡するために機能します。この場合、データセットはコレクション内の新しい空のアイテムを指しています。すべての要素が同じデータセットに接続されているため、それらはすべて同じアイテムに保存されます。
動的ページを作成すると、動的ページデータセットがページに自動的に追加されます。通常のデータセットと同様に、動的ページデータセットを使用すると、ページ要素をコレクションに接続できます。ただし、動的ページデータセットが通常のデータセットと異なる点がいくつかあります。
動的ページが表示できるコンテンツは、そのURLによって制御されます。このため、通常のデータセットとは異なり、動的ページデータセットでは、データセットが接続されるコレクションを変更できません。
URLはページが表示できるコンテンツを制御するため、コレクションのコンテンツのためのフィルタとしても機能します。ここでも、ページ設定でURL定義を変更することにより、コンテンツフィルタリングを変更します。動的ページデータセット設定を使用して、さらなるフィルタを追加したり、ページ上のコンテンツを並べ替えたりすることもできます。
また、ページから動的ページデータセットを削除することもできません。データセットを除去するには、動的ページを通常ページに変換する必要があります。
データベースコレクションについて
チュートリアル:データベースコレクションにユーザ入力を保存するフォームを作成する
コード要素および検索エンジンサポートを組み込むウェブサイト構築システム
もくじ
はじめに 1
関連出願 2
背景技術 2
システムの説明およびアーキテクチャ 3
コンセプトの詳細 7
付属書類一覧 10
1.本出願は、ウェブサイト構築システム(および他の視覚的編集システム)を対象とするものであり、検索エンジンによりインデックスされ得る、またSEOをサポートし得るウェブサイトを生成しながら、クライアントサイドおよびサーバサイドの両方において
ユーザ提供コード(UPC)の組み込みを実現する、洗練された視覚的編集ツールについて説明している。
2.本出願は、Wixコードのコンテキストで説明されている複数のコンセプトについて説明している。Wixコードは、Wix.Com Ltdが提供するWixウェブサイト構築システムの一部として開発されているサーバレスサイト開発プラットフォームである。以下の説明は、このようなシステムの包括的な説明を含む。Wixコードの実装は本コンセプトおよび技術の唯一の実施形態ではなく、本明細書の開示に従って追加の異なる実施形態を構築できることを明確にしておきたい。
3.本出願は、付属書類A1に記載されている特許出願を参照しており(または関連しており)、そのすべてが本出願の譲受人と同一の譲受人に譲渡されている。付属書類A1に記載されている特許出願および特許のそれぞれの開示は、その全体が明示的に本明細書に組み込まれる。
4.出願人は、クラウドエコシステムの欠陥を見出した。laaS(サービスとしてのインフラストラクチャ)、PaaS(サービスとしてのプラットフォーム)、およびSaaS(サービスとしてのソフトウェア)の状況によって、VM、コンテナおよびネットワーキング、バックエンド開発者向けの様々な種類のプラットフォーム、モバイル開発者向けのバックエンド、ならびに個人および企業向けの既製のソフトウェアのための解決策が提供されている。その中で欠けているのは、ウェブサイトおよびウェブアプリのためのプラットフォームである。
5.サーバレス(サーバレスコンピューティングとも呼ばれる)の登場している中で、この欠陥にはまだプレーヤがいない。出願人は、この欠陥にある程度対処するために、ウェブサイトおよびウェブアプリの開発およびデプロイのためのプラットフォームであるWixコードを開発した。このプラットフォームは、フロントエンドに最適化されたJavaScript、SEO互換性、WYSIWYGサイトビルダー、ウェブメソッド、およびバックエンドJavaScriptなどの要素ならびに要求時コンテナブートを提供する。
6.特に、本開示のシステムは、フロントエンドおよびバックエンドの両方のコードに対してウェブサイトに組み込まれた埋め込みコードを指定しながら、ウェブサイトを視覚的に作成する機能を提供する。このすべては、検索エンジンによりインデックスされ、SEO技法を適用するウェブサイトの機能を維持しながら実行できる。
7.ウェブサイト構築システムは、スタンドアロンシステムとすることもできるし、より大きな編集システム内に組み込むこともできる。また、ウェブサイト構築システムは、オンライン(すなわち、アプリケーションが編集され、サーバに保存される)とすることも、オフラインとすることも、部分的にオンライン(ウェブサイトはローカルで編集されるが中央サーバにアップロードされる)とすることもできる。本開示のシステムは、通常、オンラインのウェブサイト構築システムの一部であり得るが、他の種類のウェブサイト構築システムに組み込むこともできる。
8.視覚的デザイン環境に基づいた既存のウェブサイト構築プラットフォームは、通常、MicrosoftのOfficeスイートを操作するために必要なスキルセットなどのスキルセットを有するユーザを対象としている。しかしながら、こうしたユーザが構築しているのはサイトの5%のみである。
9.本開示のシステムは、作成するのにより高いレベルのスキルを通常必要とするより複雑なサイトをサポートする。このようなサイトは、通常、設計者、スクリプトライター、および開発者によって作成され、インターネット内のサイトの95%を含む。付属書類A2は、この範囲のサイト作成者およびサイトタイプをさらに説明するプレゼンテーションを含む。
10.付属書類A3は、例示的なシステムおよびその要素の詳細な内部技術説明を含む。
11.付属書類A4は、技術的なユーザ/開発者向けの例示的なシステムの内部技術説明を含む。
12.付属書類Bは、例示的なシステムの仕様とユーザ/開発者による使用法とを説明する、1セットのユーザ向けガイドおよびチュートリアルを含む。
13.付属書類Cは、例示的なシステムの全体的な紹介を提供する、1セットのプレゼンテーション、チュートリアル、およびビデオスクリプトを含む。
14.(基本的なWixシステムに加えて構築された)例示的なシステムの基本設計は、以下に説明する15のサブシステムから構成される。16番目の「サブシステム」は、サイト設計者から提供され、(適切なカプセル化および分離が適切に行われている)システムの一部として実行され得るユーザ提供コード(UPC)である。
15.これらの例示的なサブシステムは、クライアントサイドのプレゼンス、サーバサイドのプレゼンス、またはその両方を持つことができる。例示的なサブシステムは、中でも以下を含み得る。
16.これらの例示的なサブシステムおよびその例示的な機能は、次のように簡単に説明できる。
1
(サブシステム名)計算グリッド
(頭字語)CGD
(説明)
ドッカー(1)を実行するバックエンドサーバ:
・ドッカー内の部分を含まない。
・ドッカーのリサイクルおよびドッカーの高速起動を行う。
・エレメントリに特定のサービスを提供し得る。
(1)https://www.docker.com/what−docker
https://www.docker.com/what−container
2
(サブシステム名)エレメントリ
(頭字語)ELM
(説明)
各ドッカー内のアプリケーションサーバ:
・node.jsベース。
・クライアントサイドのスクリプトを準備するために使用。現在、これは計算グリッドの別のサービスとして外部に移動されている。
3
(サブシステム名)Wixデータ
(頭字語)WDT
(説明)
システムの基礎となるDBであり、以下を含む:
・クライアントおよびサーバAPIおよび実装。
・パーミッションシステム。
・フックシステム(カスタマイズ可能なコールバック)
・DBドライバ。基礎となるDB(以下のWix DBまたは代替的なDBなど)に接続する。
スキーマの使用について:
・単独で「ソフト」スキーマを使用。スキーマは上から提供される。
・スキーマは、APIにはなく、アプリケーションレベルにある。
・コンテンツマネージャは、スキーマとは異なるセルを有する場合がある。よって、「非準拠データを処理する」ユースケースを有する。
サンドボックスおよびライブの2つのDBインターフェースを提供する。単一のDBおよび2つ目のための差分で実装される。O(1)操作を保持する。以下のアルゴリズムに関するコメントを参照されたい。
4
(サブシステム名)ウェブメソッド/RPC
(頭字語)WBM
(説明)
クライアントからサーバへのRPC:
・Ajaxのための自動ラッパー
・セキュリティサービスを提供する。
・サーバからのエラーおよびログメッセージは自動的にクライアントに、すなわちブラウザコンソール(デバッグ用)に送信される。これによりデバッグ時に「単一システムイメージ」の感覚を提供する。
5
(サブシステム名)設定不要IDE
(頭字語)ZSI
(説明)
設定不要IDE:
・エディタに組み込まれたオンラインIDE
・コード補完をサポート
・メディアのための特定のサポート(画像/ビデオ/文書、URLなどのためのメディアマネージャを開く)
6
(サブシステム名)エディタプラットフォーム
(頭字語)EPT
(説明)
Wixサイトにアプリケーションを追加する新しい手法:
・ウェブワーカー(2)に基づく
・iframeにおけるウェブワーカー。アプリコードを実行する。
・コントローラ。Wixコンポーネントに接続する。
・APIへのインターフェースを含む。
・ルータ(インフラストラクチャ)を有する。コードバックエンド。ページのURLおよび選択を制御できる。
(2)https://en.wikipedia.org/wiki/Web_worker
7
(サブシステム名)クライアントサイドウェブワーカー
(頭字語)CSWW
(説明)
クライアントユーザコードを実行するクライアント上のウェブワーカー独立スレッド内のRTコードが:
・ウェブサイトを操作および修正するウェブワーカーiframeのコードを許可する一連のAPIから構成される。
・コンポーネントのデータの変更および可視性の変更に制限される場合がある。
・また、特定のアイテム(次のアイテム、アイテムX、...)を表示するためにギャラリーを変更するなど、一部のタイプのコンポーネントを制御できる。
・コンポーネントの追加/除去、コンポーネント属性の変更など、サイト自体の修正を含むように拡張できる。
8
(サブシステム名)ルータ
(頭字語)RTR
(説明)
ルータインフラストラクチャ。ユーザがルータコードを直接記述できる。
9
(サブシステム名)動的ページ
(頭字語)DYP
(説明)
独自のルータを持つアプリケーション。
ルータは、Wixデータのコレクションがあれば、アイテムおよびカテゴリページを作成し、データバインディングを介してデータを公開する。
これらは実際には、独自のURLで新しく作成されたページである。
これはすべてのルータの状況である。
他のページタイプにも拡張できる。
10
(サブシステム名)データバインディング
(頭字語)DBD
(説明)
独自のコントローラを定義するアプリケーション。そのコントローラが管理するのはデータセットであり、データベース内のデータをUIコンポーネントに接続する。
11
(サブシステム名)コンテンツマネージャ
(頭字語)CMGR
(説明)
WixデータのためのExcelのような編集ツール。
・ソフトスキーマをサポート。
・よって、システムは数値セル内に文字列値を持つことができる。セルは文字列表示機能を使用して表示されるが、赤い線でマークされます(スペルチェックと同様)。ホバー時に、文字列でポップアップを表示し、ユーザが修正できるようにする。
12
(サブシステム名)動的SEO
(頭字語)DSEO
(説明)
Wixコードのための完全なSEOソリューション。
・SEOを動的ページ、データバインディング、およびAPIに適用する。
・代わりに、サーバ環境で上記のワーカー(通常はクライアントで実行)を実行する。
・処理された検索エンジン対応ページを提供する。
13
(サブシステム名)計算関数
(頭字語)CFN
(説明)
関数をフロントエンドに直接公開するバックエンドの機能。関数を呼び出して応答を取得する。HTTP式バックエンド。
14
(サブシステム名)Wix DB/ドックストア
(頭字語)WDB
(説明)
システムの基礎となるスケールアウトMongo DB。データの外部管理シャーディング(3)をサポートする。
(3)https://en.wikipedia.org/wiki/Shard_(database_architechture)
15
(サブシステム名)$W API
(頭字語)$WAPI
(説明)
サイトのビジュアルに影響を与えるためにユーザが使用するAPI:
・コンポーネント属性、可視性などに影響を与えるDBDが使用するメインチャネル。
・jQueryに類似。
−
(サブシステム名)UPC
(頭字語)UPC
(説明)
ユーザ提供コード:
・これは、ウェブサイトの一部としてユーザにより記述または提供される実際のコードである。
・ウェブワーカー内で実行される。通常クライアントで実行されるが、SEOのためにサーバで実行されてもよい。
17.様々なサブシステム間の関係は、次のように視覚化され得る。
18.これらの例示的なサブシステムのそれぞれの詳細な説明は、付属書類A5に含まれる。
19.付属書類A6は、上記のWDTの一実施形態を実装するための特定の「データベースオーバーレイ」アルゴリズムを含む。代替的な実施形態は、「マイナスDB」を使用する代わりに、議論された「プラスDB」で「廃棄記録」(削除された記録を意味する)を使用し得る。
20.出願人は、本明細書でより詳細に説明されるいくつかの領域、機能、および能力を見出した。これらには次のものを含む。
20.1.オンラインウェブサイト構築環境でのカスタムバックエンド機能。
20.2.データベースで入力されるウェブページの動的プレビュー。
20.3.仮想ウェブページのプレビュー中におけるデータベースの編集
20.4.ウェブサイトホスティングのためのオンデマンドウェブサーバ実行インスタンス
20.5.ウェブサイトのライブ運用およびテストのための共通データベース。
20.6.自動レイアウト推奨エンジン(マジックレイアウト)。
20.7.SEOを改善するための自動ウェブサイト設計推奨。
20.8.分離されたユーザアップロードプラグインは、共同ホストされたウェブサイトにわたる感染を回避する。
20.9.ウェブサイトのためのユーザアップロードプラグインを分離する。
20.10.ユーザ提供プラグインがオンラインエディタの機能を拡張する。
20.11.設計ツールから分離したiFrameエディタインターフェース。
21.付属書類Dは、これらのコンセプトのそれぞれに関するさらなる詳細および開示を提供する。
以下は、いくつかのコンセプトに関する特定の追加の明確化である。
22.オンラインウェブサイト構築環境でのカスタムバックエンド機能。
22.1.システムは、生成されたページのHEADタグに含まれるスクリプトまたはマーカを介して、特定の検索エンジンスパイダーサポートを提供し得る。
22.2.このようなマーカまたはスクリプトは、スパイダーが特定の専用ウェブサービスを使用するように誘導し、ページをインデックス可能にするのに役立つ。
23.ウェブサイトホスティングのためのオンデマンドウェブサーバ実行インスタンス
23.1.本コンセプトは、特定のサイトのために構成されたウェブサーバインスタンスを実行し(特定のプラグインおよびこのサイトのサーバサイドのユーザ提供コードを含む)、かつタイムアウトなしで、またユーザが許容できる合計時間枠内でのHTTP要求への応答を十分な速さで行う、ドッカーコンテナの高速ブートを含む。
23.2.通常、仮想マシンの起動には数分かかる。ドッカーコンテナの起動には依然として2〜3分かかる。これらの時間の両方とも許容可能ではない。
23.3.本開示のシステムでは、すべての関連するサイト固有ではないコードを含むが、ユーザ/サイト固有のコードを含まないスタンバイドッカー(例えば、コンテナ)のプールが提供される。
23.4.本システムは、特定のウェブサイトのサーバに接続する要求をライブポートでリッスンし得る。特定のウェブサイトに関連付けられているライブドッカーがある場合、本システムはそれに接続し得る。それ以外の場合は、プールからのスタンバイドッカーを使用し、要求されたコンテンツをプールに投入するか、そのようなコンテンツをロードするように指示することができる。
23.5.サイトが所与の期間(15分など)アクティブでない場合、システムはスタンバイコンテナをドロップし得る。
24.ウェブサイトのライブ運用およびテストのための共通データベース:
24.1.このコンセプトは、同じDB上でステージングおよびライブデータを実行することが含まれる。
24.2.上記のように、例示的なアルゴリズムが付属書類A6に詳述されている。
24.3.開発システムがDBに書き込むと、データのコピーが作成され得る。このコピーは、開発システムから見えるものであり得る。開発データはライブサイトでは表示されない場合がある。
25.ウェブサイトのためのユーザアップロードプラグインを分離する:
25.1.このコンセプトでは、iFrameを使用して1つのサイトからコンテンツを取得し、別のサイトに安全に組み込む方法について説明する。しかしながら、このようなコンテンツの組み込みは、次のようないくつかの方法を使用して実装され得る。
25.1.1.AJAXを介してコンテンツを転送すること。
25.1.2.静的コード分析の対象となるリモートコンテンツを直接含めること。例えば、JSコードを分析して安全かどうかを確認する。
25.2.本開示のシステムは、プラグインコードを実行するためにより小さい(かつ通常は非表示である)iframeを使用するが、プラグインUI自体はウェブサイト構築システムにネイティブであり得る。
これは、TPAのUIの一部または全部がiFrameに実装されているTPA(サードパーティアプリケーション)で使用される構成とは異なるが、TPAはTPAをホスト
するページ内の他のネイティブコンポーネントと依然として通信できる(TACA Wix特許出願で説明されているように。付属書類A1参照)。
25.3.プラグインはまた、プラグインがユーザ提供のコード(クライアントサイドでのみ実行される)のみを通常含むという点で、TPAとは異なる。一方、TPAコードはTPAプロバイダサーバで実行される。
25.4.よって、本開示のシステムは以下の利点を提供し得る。
25.4.1.プラグインをサイトにインストールできるようにし、これにより、機能が追加されるが、コードの分離に起因してウェブサイト自体が危険にさらされることはない。
25.4.2.プラグインはサイトのクッキーおよびDOMにアクセスできない。また、ウェブコンポーネント(4)または同様のシステムにより提供される(制限された)カプセル化のように、このセキュリティ対策をバイパスすることはできない。
(4)htts://www.webcomponents.org/
25.4.3.本開示のシステムにより、(例えば、プラグインを別々のiFrameに配置することなどにより)複数のプラグインをインストールできるため、互いに干渉することはない。
25.4.4.本開示のシステムにより、両方に単一のiFrameを使用したり、複数のiFrame間でAPIを使用したりして、別のプラグインを拡張するプラグインをインストールできる。このようなプラグインは、互いに分離またはサンドボックス化されておらず、例えば、同じベンダが提供するプラグインファミリの一部であり得る。
25.4.5.本開示のシステムは、サイト自体から切り離されたリッチAPIを備えた安全なプラグインサブ領域を提供することができ、同じ領域に複数のプラグインを配置できるようにし、上記の$w APIを介してリッチAPIをサポートする(場合により、TACA特許出願で説明されているように、制御されたクロスiFrame APIを使用する。付属書類A1参照)。
25.5.この構成は、iFrameには開発されたAPIがなく、ホスティングWBS(ウェブサイト構築システム)またはWBSページとやり取りしないために、通常のiFrameとは異なる。また、CSRF(クロスサイトリクエストフォージェリ)、クッキー窃取、XSS(クロスサイトスクリプティング)の防止にも効果的である。ただし、使用できるのはオンラインWBSのみである。
25.6.これは既存の従来技術のシステムとは対照的であり、従来のシステムは通常、正しく記述されたプラグインに依拠するか、特定のプラグインに制限されている。
25.7.本実装は、例えば、PostMsgのためのゲートウェイへのフックに依拠し、特定のメッセージをフィルタリングし得る。よって、本開示のシステムはまた、ユーザが任意のプラグインに付与されたアクセスパーミッションを正確に制御できるようにするユーザ指向のパーミッション技法も実装できる。これは、スマートフォンのオペレーティングシステムが、インストールされているアプリケーションに付与されるアクセスパーミッションを正確に制御する仕方に似ている(例えば、「アプリXYZはGPSを使用できますか?/連絡先にアクセスできますか?」)ただし、これはインストール前にプラグインのコピーをダウンロードする必要なく行われる。
25.8.本開示のシステムは、オンラインWBSとして、プラグインが更新されるとすぐにプラグインのすべてのインストールが更新され、プラグインを1か所に格納し得ることにさらに留意されたい。これは、各プラグインのインストールが別個であり、それ自体で更新する必要がある既存のオフラインの従来のシステムとは対照的である。
計算グリッド
Wixコードの計算グリッド
目的および機能
グリッドにはWixコードの2つの主要な機能がある。
・フロントエンドおよびバックエンドのコードを開発する場合、エディタモードであり、エディタモードは、安全なマルチテナント方式でのプレビューのためにフロントエンドコードのバンドルとバックエンドコードの実行を提供しながら、ソースコードの基礎となるファイルシステムを提供する。
・パブリック表示では、パブリックモードのユーザバックエンドコードのための高速で安全なマルチテナント方式の信頼できるエグゼキュータ。
目的
・クラウドランタイムの実行は、コンピューティンググリッドの存在の唯一の目的である。
・クラウドランタイムコンテナは、信頼性、高速性、および安全性を備えるように設計されている。
・クラウドランタイムコンテナは、単一ノードJSプロセスを実行する軽量コンテナである。
・コンテナがユーザコードを提供する準備が整うのに比較的長い時間がかかるため、そのためのスタンバイコンテナのプールを維持する。
・オンデマンド機能を提供するために常に十分なスタンバイコンテナがあることを確認することは、クラウドライフサイクルの役割である(以下を参照)。
・パブリック(編集しない)モードでは、
○コンテナは完全に廃棄可能である。
○システムは、ユーザコードが実行されているコンテナを100ミリ秒未満でプロビジョンできる。
・編集モードでは、
○ユーザコードは、定期的に自動的にアーカイブされる。
○コードの編集はクラウドランタイムコンテナが実行されているのと同じファイルシ
ステムで行われるため、ユーザはコードをすぐに実行してプレビューできる。
・クラウドランタイムコンテナは1つのアプリケーションのみを実行するため、コンテンツリークは発生しない。
・コンテナは、静的にリンクされたノードJSバイナリのみを含む。
・コンテナのルートファイルシステムは読み取り専用である。
・各コンテナは一意のユーザIDで実行される。
・ユーザコードはホストワーカーによってコンテナの外部から投入される。
・コンテナはコードにアクセスできないが、コードが割り当てられているユーザはアクセスできる。
・ユーザコードファイルシステムは実行パーミッションを持たない。
・ディスククオータ、メモリ、CPU、ネットワーク、および他のシステムリソースクオータ制限がコンテナに適用される。
・クラウドライフサイクルはグリッドホストの外部であるが、このコンテキストで言及するに値する。その機能は、Wixコードの計算グリッドを制御および管理することである。
・ライフサイクルは、グリッドホスト上の2つのコンポーネントを使用して、ホストおよびクラウドランタイムコンテナを管理する。
a.ドッカーデーモン。ホストワーカーおよびクラウドランタイムコンテナを開始、停止、および制御する。
b.ホストワーカー。クラウドランタイムコンテナファイルシステムのパーミッション、クオータ、およびアーカイブ機能を管理する。
・このドキュメントに関連するのは、クラウドランタイムが使用している各ユーザコードごとにUNIX(登録商標) UIDを割り当てるライフサイクル機能である。
計算グリッドは、Wixコードライフサイクルサービスによって管理される3つの主要コンポーネントで構築される。グリッド上の各ホストは、次のコンポーネントを有する。
1.ドッカーデーモン
2.(ドッカーコンテナ内の)ホストワーカー
3.(ドッカーコンテナ内の)クラウドランタイム(旧エレメントリ)
・グリッドホストが稼働を開始すると、グリッドホストIPを、その定義されたリソース、すなわちCPUおよびメモリと共にメッセージコンテナに送信することにより、自身をライフサイクルに登録する。
・グリッドホストには、クラウドライフサイクルを管理するために、動作中のドッカーデーモンがインストールされ、実行されている必要がある。
ホストワーカーは、クラウドライフサイクルがホストを管理するために使用するコンポーネントの一部である。これには2つの役割がある。
1.ライフサイクル機能を拡張して、システムのパーミッション、クオータ、ネットワーク、ファイルシステム、およびコードアーカイブを管理および操作する。
2.ユーザがWixエディタでコードを編集する際に、エディタにAPIのようなファイルシステムを提供する。
1.クラウドランタイムコンテナ作成前
a.ユーザコードのためのディレクトリを作成する。
b.適切なパーミッションおよびディスククオータを設定する。
2.クラウドランタイムコンテナが「ウォーム」で作動した後
a.コンテナにネットワークトラフィックの実施を設定する
b.ユーザがコードを編集している間に、ユーザコードを定期的に自動アーカイブする。
3.クラウドライフサイクルがコンテナの停止を決定した場合に、
a.ユーザコードを保存してデータベースにアップロードする(エディタモードで)。
4.ライフサイクルによりスケジュールされた定期的なタスクを実行する。
a.「感染した」コンテナを見つけ、キルする。
b.コードがアーカイブされた後、ディスクをクリーンアップする。
上述のように、ホストワーカーの他の役割は、エディタに仮想ファイルシステム(VFS)APIを提供することである。その意味でのホストワーカーの役割は次のとおりである。
1.次のような基本的なファイルシステム操作を提供する。
a.ファイルおよびディレクトリの作成、更新、読み取り、削除操作。
2.上記の操作が、クオータおよびパーミッションの制限を維持しながら許可されたユーザに代わってのみ行われることを確認する。
エレメントリ
Wixコード−クラウドランタイム/エレメントリ
概要
クラウドランタイム(別名エレメントリ)は、プレビューおよび表示のモードの両方の編集のためのユーザ要求を処理するnode.jsベースのサービスである。サービスは、複数のシナリオでユーザコードを実行し、ユーザクライアントコードを処理およびトランスパイルする役割を果たす。
・ウェブメソッド。サブプロジェクト#4ドキュメントで指定されている。
・動的ルータ。サブプロジェクト#8ドキュメントで指定されている。
・Wixデータ。サブプロジェクト#3ドキュメントで指定されている。
・Wixエンドポイント(計算関数)。サブプロジェクト#13ドキュメントで指定されている。
・静的ファイル。ユーザコードをトランスパイル、バンドル、および処理する。
サービスは内部モジュールと外部モジュールとに分離され、ユーザコードは外部モジュールにマウントされ、ユーザはそこからwixライブラリ(wix−data、wix−routers、wix−endpoints、wix−fetch)にアクセスできる。
ユーザが外部モジュールのみにアクセスするように制限するために、サービスはスコープ指定を要するモジュール(wixが開発したオープンソースプロジェクト)を使用する。
Wixコードにより、ユーザは最新のECMAScript(現時点ではES2017
まで)機能を使用してコードを記述でき、クラウドランタイムの役割のうちの1つは、ランタイム環境によってこのコードをJavaScriptのサポートバージョンにトランスパイルすることである。
・クライアントサイドコード。クラウドランタイムには.jsファイルおよび.mapファイルを要求するためのエンドポイントがあり、サービスはクライアントサイドコードをトランスパイルおよびバンドルするために同じコアライブラリをクラウドバンドラサーバと共有している。
・バックエンドコード。ECNAScriptの最新機能はnode(v6.11.0)の現在のLTSバージョンではサポートされておらず、サービスは必要なファイルのトランスパイルを遅延評価するためにバベルレジスタを使用する。
ユーザは、ウェブメソッド、wix−dataフック、カスタムルータ、データバインディングルータフック、および計算関数を使用して、最終的にクラウドランタイムサービスで実行する必要があるバックエンドコードを作成できる。
クラウドランタイムは、ユーザコードをコンテキストでラップするためにノードドメインを使用し、これによりユーザコードのスタックトレースおよびログをキャプチャできる。
Wixデータ
Wixデータ
WixデータAPI
WixデータAPI。データベースへのアクセスに使用される。WixデータAPIは、クライアントサイドのブラウザコード(CSWWを参照)とユーザバックエンドコード(ELMを参照)との両方で使用される。ルータのドキュメントはこちらで参照できる。
WixデータAPIモジュールはまた、データ変換およびエラー処理も実行する。
WixデータAPIは、ウェブメソッドプロトコル(WBMを参照)を使用してWixデータプロバイダと通信する。
Wixデータプロバイダ。APIの実装である。ユーザが自分のバックエンドコードを持たない場合、実装はクラウドマルチテナントサーバでAPI要求を実行して処理するか、ユーザドッカーコンテナで実行される(ELWを参照)。Wixデータプロバイダは、必要なWixデータロジックを実行する。
・認証を処理する。パーミッションの構成は、各ロール(サイト所有者、データ所有者、誰でも)が持つパーミッション(読み取り、挿入、更新、削除)を定義します。
・フックを処理する。フックにより、ユーザコードはAPIを介して実行されるWixデータ要求をインターセプトおよび修正できる(こちらの文書を参照)。
・必要なクエリおよびデータ変換を実行して、高度なWixデータ機能をサポートする。
○削除されたフィールドを結果から非表示にし、フィルタリングする。
○結果として得られるオブジェクトを計算フィールドで強化する(計算フィールドはスキーマで定義された特別なフィールドであり、既存のフィールドデータに基づいて新しいフィールドを生成できる)。
○参照されたコレクションアイテムを結合する。
○保存されるドキュメントを所有者識別で強化する。
Wixデータプロバイダは、VFSに格納されたスキーマおよびパーミッションを認識している。
ドックストア。MongoDBとWixデータプロバイダとの間のブリッジとして機能するサービス。
・WixデータからMongo形式へのクエリ変換を実行する。
・データベースのコピー機能およびデータ同期機能を含む(これによりサンドボックスからライブおよびテンプレートからユーザサイトにデータを同期できる)。
・IDを生成し、ドキュメントの作成時間および更新時間を格納することにより、データの強化を実行する。
出願人らの知る限り、どのプロジェクトでも(コピーのように)オープンソースコードを直接使用することはない。
WixデータAPIおよびWixデータプロバイダで使用されるオープンソースライブラリは次のとおりである。
ウェブメソッド/RPC
WBMウェブメソッド/RPC
ウェブメソッドは、ネットワークを介して呼び出され得る、ECMAScriptモジュールからエクスポートされた関数である(このようなモジュールはウェブモジュールと呼ばれる)。これは、エンドユーザのブラウザ内のCSWWで実行されるコードがELMで実行されるコードとシームレスにやり取りできるようにするメカニズムである。このメカニズムは、どのロールがどのウェブメソッドを呼び出すことを許可されているかの認証を処理し、要求スコープ指定情報をウェブメソッドに投入し、エラーを伝播し、ブラウザコンソールに記録されるCSWWに記録する。加えて、同じECMAScriptモジュールインポート構文を使用して、CSWWおよびELMの両方のユーザコードから同じコードを呼び出すことができる。この手法により、アプリケーションをデバッグおよび開発する際の「単一イメージシステム」の感覚が得られる。
ウェブメソッドのサーバ部分はELM内で実行され、RTRフックおよびカスタムルータ、WDTフック、CFNなど、ELMで実行されるユーザコードからプロミスを返す通常の関数として自由に呼び出すことができる。WBMはまた、WDTのためのRPCメカニズムとしても使用されて、バックエンドコードおよびページコードで同じように使用できるようにする。プロミスを返す通常の関数としてウェブメソッドを呼び出すためのJavaScriptプロキシは、ユーザコードにバンドルされ、CSWW内で実行される。
このメカニズムは、次のコンポーネントによって実装される。
・ウェブメソッドドメイン。要求スコープ指定情報をnode.jsドメインにアタッチし、これは、後でウェブモジュールエクステンションによって生成された関数によって取得され、加えてnode.jsのデフォルトのロギング関数をオーバーライドして、このドメインにログを収集する。
・ウェブモジュールエクステンション。バベルレジスタを使用して、グローバル要求関数の動作をオーバーライドして、ECMScript 2015コードをELMで使用されるノードのターゲットバージョンに変換し、ユーザウェブモジュールからエクスポートされた関数をラップするために要求メカニズムにフックする。
・ウェブメソッドエクスプレスルータ。エレメントリサポートから到来する要求のためのELMへのエントリポイントである。CSWWからのウェブメソッド呼び出しの認証を
処理する。また、ウェブメソッドの実行が終了すると、ウェブメソッドの実行中に収集されたログを転送する。
・エレメントリサポート。ワイヤプロトコルを介したウェブメソッドのクライアントサイドを提供する。CSWWで実行され、ウェブメソッドプロキシによって呼び出される。また、エレメントリから受信したログもユーザのブラウザコンソールに出力する。
・ウェブメソッドプロキシは、ウェブモジュールの静的分析を実行して、エクスポートされる関数を決定することにより生成される。これらは、CSWW内で実行するためのユーザコードにバンドルされる。
ウェブメソッドのロードおよび実行は、babel−preset−es2015−node6と共にバベルレジスタを使用して実装される。スコープ指定要求は、ユーザコードからインポートされ得るモジュールのファイルシステムの場所を変更するために使用される。ウェブメソッドプロキシは、Acornパーサを使用して静的分析を実行し、生成されたプロキシをBrowserifyを使用してユーザページコードとバンドルすることで生成される。エレメントリサポートおよびウェブメソッドエクスプレスルータにより使用されるオーバーザワイヤプロトコルは、ネイティブJavaScript Datesを処理するための拡張機能を備えたJSONに基づいている。
設定不要IDE
IDE
IDEコンポーネントは、Wixエディタに組み込まれたオンラインコードエディタである。
既存のサイトページのコードを編集したり、Wixコードファイルシステムに存在するファイル(パブリックおよびバックエンドファイル)を編集したりするために使用できる。
IDEはまた、リッチなコンテキストコード補完、Wixメディアマネージャの組み込み、コードの書式設定、カスタム警告およびエラーも提供する。
これらのカスタム機能はすべて、Orionと呼ばれる既存のオープンソースIDEの上に構築されている。
IDEは、標準のJavaScript環境およびWixコードAPIの両方に対して、リッチなコード補完をユーザに提供する。
コード補完は、以下の補完を提案できる。
1.WixコードコンポーネントAPI($w)。現在のページに存在する要素に応じて提案、例えば「$w(’#button1’)」を提示する。つまり、ユーザには、現在のページに存在する要素についてのみ提案が表示され、他のページの要素については表示されない。これらの提案は、通常のパブリック/バックエンドファイルには表示されず、ページコードを編集する場合にのみ表示される。
2.「wix−data」、「wix−window」など、コードのコンテキストに依存しないWixコードの一般的なAPI。つまり、ページのコードを編集するとき、または通常のパブリック/バックエンドファイルにおいて利用可能である。
3.JSオブジェクトおよび関数、例えば「console.log()」もまた、すべてのファイルタイプで利用可能である。
4.テンプレート。モジュールのインポート(例えば、「’wix−location’から場所をインポートする」)と、forループなどのJS共通テンプレートと、の両方のテンプレート提案を提供する。
5.関数パラメータ。関数のパラメータおよび名前を提示する。
コード補完ウィジェットはまた、選択されたすべての提案の簡単な説明を完全なドキュメントへのリンクと共に提供する。
ユーザは、画像要素のソースを変更するコードをサイトに追加できる。つまり、実際に表示されるイメージを置き換える。ユーザは、画像のソースプロパティを任意の画像URLに、またはWixメディアマネージャからの画像に設定できる。ソースプロパティを設定しようとする場合、コード補完ウィジェットはメディアマネージャを開くことを提案します。そこで、ユーザは画像を選択でき、そのURL(カスタムWixコードURLプロトコル)がコードに貼り付けられる。例えば、「$w(”#image1”).src=”image://v1/6e7958de786842eb811149ac9c25f73c.jpg/2362_4724/Cotton Candy Cone”」。ユーザはまた、URLにカーソルを合わせることができ、画像を表示するツールチップが開き、画像を置き換えるメディアマネージャを開くためのリンクが表示される。
IDEは、オープンソースプロジェクトOrion[https://wiki.eclipse.org/Orion]の上に構築される。独自のカスタムエクスペリエンスとWix固有のバグ修正と動作の変更を提供するために、Orionからの特定のモジュ
ールを独自のモジュールでオーバーライドする。元のOrionコードを修正する代わりに、カスタムモジュールの読み込み構成があり、これは、元のモジュールの代わりにオーバーライドするモジュールをロードすることを把握し、コードを元のソースコードから分離する。
OrionおよびOrionの依存関係を除き、プロダクションコードでは他のライブラリまたはパッケージを使用しない。
コードを構築してテストするために、無数のオープンソースパッケージ、例えばgrunt、mocha、karma、selenium−webdriver、lodashなどを使用する。これらのパッケージのためのコードは開発時にのみ使用され、最終製品の一部としては出荷されない。
コード補完を提供するために、内部モジュール「wixコード参照ドック」に依存している。このモジュールは、API($wなど)を公開するすべてのWixコードライブラリに依存し、コード補完を提供するために必要なすべての情報を保持する1つの大きなファイルを構築する。このファイルは、構築プロセス中にコピーされ、IDEによって実行時に使用される。
コード全体はJavaScriptで記述される。
エディタプラットフォーム
エディタプラットフォーム
クライアントサイドウェブワーカーおよびSDKを使用することにより、ウェブアプリケーションでカスタムコードを実行させることができる。このプラットフォームにより、再利用可能なコードを記述でき、したがって、同じウェブアプリケーション内で、また複数のウェブアプリケーションにわたって複数のインスタンスに配信することができる。このプラットフォームは、次のコンポーネントから構成される。
・アプリグローバルエンティティ:パート間での共有状態。
・ルータ:URLおよびページ解像度の制御。
・コントローラ:アプリのロジックチャンク、複数のインスタンス。
・API:すべての公開および混合。
アプリケーションのグローバル状態により、次のようなシナリオが可能になる。
・ショッピングカート、多段階の購入エクスペリエンス中のアイテムの集約
・複数ページのウィザードエクスペリエンス
・多段階のチェックアウトエクスペリエンス(カート、配送情報、アカウント情報)
・終了後にすべての情報を保存するオーサリングエクスペリエンス
このプラットフォームにより、ユーザコードがアプリケーションのグローバル状態を保存できて、上記のシナリオを可能し得る。また、クライアントのウェブワーカーがアプリケーションのロジック態様に影響を与えずにページの遷移およびクリーンアップを実装するための抽象化も提供する。
アプリケーションはルータを作成し(セクション8を参照)、これをウェブサイトに登録できる。アプリケーションは構成情報をウェブサイトに保存でき、これにより、アプリケーション開発者はルータのための単一サーバエンドポイントを作成でき、分散ターゲットごとに複数の構成をとることができる。ブログのルーティング要件の例は次のとおりであり得る。
1.domain.com/blog/2016/07/26/my−post
→1.「my post」を表示する一般的な投稿ページ
2.domain.com/blog/2016/07/26
→2.2016年7月26日からのすべての投稿
3.domain.com/blog/2016/07
→3.2016年7月からの最初の10件の投稿
4.domain.com/blog/2016/07?page=2
→4.2016年7月からの#11〜#20の投稿
5.domin.com/blog/tag/a−tag−i−use−a−lot
→5.「a−tag−i...」とタグ付けされた最初の10件の投稿。
6.domain.com/blog/category/my−category
→6.「my cat..」というカテゴリからの最初の10件の投稿
7.domain.com/blog/2016/07/26/my−100th−post
→7.第100番目の投稿のためにデザインされた特別な投稿ページ
アプリケーションがルータを構成し、これをインスタンス/サイトごとに保存できるようにすることにより、ルータサーバコードが1回作成され、URL構造は同じでも異なるURL形式(日付あり/なし)および特定の投稿のための特定のページをサポートできる。一般的な使用法は次のとおりである。
・特異性に基づいたカスケードページテンプレート(すなわち、アイテム→製品→デジタルグッズ)
・SEO(検索エンジン最適化)要件に基づく様々なURL形式
・CMS(コンテンツ管理システム)においてコンテンツを追加することによるページの追加
コントローラにより、ユーザコードの作成者は、コードをコンポーネントのリストと共に再利用可能な仕方でパッケージ化できる。通常の(Wixコード)メソッドでは、ユーザはページに一意のIDに基づいてコンポーネントにアクセスする。このことは、同じページで2回まで使用するオプションを減らし、配信が困難にする。コントローラには次のプロパティがある。
・構成であり、サイトに保存する。この構成により、コントローラのインスタンスを別のインスタンスと区別する仕方が提供されるため、コードを再利用できる。例えば、コントローラコードが外部データソースに接続し、情報を取得し、画像およびテキストを使用してそれを提示する場合、構成はリモートシステムにおけるアイテムIDになる。このように、同じページ上の2つの別個のコントローラは、異なる画像およびテキストコンポーネントを使用して、リモートシステムにおいて2つのアイテムを表すことができる。
・ロール(文字列)を名前として使用し、接続構成を使用したコンポーネントへの接続。これにより、コンポーネントがページで受け取るIDに関係なく、コントローラコードを事前に記述してから配信できる。これは、同じIDを持つことができない2つの異なるコンポーネントにアクセスする同じページ上の2つ以上のコントローラに特に役立つ。ほとんどの場合、コントローラはロールを使用して操作するためにコンポーネントを選択する(セクション15のセレクタを参照)。各コンポーネントには複数のロールを定義して、複雑なデータバインディングシナリオと行動プログラミングモデルを実現できるが、複数のコントローラは定義できない。(つまり、各コントローラはコンポーネントの異なる態様を担当する。例えば、ドロップダウンコンポーネントは1つのコントローラからオプションのリストを取得し、選択したパラメータを別のコントローラに保存できる)。
各コントローラは、独自のAPIを公開できる。これにより、コントローラがコンポーネントとして表示され、同様の動作が行われる。サイトレベルまたは他のコントローラの他のコード作成者がコントローラコードをブラックボックスとして再利用できるようにし、コントローラをランタイム環境の拡張ブロックに変える。
クライアントサイドウェブワーカー
クライアントサイドウェブワーカー
クライアントサイドウェブワーカーにより、カスタム機能を使用してウェブサイトを拡張できる。その拡張の最も一般的な使用法は次のとおりである。
・サイトの動的コンテンツ強化
・カスタムユーザフロー
・カスタム対話
これを可能にするために、SLA、セキュリティ、およびこれらの拡張機能をユニファイドクラウドでホストする能力を維持しながら、次のアーキテクチャが使用される。
以下は、システムの論理コンポーネントのリストである。
・サイトトップフレーム:これはウェブアプリケーションのメインページである。ユーザのドメインまたはホスティングサービスの一般的なドメイン(Wix)で提供される。これはウェブアプリケーションを実行するメインエンジンであり、別名「ビューア」または「ランタイム環境」である。
・IFrameサンドボックス:悪意のあるコード(クッキーハイジャックなど)からトップフレームのセキュリティを保護するために、異なるドメインを持つIFrameが構築される。ドメインの違いは、サンドボックスシステムリソース(ウィンドウ、クッキーなど)およびメモリである(すべての通信はpostMessageのみを使用して実行でき、メモリ共有は使用できない)。
・ウェブワーカー:ウェブワーカーは、非同期コードの実行を可能にする標準的なブラウザ機能である。すべての通信はpostMessageを介して可能であり、ウェブワーカーでグローバルに利用可能なAPIサーフェスはトップフレームよりもはるかに制限されているため、ウェブワーカーはトップフレームに別の保護レイヤを作成する。例えば、ウィンドウグローバルオブジェクトは利用可能ではなく、DOM(ドキュメントオブジェクトモデル)アクセスは禁止されており、つまり、ウェブワーカーコードはUI要素を操作できない。ウェブワーカーのセキュリティ上の利点に加えて、非同期の性質により、ウェブワーカーがCPUを集中的に使用している場合でもトップフレームが応答を停止することはないことが確保される。別の利点は、トップフレーム実行コンテキストを遮るこ
となくユーザコード(ウェブワーカーで実行中のコード)をデバッグおよび一時停止でき、ユーザが、ブレークポイント中でも、UIレイヤにおいてユーザコードの伝播を確認できることである。
・RMI(リモートモデルインターフェース):このコンポーネントは、トップフレームの論理モデルを作成および維持し、postMessageトランスポートレイヤを介してウェブワーカーと共有する役割を果たす。モデルの変更は、ウェブアプリケーションに影響を与える。例えば、ボタンのテキストおよびリンクはモデルで表される。モデル内のこれらの値の変更は、視覚的なボタンコンポーネントおよびその機能に影響を与える。加えて、RMIレイヤにより、ウェブワーカーがトップフレームで事前定義されたメソッドを呼び出すことができる。これは、ウェブワーカーの機能を強化し、モデル(すなわち、アニメーション)で表されるように、状態に関連しないアクションを実行するために使用される。リモートモデルは非同期バリアをブリッジし、同期コードをユーザコードが認識できるようにし、これは、記述は単純であるが、アクションは非同期である。例えば、ユーザコードは画像URLをAからBに変更する。コードの次の行は、次のアクションを決定するための値を示す。モデルの値は既にAからBに変更されているため、一貫した値であるBを返すが、モデルの非同期動作は、ウェブアプリケーションのUIに既に表示されていることを保証しない。
・SDK:SDKは、RMIモデルの上にあるラッピングレイヤである。より単純なAPIをユーザコードに公開し、モデルを一貫性のあるドキュメント化されたメソッド呼び出しならびにプロパティセッターおよびゲッターに簡素化するために使用される。ライフサイクルメソッドおよび$wオブジェクトをユーザコードのベースコンテキストとして公開する。詳細な説明は、セクション15で提供される。
ルータ
RTR ルータ
ルータにより、サイト所有者がサイトのカスタムURL構造を定義できる。ルータは、特定のURLをページに解決するために動的ページによって使用され、サイトマップ要求を介してサイトで利用可能なすべてのページを取得するためにSEOおよびエディタによって使用される。ルータはまた、ページに関連付けられる追加のSEO情報も公開する。ルータには2つのタイプ、すなわちデータバインディングルータおよびカスタムルータがある。ルータはELM内で実行されるバックエンドコンポーネントである。
データバインディングルータは、サイト所有者から提供された1つ以上のデータベースフィールドおよびカスタムテキストフラグメントに基づいてURL構造を自動的に接続する。これは、エディタのUIを使用して完全に実行でき、ユーザコードは必要としない。加えて、これらのルータはフックによってカスタマイズされ、これにより、ユーザコードがルータに渡されるパラメータを修正し、応答を修正し、WDTに発行されたクエリを修正できる。
カスタムルータは、サイトの所有者にURL構造の完全な制御を提供する。エディタから、サイトの所有者は特定のプレフィックスのためのルータを作成でき、URLの残りの部分がカスタムルータによって解釈される。ルータ要求は、ユーザが提供する2つの関数、すなわちルータ関数およびサイトマップ関数により処理される。ルータ関数は、単一のURLの特定のページへの解決を処理する。WixルータAPIは、この要求に渡されるデータを説明している。この関数は、追加のSEO情報と共に、APIで事前定義された応答(例えば、OK、見つかりません、禁止など)のうちの1つを返すことが期待されている。サイトマップ関数は、ルートで利用可能なすべてのページをリストすることが期待されていることを除いて同様である。
動的ルーティングは、2つのコラボレータによって実現され、1つはユーザのブラウザで実行され、もう1つはバックエンドで実行される。動的ルータにより処理されるURLを介してページがロードされると、ブラウザにデフォルトのHTMLページがロードされ
、表示するページを判定するためにバックエンドに対してAJAX要求が行われる。コードのバックエンド部分は、どのプレフィックスがどのルータで処理されるかを認識していない。ルータが表示することを選択できるページを含む、URLを解決するために必要なすべてのデータはこの要求で送信され、バックエンドからの応答は、ページの適切な動的ページを開き、それにデータを投入するために使用される。ルータは、ページが開かれるときにページに公開されるデータを入力することを選択でき、そのため、サーバへの別のラウンドトリップを回避できる。
ルータ−詳細
動的ルーティング
データバインディングルータ
カスタムルーティング
はじめに
動的ルーティングモデル
動的ルーティングモデルの基本コンポーネント
ルーティングのさらなる詳細な説明
ルータエンドポイント
URL解決エンドポイント
URL解決エンドポイント入力
URL解決エンドポイント出力
ページロールの詳細
サイトマップエンドポイント
サイトマップを正しく実装する
ユーザクレデンシャルの考慮
404応答コードを返すことになるURLの考慮
ルートの考慮
動的ページ上の「ノーインデックス」フラグの考慮
サイトマップエンドポイント入力
サイトマップエンドポイント出力
注記:プレビューピッカー
注記:リンク作成
動的ルーティングおよびSEOメタタグ
HTTPクッキーおよびヘッダ
404ページおよび403ページ
動的ルータを実装する際のクロスドメインの問題
完全な例
データバインディングルータ
データバインディングのコンセプトの簡単な要約
データバインディングルータ
URLをWixデータクエリに変換する
データをクライアントに返す
データセットを用いて取得したデータをUI要素にバインドする
URLパターンからリンクを作成する
スキーマの拡張
一時的計算フィールド
参照フィールド
データバインディングルータに関する他の考慮事項
データバインディングルータにおけるページロール
SEOメタタグを指定する
サイトマップエンドポイント
データバインディングルータ上のフック
未解決の問題
カスタムルータ
はじめに
このドキュメントでは、エディタ/ビューアスタックに追加する予定の動的ルーティング機能の背後にあるアーキテクチャおよび様々なサブシステムを概説する。次に、このドキュメントでは、新しいデータバインディングルータを概説し、動的ルーティングモデルの上に構築する仕方について概説する。最後に、このドキュメントでは、開発者が独自の動的ルーティング実装を作成するためにカスタムルータを構築する仕方について説明する。
動的ルーティングにより、wixサイト/アプリで動的URLを定義および管理できる。これにより、ユーザおよびエディタアプリは、公開時に知られるURLを持つ静的なページ以上のものを持つサイトを作成できる。
最終的にユーザおよびアプリは次のことができる。
−具体的なレンダリングされたページにマップするURLパターンを定義する
−コンテンツが到来する動的URLに依存する動的ページを作成する
−これらのURLをボット(検索エンジンおよび同様の自動化されたコンシューマ)に公開する
このモデルの基本コンポーネントは、アプリ、ルータ、ルート、ルータエンドポイント、URL、動的ページ、ページロール、およびサイトマップである。以下では、それらと、それらがやり取りして動的ルーティングモデルを作成する仕方について説明する。
動的ルーティングを可能にする基本的な構造はルータである。ルータはアプリによって所有される。必要に応じて、各アプリに複数のルータがある場合がある。
ルータは、特定の到来するURLを、ビューアがレンダリングする特定の動的ページに解決する役割を果たす。
到来する動的URLは次の構造を有する:<site>/<prefix>/<suffix>:
−<site>:プレミアムサイトの場合は<my.site.com>の形を有し、無料サイトの場合は<user_name.wixsite.com/site_name>の形を有する。
−<prefix>:この部分は、到来するURLを処理するルータを判定する部分である。各ルータは、サイトヘッダに1セットの一意のプレフィックスを登録する。この情報は、エディタランタイムによって管理される。エディタは、2つのルータが同じプレフィックスを定義しないことを確保する。
−<suffix>:プレフィックスの後に来るあらゆるもの。この部分は、プレフィックスと共に、到来するURLを解決するためにルータによって後で使用される。
各ルータは1つまたは複数のルートをサポートする。ルートは、URLの<suffix>部分のテンプレートである。ルートの例(ルートを太字で示す)は次のとおりである。
−my.site.com/blog/
−my.site.com/blog/post−{id}
−my.site.com/blog/{year}/{month}/
−my.site.com/blog/featured−posts
アプリは、可能なすべてのルートを常にサポートするのであってもよいし、有効にするルートと無効にするルートとをユーザに選択させるのであってもよい。例えば、ブログア
プリでは、注目記事機能を使用するか否かを決定するのはユーザに委ねられていてもよい。
異なるルート間の違いを認識できるように確保するのは、アプリおよび特定のルータに委ねられていることに留意されたい。ブログアプリのための次の2つのルートを考える。
−my.site.com/blog/{year}/
−my.site.com/blog/{author}/
到来するURLを復号するために使用するルートを判断するのが難しい場合がある−「2016」という名前の作成者がいる可能性がある−そのような場合には、代わりに次のルートを作成する方がよい場合がある。
−my.site.com/blog/{year}/
−my.site.com/blog/authors/{author}/
動的ページは、単純に、ルータがルーティングできる任意のページである。動的ページはルータによって所有されている。つまり、すべてのルータは、そのルータだけがルーティングできる1セットの動的ページを有する。したがって、ルータは「レガシー」静的ページにルーティングできない。
各動的ページには、1つまたは複数のページロールが割り当てられる。ページロールは、ルータが、到来するURLを、レンダリングするための具体的なページに解決する仕方を決定するのに役立つ。
(簡略化された)アルゴリズムは次のように動作する。
1.[ビューアランタイム]<prefix>部分に基づいて、到来するURLが解析されて、どのルータがそれを解決するかを決定する
2.[ビューアランタイム]は、選択したルータのURL解決エンドポイントを呼び出し、ルータが特定の動的ページIDにURLを解決するために必要な情報を渡す。
3.[選択されたルータ]到来するURLのためのページロールの順序付きリストを計算する
4.[選択されたルータ]動的ページのリストとそれに関連付けられたページロールに基づいて、解決する動的ページIDを選択する。順序付きリストの各ページロールについて、ルータはそのロールに整合する動的ページを探す。そのロールを持つ動的ページが見つかると、検索は終了する。ページが見つからない場合、URLは404応答コードに解決される。
5.[選択されたルータ]選択されたページIDを、動的ページ(最も重要なこととして、オプションのデータペイロード)のレンダリングに必要な補助情報と共に、ビューアに返す。
6.[ビューア]選択された動的ページをレンダリングする
ルータが異なる到来するルートを同じページIDに解決するのはまったく問題ないことに留意されたい。例えば、動物園管理アプリケーションを考える。このアプリケーションは、<zoo>プレフィックスの下にルータを登録し、次の2つのルートをサポートする。
−/zoo/animal_of_the_day
−/zoo/animals/{{animal_name}}
この場合、両方のルートともページロール{animal_page}に解決される。到来するURLが</zoo/animals/tiger>であり、現在虎が「今日の動物」である場合、両方のルートとも動物をレンダリングする動的ページに解決され、両方とも画面上に美しい虎をレンダリングする。
これまで見てきたように、ビューアはルータを使用して、レンダリングするためのページを解決する。しかしながら、動的ページを正しくレンダリングするためには、考慮すべき点がさらにいくつかある。
このことを詳細に説明するこちらの図を参照されたい。
各ルータは、次の2つのエンドポイントをサポートする必要がある。
−URLエンドポイントの解決:到来するURLをページIDに解決するために使用される
−サイトマップエンドポイントの取得:このルータが解決できるURLの完全なリストを取得するために使用される
これらのエンドポイントおよびその動作の詳細を以下に示す。
このエンドポイントは、到来するURLを特定の動的ページに解決する必要がある場合に使用される。
到来するURLを解決するために、ルータは次の情報を潜在的に必要とする。
−URLのパート(サイト、プレフィックス、サフィックス)。これにはURLクエリ文字列(「?」の文字の後、および「#」の文字の前のパート)を含める必要があることに留意されたい。
−アプリ符号付き署名インスタンス:ルータエンドポイントは、到来する要求がどのサイトからのものであるかがわかるように、アプリケーションインスタンスIDを知っている必要がある。例えば、ブログアプリケーションを考える。特定のブログ投稿に関して到来するURLを解決するには、ルータはブログアプリインスタンスを知っている必要がある。
−ユーザクレデンシャル:符号付きインスタンスの一部である。ルータは、現在要求を発行しているユーザのユーザクレデンシャルを知る必要がある。これは、例えば、そのユーザが要求された特定のページの情報を表示することを許可されているか否かを知るために必要とされている。例えば、ブログルータは、匿名ユーザがmy.site.com/blog/adminの背後にあるページを表示することを禁止したい場合がある。
−ルートアレイ:[これはルータ構成の一部である。]このアプリインスタンスがサポートするルートの配列。通常、各ルートは、そのURLパターン、この特定のルートに関するタイトルおよび他のSEOメタタグなどに関する情報を提供する。詳細については、以下のSEOセクションを参照されたい。
−ルータ構成:アプリおよびルータ固有の追加情報。例えば、ブログアプリを考える。このアプリが所与の著者のすべての投稿を含む動的ページを提供すると仮定する。このようなページのURLは、my.site.com/{{author_name}}のようになる。この場合、これらのURLを処理するルータがあり、投稿データベース内の特定の著者IDに著者名をマッピングできる必要がある。そのマッピングを行うために、ルータ構成は次のものを持つ:{author_ID:123}.ルータエンドポイントが呼び出されると、author_ID 123の投稿が取得される。
−動的ページおよびそれに関連するロールのリスト:上記で説明したようなロールマッチングに基づいてレンダリングするページIDを選択するためにルータによって使用される。
−ルータがURLを解決した一次結果をレンダリングするためのページID。
−HTTP応答コード:URLを扱っているため、可能性のあるHTTP応答コードを考慮する必要がある。具体的には、応答コードは{200、301、302、403、404}を含む。ビューアランタイムはこれらのコードを使用して正しく動作する。
−データペイロード:ルータは、後で特定の動的ページのレンダリングに使用されるデータペイロードを返す可能性がある。このペイロードは、例えば、ページ上のコンポーネ
ントにバインドするために使用されるデータセットに供給できる。
−タイトル:レンダリングされるページのタイトル。ビューアランタイムはこれを使用して、ブラウザのためのページのタイトルを設定する。タイトルは、特定の動的ページに対して取得されたコンテンツに基づいて計算され得る。通常、ルートが異なるとタイトルが異なり得る。例えば、</zoo/animal_of_the_day/>というルートは、「今日の動物−虎!」というタイトルと共に動物を表示する動的ページに解決され得る。</zoo/animals/tiger>というルートは同じ動的ページに解決され得るが、タイトルは単に「当園の虎」になり得る。したがって、タイトルを作成するためのテンプレートは通常、その特定のルートのためのルータ構成の一部である。
−SEOメタタグ:SEO関連の情報。これについては後で詳述する。
上で説明したように、システムはページロールを使用して、解決する実際の動的ページを判定する。ページロールにより、アプリはフォールバックを作成できる。つまり、アプリのユーザが特定のコンテンツのために特定の動的ページを作成でき、これが他のコンテンツに使用される標準の動的ページとは異なる場合があることを意味する。
例えば、ブログアプリでは、2つの異なる動的ページが存在し得る。
−<post−page>というロールを持つ標準の投稿ページ。
−<post−page−id−123>というロールを持つ特定の投稿ページ。
ルータは、<site>/<blog>/<post−id−xxx>という形式の到来するURLを解決する。次のページロール順序付きリストを計算する:{post−page−id−xxx,post−page}。
123以外のIDを持つすべての到来するURLについては、ルータは標準の投稿ページに解決します。しかしながら、<site>/<blog>/<post−id−123>というURLについては、ルータはその123投稿のための特定のページに解決する。
このメカニズムにより、動的ページを解決するためのフォールバック方針を作成している。後でユーザがポストID 321に特定のページを追加することを決定した場合、必要なのは正しいページロールを持つ新しい動的ページを追加することだけであり、ルータはそのページに解決することを把握する。
サイトマップは、所与のサイトで公開されているURLのリストである。動的モデルのコンテキストでは、このリストはURLのリストを含み、それぞれについてサイトマップのコンシューマが必要とする情報が追加されている。
サイトマップは2つの異なるシナリオのために働く。
−まず、サイトマップは、サイト内のページのリストをボット要求に公開するという従来の目的に使用される。このシナリオでは、ルータサイトマップエンドポイントは、解決できるURLの完全なリストを計算し、それらを到来するボット要求に返す。
−次に、サイトマップはエディタでも使用できる。このシナリオでは、エディタはサイトマップエンドポイントに要求を発行し、返された結果を使用して、返されたURLのうちの1つをエンドユーザに選択させる。これは、2つの異なるケースで役立つ。
−ユーザが動的ページへのリンクを作成するとき。リンクを作成するには、エディタはリンク先の完全なURLを必要とする。
−ユーザが動的ページをプレビューしたいとき。この場合、正しくレンダリングするために必要なデータをページに提供する仕方を知るために、このページに解決する正確なURLを知る必要がある。
次の態様を考慮する必要がある。
URLのリストでは、呼び出しのためのユーザクレデンシャルを考慮する必要がある。ボット(匿名)要求の場合、サイトマップにはパブリックに利用可能なURLのみを含める必要がある。ボットは、匿名ユーザに禁止されているURLを見るべきではない。例えば、<my_app>というプレフィックスのルータを持つアプリがあると仮定する。そのアプリが、<site>/<my_app>/<admin/salaries>の下に従業員の給与を管理するためのページを有する場合、このURLは呼び出し元に返されない。
ルータが特定のURLを解決できる可能性はあるが、サイトがそのURLをレンダリングする正しいページロールを持つ動的ページを定義していない可能性がある。これらの場合、ルータは404応答コードに解決される。ボット要求に返す結果から、このようなエントリを除去するのは、ルータのサイトマップエンドポイントの役割である。
ルータは、特定のサイトで使用されていないルートを潜在的にサポートし得る。例えば、</posts/post−id>や</posts/featured−posts>などのルートをサポートするブログルータを考える。しかしながら、特定のサイトのブログインスタンスでは、ユーザが注目記事機能を使用しないことを決定していることがあり、そのため、どの投稿も注目としてマークせず、注目記事のための動的ページさえも作成していない。
そのような場合、サイトマップはこのURLを返すべきではなく、そうでないと、ボットはそれを探して404応答を取得するか、さらに悪いことには、空の投稿リストを持つ別の動的ページを取得する。
これらの問題を回避する方法は、サイトマップ生成で、サイト内のアプリインスタンスでサポートされるルートを考慮し、サポートされるルートのURLのみを生成することである。
ユーザは、動的ページを「ノーインデックス」としてマークする場合がある。これは、検索ボットによりインデックスされるべきではないことを意味する。サイトマップエンドポイントがURLのリストを計算するとき、各URLが解決するページIDも計算する必要がある。そのページIDが「ノーインデックス」としてマークされている場合、そのURLはリストから除去されるべきである。
サイトマップを計算するために、エンドポイントは次の入力に依拠する。
−符号付きインスタンス:生成するアプリインスタンスのサイトマップを知るためにエンドポイントによって使用される
−ユーザクレデンシャル:符号付きインスタンスでエンコードされているため、ルータは、ユーザが表示を許可されているURLを含むサイトマップを生成できる。
−「Is_editor」フラグ:これにより、エンドポイントは、エディタの使用に適したサイトマップを生成できる。エディタは、サイトマップをエンドユーザに表示するための情報を必要とするが、これはボットは要求していない。
−ルータ構成:この特定のルータがサイトマップを生成する仕方に関する情報。
−このサイトで使用中のルート:(ルータ構成の一部として)サポートされるルートのリスト。生成されるサイトマップは、この特定のサイトにおいてこのアプリの特定のインスタンスで使用中のルートのみを含むべきである。
−このルータの動的ページおよびそのページロールのリスト:動的ページに実際にマップされるURLのみがサイトマップに含まれるようにするために使用される。どのページにも解決しないURLは、リストから除外する必要がある。
−このルータの動的ページごとの「ノーインデックス」フラグ(ルート構成の一部):「ノーインデックス」とマークされたページに解決されるURLは、ボット用に生成されたサイトマップに表示されるべきではない。しかしながら、要求がエディタから到来する場合は、同じURLを含めるべきであり、なぜならその場合には、解決されたページにインデックスされているか否かは関係ないためである。
ボット要求の場合、以下が出力されるべきである。
−ボットがスキャンするURLのリスト
−URLごとに、次の(すべてオプションの)パラメータ:
−最終変更日
−変更頻度
−インデックスする優先順位
1つのサイトマップ要求は50,000個を超えるURLを返すべきではないことに留意されたい。この段階では、出願人らは結果のページングをサポートする予定はない。50,000を超えるURLがある場合は、余分なURLを省略されたい。
ボットのためのサイトマッププロトコルの完全な仕様については、こちらを参照されたい。
エディタ要求の場合、以下が出力されるべきである。
−URLのリスト
−URLごとに、次のパラメータ:
−扱いやすいタイトル。エディタで特定の動的ページへのリンクを作成するときに使用され、またエディタのプレビューピッカーボックスにより使用される。
−このURLが解決されるページID。エディタのリンク作成ダイアログにより使用されて、ユーザが特定の動的ページに解決するURLを選択できるようにする。
ユーザが動的ページをプレビューしようとする場合、エディタはこの動的ページに使用するURLサフィックスを知っている必要がある。プレビューピッカー要素はサイトマップを呼び出し、この動的ページIDに解決されるURLの結果をフィルタリングする。次に、ユーザはリストをブラウズし、その扱いやすいタイトルによりURLを選択する。エディタは、ここで、動的ページをレンダリングするために使用する正しいURLサフィックスを把握している。
ユーザが動的ページへのリンクを作成しようとしていると仮定する。エディタはサイトマップを取得し、このページIDにマップするURLを探す。ユーザは、その扱いやすいタイトルを見てURLをブラウズし、そのうちの1つを選択する。エディタは、ここで、選択したURLのサフィックスを使用して、特定のページIDへの「ルータリンク」を作成する。
ルータは、URL解決エンドポイントの一部としてメタタグを提供する必要がある。主なものは、「タイトル」、「ノーインデックス」、「説明」、および「画像」を含む。アプリおよびそのルータにとって意味のある方法で、解決されたURLごとにそれらを提供することはルータに委ねられている。つまり、ビューア/エディタインフラストラクチャはメタタグに依存しない。各アプリはiframeを提供して、メタタグの動作を定義で
きる。このiframeは、動的ページのためのページ設定ダイアログの一部としてレンダリングされる。情報は、ルータの構成の一部として保持され、後で正しい応答を生成するために使用され得る。
クッキーは様々なエンドポイントに送信されない。ヘッダに関しては、サポートすることが重要なヘッダの最終リストはまだ未定である。
これらのページはビューア/エディタインフラの一部として組み込みサポートを有する。ユーザはそのような特別なページを作成でき、それらが存在する場合は、インフラは適切なHTTP応答コードが受信された場合にそれらにルーティングすることを認識する。
未定
未定
ドキュメントのこのパートでは、新しいデータバインディングルータを概説し、このドキュメントの最初のパートで詳述した動的ルーティングインフラの上に構築する仕方について説明する。
読者がデータバインディングモデルの基本を理解していることを前提としている。
その上で、データバインディングコンポーネントの簡単な概要は次のとおりである。
−コレクション:mongo−DBベースのレコードセット。
−スキーマ:コレクション内のデータのメタモデル。コレクションのスキーマはスキーマファイルに保存される(コレクションごとに1つ)。
−コンテンツマネージャ:ユーザがコレクションのコンテンツを管理できるスプレッドシートのようなアプリケーション。
−Wixデータ:wixコードの一部としてデータアクセスを提供するライブラリ。Wixデータは、ユーザ提供フックの実行、パーミッションの実施、検証の実行などを担当するクライアントインターフェースおよびバックエンドレイヤを有する。
−データセット:ユーザがWixデータAPIを介して提供されるデータにUI要素をバインドできるようにするエディタ/ビューア要素。
−データバインディング:データセットを使用して視覚的コンポーネントをデータにバインドする機能。
−開発DB:エディタが動作するデータベースインスタンス。
−プロダクションDB:ライブサイトが動作するデータベースインスタンス。
本データバインディングシステムの提供を完了するために、動的URLと動的ページのレンダリングに必要なデータとの間のギャップを埋めるルータを提供する。
基本的に、データバインディングルータは、到来するURLを解析し、wixデータを使用してクエリに変換する役割を果たす。結果が取得されると、それらは特別なタイプのデータセットに送られ、そしてレンダリングされたページ上の要素にデータが提供される。
このシステムを構成する様々な要素を見ると、正しいクエリを作成すること、クライア
ントにデータを返すこと、および特別なデータセットを使用してデータをページ上のコンポーネントにバインドすることがある。
動物のレコードを有する動物のコレクションがあると仮定する。また、動物ページに/animals/{{animal_name}}のルートを設定すると仮定する。ルータはどのようにして正しいwixデータクエリを生成するのであろうか。
ルータは次を実行する必要がある。
−クエリするコレクションを知る→ルートを定義するときにルータの構成の一部としてコレクション名を保持する。
−クエリするフィールド(複数可)を知る→ルータの構成でマッピングを維持する。この場合、{{animai_name}}を「名前」フィールドにマッピングする。
−正しいクエリ構文を生成する→これはもう少し複雑である。URLの値は常に小文字で、スペースは含まれない。しかしながら、コレクション内の値は通常、人間が読みやすい形式である。例えば、動物名はコレクションでは「Grey Wolf」であるが、URLでは「grey−wolf」である。これを克服するために、ルータは「regex−query」を生成する必要がある−「grey−wolf」のすべての可能な順列のコレクションを検索する:{「Grey Wolf」、「Grey−Wolf」、「grey wolf」など}
こちらはより単純である。ルータは、resolve_url()APIごとにペイロードを提供し、そしてそれだけである。
クライアントサイドでデータを利用可能になっているため、ページ上のUIコンポーネントにプッシュするデータセットが必要である。このデータセットにはいくつかの特別な特性があるため、これをルータデータセットと呼んでいる。このデータセットは次の特別な動作を有する。
−実行時に、データペイロードを期待し、wixデータクエリを単独で発行する代わりに、それで自身を初期化する。
−実行時に、さらにデータを取得する必要がある場合(例えば、グリッドがスクロールされる場合など)、このURLに対してルータによって定義されたフィルタにアクセスする必要がある。したがって、ルータによって作成されたクエリと同様の結果を返すwixデータクエリを生成する方法を知っている。
−編集時には、ユーザがURL要素にバインドされている部分のフィルタをオーバーライドすることはできない。ユーザは、通常のデータセットと同様に、さらなるフィルタを追加したり、並べ替えおよびページサイズを指定したりできることに留意されたい。
−編集時に、ユーザがマスタページに移動することを許可しない(特定のページを暗示するURLにバインドされているため)。
−他のUX関連の動作(例えば、削除される場合の特別な通知、または複製された場合の特別な動作)。
次に、リンクの生成に注目する。各動物の一意のページへのリンクを有した状態で、グリッド状にすべての動物を表示する非常にシンプルなインデックスページが必要であると仮定する。グリッドで使用されるこれらのリンクをどのように生成するのであろうか。
基本的な考え方は、特定のコレクションのための動的ページに定義された、よく知られたURLパターン、またはルートを使用することである。これらのパターンがわかれば、それらからリンクを生成できる。
例えば、システムに3つの異なるURLパターンがあるとする。
−[main route]\zoo¥animals→動物園内のすべての動物のコレクションページ
−[habitat route]\zoo\animals/{{habitat}}→{{habitat}}に住む動物を示している
−[animal route]/zoo/animais/{{animal_name}}→特定の動物のページ
これらのパターンを定義し、動物コレクションのレコードを与えると、これらのURLを3つすべて作成できる。これを機能させるには、システムのいくつかの新しいコンセプトを含む。
スキーマの拡張は、アプリケーションによって提供されるコレクションのスキーマファイル内のセグメントである。この拡張は、通常、既存のスキーマファイルにスキーマ要素を追加する。
この場合、所与のコレクションに対して新しいルートが追加(または変更、または除去)されると、システムは関連するコレクションに対してデータバインディングアプリによって提供されるスキーマ拡張を修正する。ルートごとに、ルートのURLを生成する仕方をシステムに伝える一時的計算フィールド(以下を参照)を作成する。
これらのフィールドは、(a)計算された、(b)一時的なものである。つまり、コレクション内の実際のレコードに保持されることはなく、むしろ、指定された計算ごとにデータ取得時に計算される。これらの計算はすべて、wixデータバックエンドレイヤで行われる。
上記のルートの例では、次の3つのこのようなフィールドを作成する。
−Main_URL:string.Val=“/animals/”
−Habitat_URL:string.Val=“/animals/”+to_url_part(field_val[“habitat”])
−Animal_URL:string.Val=“/animals/”+to_url_part(field_val[“name”])
上記の計算では、計算を実行するwixデータエンジンには不明であるため、URLの<site>パートを指定されていないことに留意されたい。計算を完了し、不足している<site>部分を追加して完全なURLを作成するのはルータに委ねられている。
将来のバージョンでは、あるコレクションから他のコレクションへの参照フィールドを追加する予定である。このようなフィールドが存在することにより、コレクションAのアイテムからコレクションBのアイテムにリンクするURLを作成できる、つまり、コレクションAにコレクションBへの参照フィールドがあり、そこにコレクションBのアイテムのIDがある場合、コレクションBで定義された一時的リンクフィールドに基づいて、そのIDを使用して正しいURLリンクを生成できる。
しかしながら、現在のバージョンにはない。
ページデータバインディングルータにおけるページロール
少なくともこのシステムのv1では、動的ページごとに複数のロールを使用したり、ユーザにページのカスタムロールを指定させたりする予定はないことに留意されたい。これは、ユーザが「フォールバックページ」またはページロールの一般的な機能ごとにより具体的なページを作成できないことを意味する。
SEOメタタグは、エディタが提供するページ設定ダイアログインフラにデータバインディングアプリが提供するiframeを介して管理される。そのiframeを介して、ユーザはデータバインディングルータが所有する動的ページごとにSEOメタタグを生成する仕方を指定できる。
この構成は、ルータの構成の一部として保持され、ルータエンドポイントに渡されて、データベースから取得したデータに基づいて正しいメタタグを生成する。
例えば、ユーザは「動物」ページのタイトルに次の表現を指定できる:「動物園の大きな{{name}}に会いに来て!」。ルータは、データを取得するときに正しいタイトルを生成する。
サイトマップの実装は比較的単純である。
−コレクションごとに、そのすべてのアイテムを取得する。
−URLルートごとにフィールドを計算しているため、必要な情報は既にある。
−後は、計算されたURLの個別のセットを取得し、呼び出し元に返すだけである。
ルータが機能を実行する前後にユーザコードを実行できるようにする予定である。基本的なメカニズムは、現在のwixデータにあるバックエンドフックに似ている−ユーザは、ルータの実行前または実行後に呼び出される関数を登録できる。
実行前フックは、ルータ自体と同じ入力パラメータを取得し、実際のルータ実装に渡しても渡さなくてもよい。
実行後フックは、ルータの実行から出力パラメータを取得し、HTTP応答の一部として送り返される前にそれらを変更してもよい。
−開発/プロダクションDB
−ページレベルでのパーミッション
−カスタムルータを作成する
−カスタム動的ページを作成する
−エラーを含む、カスタムルータのためのAPI
−カスタムルータと共にページロールを使用する
−カスタムルータと共にデータバインディングを使用する
動的ページ
動的ページ
一般的な説明
動的ページを作成すると、繰り返し使用でき、毎回データベースコレクションからの異なるコンテンツを表示する1つのページレイアウトを設計します。
通常ページには繋がり得るURLが1つしかないが、それとは反対に、動的ページは異なるURLを有することができる。ページに表示されるコンテンツは、そのページへのアクセスに使用されたURLによって異なる。
動的ページは表示されるたびに異なるコンテンツを表示するため、通常のページとは異なります。通常のページはそのコンテンツをページ自体に保存しますが、動的ページのコンテンツはデータベースコレクションに保存されます。
例えば:
レシピサイトがあり、単一のレシピのためのデータを表示するページを設計することを考える。通常の静的ページでは、レシピごとに個別のページを作成する必要がある。動的ページを用いると、1つの動的ページのみを作成し、実行時に表示されるべき特定のレシピを判定し得るURLパターンを割り当てるだけでよい。
(Wixデータコレクションに保存されている)レシピのそれぞれが「title」という名前のフィールドを含む場合、動的ページのURLを「www..../recipes/{title}」となるように定義できる。
ユーザが「www.../recipes/pizza」をブラウズすると、ページは「pizza」などのタイトルのレシピのためのコンテンツを表示する。
コンテンツマネージャ(およびWixデータデータベース)
ユーザがコレクションを作成してデータを管理するために使用する。
ユーザが動的ページを作成および管理し、またページコンポーネントを関連するコンテンツパーツに接続できるようにするパネルにより、Wixエディタを強化する。
2種類の要求を受け入れるバックエンドアプリケーション:
1. ルーティング要求。データバインディングアプリケーションに属する動的ページをロードする場合に、wixビューアは所与の入力されたURLに対して表示するページおよびコンテンツをルータに要求する。ルータは、所与のURLをサイト所有者によって定義されたパターンと照合することを試み、データベース内の関連コンテンツを探す。見つかった場合、ルータは関連するページの識別子およびコンテンツで応答する。
2. サイトマップ要求。ボットがWixサイトのサイトマップを要求し、サイトにデータバインディングアプリケーションに属する動的ページが含まれる場合、ルータは解決し得るすべての可能なURLのリストを返すように要求される。
動的ページがロードされたときに実行される。ルータから返されたコンテンツを受信し、構成に従ってページ上のコンポーネントにバインドする。
コード全体はJavaScriptで記述される。
react、redux、lodash、coなど、コードと共に出荷される様々なオープンソースライブラリを使用している。
他のオープンソースライブラリは、コードの構築およびテストに使用されるが、同梱されていない:webpack、babel、mocha、eslintなど。
Sentry
コードは、Sentry(https://sentry.io)と呼ばれるサードパーティのサービスを使用して、実行時(エディタ時間およびビューア時間の両方)に発生する問題のあるフローのログを取る。
エラーが発生するたびに、コードはエラーに関する情報と現在のコンテキストとをSentryに送信する。この情報には次のようなものが含まれる。
−アプリケーションバージョン
−エディタ構成
−エラーの説明
−サイト/エディタURL
−リファラURL
−ユーザエージェント(ブラウザタイプ、バージョンなど)
−オペレーティングシステム
−ユーザのデータベースのコンテンツ
−IDEにおいてユーザにより記述されたコード
−エラーにつながったユーザアクション
データバインディング
データセットおよびデータバインディング
データバインディングシステムのコア要素はデータセットである。データセットはデータのクライアントサイドプロバイダであり、視覚的コンストラクト(すなわち、エディタコンポーネント)は双方向にバインドできる。データセットはまた、クライアントアプリケーションが、バックエンドロジックレイヤ、また最終的にはデータストア自体によりデータ取得およびデータ変換プロトコルを実装することにより、データを管理するチャネルでもある。
最も単純なタイプのデータセットは、コレクションデータセットである。このようなデータセットは、単純に、特定のコレクションからデータを取得し、基礎となるモデルのフィールドメタデータに基づいて並べ替えおよびフィルタリングを可能にし、そのコンシューマがレコードを反復処理し、場合により、新しいレコードを作成し、既存のレコードを更新できるようにする。データセットは、クエリベースのデータセットである。このようなデータセットは、単一のコレクションに対するクエリによって駆動される。
エディタ要素はデータセットにバインドされ得る。特に、エディタ要素のプロパティは、データセットのコレクションフィールド表現にバインドされる。複数の要素が同じデータセットにバインドされ得る。
実行時には、次の(簡略化された)シナリオが実行される。
−ページがロードされる
−ページコードが実行される。その一部として、1つまたは複数のデータセットが作成される(ページへのデータセットのアタッチの仕方については後述)。
−データセットは、ここで、UIコンストラクトに自身を繋ぐ。これは次のように行われる。
−このデータセットにバインドされているページコンポーネントを見つける。
−それぞれについて、データセットとコンポーネントとの間のやり取りを促進するマッチングアダプタを作成する。
−アダプタは、そのコンポーネントからの変更イベントのリスナとして自身を登録するため、変更を中継してデータセットに返すことができる。
−ここで、データ取得機能を実行することによりデータセットにデータが入力される。
−初期データが利用可能になると、関連するアダプタを使用することにより、データが関連するデータバインドコントロールに設定される。
−ここで、データセットの状態は、多くのイベントのうちの1つに対する反応として変化する場合がある。
−「次のレコード」、「前のレコード」などの呼び出し
−「次のページ」、「前のページ」などの呼び出し
−ユーザ入力による現在のレコードへの変更
−他。
−データセットの状態に対するこのような変更のたびに、アダプタを介してすべてのバインドされたコンポーネントに対して更新コマンドを出す
−また、データセットは、要求されたときに変更をバックエンドストアに「コミット」
する場合がある。これは、「現在のレコード」ポインタが新しいレコードに移動したときに自動的に発生するか、「変更のコミット」API呼び出しによって明示的に発生する。これについては後で詳述する。
データセットの状態
コンテンツマネージャ
コンテンツマネージャ(CMGR)
CMGRは、ユーザがWixデータコレクションに格納されているデータを操作できるようにするExcelに似たデータ管理アプリケーションである。アプリケーションは、2つの主要な部分、すなわちWixサイトのそれぞれの部分に置かれるCMGRエディタアプリケーションおよびCMGRマイアカウントアプリケーションから構成される。
CMGRエディタはクライアントサイドウェブワーカーにより開かれる。これは、エディタAPIとCMGRとの間のメディエータであるエディタSDKを取得し、CMGRがWixサイトの状態を操作できるようにする。CMGRエディタは次を可能にする。
−サイトのテスト/サンドボックスデータの表示および編集(WixデータAPIを使用)
−コレクションのパーミッションを編集する(エディタSDKを使用してクラウドVFSのファイルを修正する)
−Wixデータフックの表示および編集(編集はSanta Editorの外部パネルで行われ、修正はクラウドVFSに格納される)
−コレクションデータをサンドボックスからライブに、またはその逆に同期する(WixデータAPIを使用)
−ライブデータをプレビューする(WixデータAPIを使用)
−スキーマの管理:新しいスキーマの作成、フィールドの追加/編集/除去(エディタSDKを使用してクラウドVFSのファイルを修正する)
CMGRマイアカウントはWixダッシュボードによって開かれる。CMGRマイアカウントは次を可能にする。
−サイトのライブデータの表示および編集(WixデータAPIを使用)
−スキーマに保持されないデータに一時的(未定義)フィールドを追加する
CMGRエディタおよびCMGRマイアカウントの両方におけるプライマリコンポーネントである。コレクションのスキーマを使用して、グリッドの列を構築する。スキーマは、特定のWixサイトに関連付けられたWixコードファイルシステムに格納される。W
ixデータからロードされたユーザデータを使用して、グリッドの行を構築する。これは次のことを可能にする。
−コレクションアイテム(行)の管理:追加、編集、除去、複製(WixデータAPIを使用)
−フィールドの可視性を切り替える
−データのフィルタ(WixデータAPIを使用)
−データの並べ替え(WixデータAPIを使用)
CMGRは、文字列、数値、ブーリアン、日付、ページリンク、画像、JavaScript配列およびオブジェクト、参照などの複数のデータ型を処理する。
文字列、数値、ブーリアン、日付、配列、およびオブジェクトはプリミティブ型である(JavaScriptでネイティブにサポートされている)。
ページリンクは、コレクションに格納されない特別な文字列であり、動的ページのパターンを指定すると、実行時にwixデータによって構築される。ページリンクは、Wixサイトにおいて動的ページにリンクするために使用され得る。
画像は、外部リソースへの文字列か、Wixメディアサーバに格納されているファイルを参照する特別なWixメディア文字列である。ユーザは、Wixメディアダイアログを介して画像をアップロードできる。
参照は、Wixデータコレクション間の結合を有効にするために使用される他のコレクションへのポインタである。
アプリケーションは、Reactというオープンソースフレームワークによってレンダリングされる。
https://github.com/facebook/react
アプリケーションの状態は、reduxというオープンソースライブラリで処理される。https://github.com/reactis/redux
グリッドは、次の3つのコンポーネントから構成されるag−gridというオープンソースライブラリによってレンダリングされる。
1.ag−grid(https://github.com/ceolter/ag−grid)
2.ag−grid−enterprise(https://github.com/ceolter/ag−grid−enterprise)
3.ag−grid−react(https://github.com/ceolter/ag−grid−react)
動的SEO
Wixコード−SEOサブシステムの説明
Wixサイトの「通常の」SEOレンダラは、サイトを表す静的JSONデータを取得し、それを使用して検索ボット向けにサイトの簡易バージョンをレンダリングする(クライアントサイドで実装される通常のレンダリングロジックを使用せずに)。
Wixコードはユーザがサイトを動的に変更する機能を導入するため、これらの変更を含む方法でサイトをレンダリングできる異なる/追加のメカニズムが必要とされており、これは、動的ページルーティングおよび任意のユーザロジックを含み得る。
・Wix SEOレンダラからRPC要求を受信し、処理のために利用可能なワーカーにディスパッチするディスパッチャサービス(「クラウドSEOディスパッチャ」)
・レンダリング要求を処理する「クラウドSEOワーカー」のグリッド。
各ワーカーは、(実行中のユーザコードなどを含む)実際の処理を行うクライアントコード(別名「Mini Santa」)の実行に使用されるヘッドレスChromeブラウザを実行し、
サイトを表す静的データ構造に適用する一連の変更として結果を生成する。
・利用可能なワーカーを追跡し、構成の変更と同期させる管理サービス(「クラウドSEOライフサイクル」)。
通常のSEOレンダラは、サイトがWixコード対応であることを認識すると、レンダリングに関連するデータを使用して「クラウドSEOディスパッチャ」を呼び出し、次を応答として期待する。
・サイトのJSONに適用する差分(masterPage+現在のページ)
・動的ページルーティングの場合、レンダリングするページのpageID+レンダリングするSEOメタデータ
「クラウドSEOディスパッチャ」は、レンダリングタスクを利用可能な「クラウドSEOワーカー」のうちの1つに渡す。
ワーカーは、管理されているヘッドレスChromeインスタンスに、レンダリングするサイトのパラメータによりMini Santaのレンダリング関数を呼び出すことにより、サイトをレンダリングするように指示する。
レンダリング関数は、サイトをレンダリングするコードを実行するが、画面に結果を表示する代わりに、次を計算して出力する。
1. 静的サイトの初期データ構造とユーザコードの実行後のランタイムデータ構造との差分。
2. 動的ページ情報。レンダリングするページと、レンダリング結果に追加するSEOメタデータ。
これらの結果の差分は、Wixの「通常の」SEOレンダラまでの呼び出しのチェーンに戻り、これにより最初の静的データに適用され、検索エンジンクローラに送り返される最終HTMLをレンダリングする。
計算関数
Wixコード−計算関数
要約
Wixサイトの場合、ユーザは、標準のHTTPプロトコルを介してサイトのウェブインターフェースとして公開される関数を記述する機能を有し得る。
この機能は、例えば、ウェブフックを介したサードパーティアプリケーションへの登録や、ウェブサイトのREST APIの公開など、サーバ間の組み込みに役立つ。
WixコードIDEを介して、ユーザは計算関数を追加する機能を有することができ、この機能は、コードを記述するための専用ページを開く。関数の名前は、ウェブサイトアドレスに関連するウェブパスプレフィックスを表し、これにより、HTTPプロトコルを使用して関数を呼び出すことができる。
例えば、computeという名前の関数は、http[s]://mysite.com/_api/endpoints/compute/...というURLを介してアクセスできる。
ユーザはまた、場合により、関数を使用できるHTTPメソッド(GET/POST/PUT/DELETE)を定義することもできる。コードは、ユーザのサイト専用スペースの下にあるVFSと呼ばれるマルチテナントサービスに格納される。
ユーザは、URL、クエリパラメータ、ヘッダ、ペイロード、HTTPメソッドなど、処理に使用できるHTTP要求情報を取得する。
ユーザは、ステータスコード、ペイロード、ヘッダの部分でHTTP応答を生成できる。
関数がHTTPアクセスに利用可能になり、Wixコードウェブサーバ(ディスパッチャ)に対してHTTP要求が呼び出された後、関数定義の存在をテストするために最初の検証が実行される。関数が存在しない場合、ステータス404(見つかりません)が返される。関数が存在する場合、コードは、そこで実行されている基本アプリケーションサーバ(ELM)を介して、分離されたドッカーコンテナで実行される。
計算関数の開発段階で、WixコードIDEを介して提供されるテストHTTP URLを介して関数をテストできる。既に公開されているか、現在開発中の関数実行のログを表示することもできる。
計算関数−詳細
Wixコード−計算関数
概要
このドキュメントでは、HTTPを介してAPIとしてウェブエンドポイントを公開するための機能要件および技術仕様の提案を概説する。
この文書は研究論文に基づいている。
認証なしでのウェブアクセスのためのメソッドを公開する機能
・サポートされているHTTPメソッドを定義する機能:POST、GET、PUT、DELETE(同じパス上)
・要求のHTTPメソッド、パス、ヘッダ、クエリパラメータ、およびボディを抽出(読み取り)する機能
・応答のHTTPステータスコード、ヘッダを書き込む機能
○要求のHTTPアクセプトヘッダを定義する機能があると好都合である
○応答のHTTPコンテンツタイプヘッダを定義する機能があると好都合である
・データへの不正アクセスは、データレイヤにより処理(実施)されるべきである
メソッドがウェブアクセスのために公開されると、メソッドは次の仕様で公開される。
無料サイト
公開サイト:https://{user name}wixsite.com/_api/endpoints/{site name}/*
開発:https://{user name}wixsite.com/_api−dev/endpoints/{site name}/*
プレミアムサイト
公開サイト:https://{user domain}/_api/endpoints/*
開発:https://{user domain}/_api−dev/endpoints/*
サイトルートへの/_api/endpomts/(および/_api−dev/endpoints/)という相対パスは、ユーザ定義API全体へのルートエントリポイントになる。このエントリポイントをAPIルートとして呼び出す。
ユーザの視点からは、このURLは永続的なものになる。URLが変更されるユースケースは次のとおりである。
・無料サイトにおいて−ユーザがサイト名を変更
・プレミアムサイトにおいて−ユーザがドメインを変更
・ユーザがAPIルートの後の内部サブパスを変更したとき。
・サイト移転−ドメイン名が変更され得る
・プレミアムへのアップグレード−ドメインの購入/既存のドメインの割り当て
全対全−APIの後方互換性はもっぱらユーザの役割のようである。
URLは、ユーザのサイトと同じドメインにある。これらのURLにブラウザを介してアクセスし、ユーザが意図しない安全でないコードを記述すると、潜在的なセキュリティリスクが発生する可能性がある。
以下を使用して、CSRFおよびXSS攻撃に対処できる。
・CSRF−ブラウザユーザエージェントにクッキー/ヘッダ検証を使用する
・XSS−オプトアウトまたはホワイトリストを定義するオプションを備えた状態で、デフォルトでユーザのドメインにコンテンツセキュリティポリシー機能を使用する
SSLを使用すると、セキュリティをさらに向上させることができる。
・許可されるHTTPメソッド:エンドポイントの定義による
・関数のコードは、要求のボディ、ヘッダ、クエリパラメータ、IPを抽出する役割を果たす。
・応答のステータスコード:エンドポイントのコードの役割
・適切な形式で応答のボディを提供するのはエンドポイントのコードの役割である
・応答ヘッダも提供することができる
はじめに
一般的な方向性は、パブリックサイトスクリプトで使用されるウェブモジュールを、HTTPコンシューマ向けにウェブを介してパブリックに公開されるメソッドの定義と区別することである。後者を計算関数と呼ぶことにする。共有コードをパブリックスクリプトから使用する必要がある場合、より簡素な設計および実装が可能になると同時に、その結果のデフォルトの形式は、そのままウェブ計算関数の公開に使用することはできず、なんらかの操作が必要となる。
また、サイトのプレゼンテーションレイヤ(パブリックスクリプト)とはまったく関係のないウェブ計算関数を定義することもできる。
例えば、githubウェブフックをリッスンするウェブ計算関数は、データを解析し、データベースコレクションに情報を保存し、同じコレクションからのデータを提示する動的ページがある。ここにはパブリックサイトのスクリプトは含まれていない。
計算関数のコードを専用のJSファイルに格納する。ユーザは計算関数を定義できる−そしてUIはすべての計算関数のコードが置かれるファイルを開く。
そのファイルのコードが大きくなる可能性がある場合は、この態様を再検討する必要が
あり得る。
計算関数には2つの態様がある。
1.設計時の態様−ユーザが計算関数を定義し、HTTPメソッド、受け入れる要求コンテンツタイプ、生成する応答コンテンツタイプなど、様々な態様を構成する方法。
2.実行時の態様−このような計算関数が定義されたならば−適切なHTTPエンドポイントが公開されるべきであり、計算関数のコードの実行にリダイレクトするために呼び出されたとき、および既存の計算関数が削除されたときに、既存のHTTPエンドポイントを除去するべきである。当然のことながら、これは、サイトの公開後、またはユーザによる計算関数のテスト目的で公開する前にのみ利用可能にするべきである。
・計算関数のプレフィックスごとにエクスポートされた関数を定義する
・関数には次のプレフィックスがある:get_、post_、put_、delete_、use_
・プレフィックスの後の関数名は、ウェブエンドポイントのパスプレフィックスを表す
・すべきこと:新しい計算関数を定義する方法のUIの態様をまとめる必要が依然としてある
//URLのためのすべてのGET要求
//http[s]://{user_domain}/_api/endpoints/example/*はここにルーティングされる
//URLのためのすべてのPOST要求
//http[s]://{user_domain}/_api/endpoints/kuku/*はここにルーティングされる
//URLのためにどのHTTPメソッドが呼び出されたかに関係なくすべてのHTTP要求
//http[s]://{user_domain}/_api/endpoint
s/jojo/*はここにルーティングされる
他の却下された代替策については、付属書類Aを参照されたい。
良い点:
・シンプルな定義、UIにより容易に支援可能
・構成はコードに近い
・反映の必要がない
・現在パブリックに利用可能なJSの仕様を使用する
悪い点:
・HTTP呼び出しへの関数の動的バインディング−事前定義された構成が存在しない
・あいまいな定義が発生し得る−例えば、同じエンドポイントでget_とuse_
○文書化する必要がある単純な優先順位アルゴリズムによって解決できる。特定のメソッドはuse_*よりも優先される
・一部の文字はプレフィックスの一部にすることができない(例えば、「−」という文字)
○JS関数名に配置することがサポートされていないすべての文字
再検討:wixインフラストラクチャのリダイレクトレベルによっては、途中でいくつかの内部ヘッダが追加される場合がある。これは、要求ヘッダの提供を回避することで解決できる。一方、機密ヘッダがサービスに転送されるような場合は、おそらく通信プロトコルのセキュリティ問題であり、なんとしても回避する必要があり、関連するプロトコルを再設計することで解決できる。
ユーザランタイムは今日も安全ではない環境と見なされているため、ユーザコンテナに機密情報を保持したり、渡したりすることはない。ユーザがアクセスできないようにしたいものがあれば、ディスパッチ中にそれを削除できる。
ルータ機能に関して、要求オブジェクトおよび応答オブジェクトのデータ構造を統一するよう努めている。
//プレミアムWixサイトのドメインまたは無料WixサイトのURL
//パートで分解されたAPIルートへの相対パス
//関数がアクセスされたURL全体
//元のクライアントIP
//このオブジェクトはクエリパラメータ名のキー/値およびそのそれぞれ値を有する
//このオブジェクトはヘッダのキー/値およびそのそれぞれ値を有する
//要求のボディ
//”GET”、”POST”、...
//応答のステータスコードを表す整数の数値
//ルータの応答関数、例えばok()、forbidden()、notFound()などをここで再利用する場合がある
//応答のボディ
//このオブジェクトはヘッダのキー/値およびそのそれぞれ値を有する
応答のためのファクトリ
//応答ファクトリからready応答がある
//wix−compute−functions.jsを含む。これは以下の関数を公開する。
//一般的な応答
//200 OK応答
//201 Created応答
//404 Not Found応答
//500 Internal Server Error応答
//400 Bad Request応答
//403 Forbidden応答
注意−各サイトにcompute−functions.jsというファイルがあり、エンドポイントのURLから関数へのマッピングは、関数のコード自体と共に配置されている。
・UIを介して計算関数を作成すると、/compute−functions.jsというパスのエレメンタリに、関連するサイトコンテキストの下のファイルが作成される
ドメインからサイトlDを取得する簡単な方法はないようである。どのgridAppIdを起動するべきかを理解するために、3つのRPC呼び出しがある。
しかしながら、metaSiteId/siteId/domainが変更された場合、これら3つのRPC呼び出しをキャッシュすることを勧める。キャッシュを更新する、または定期的なポーリングによってキャッシュを更新するイベントが必要であり、これは結果整合性を示す(イベントが万全であることに頼ることはできないため、キャッシュ更新の代替策において)。出願人らの理解では、metaSiteIdの変更またはドメインの変更のイベントはない。
ドメイン→gridAppIdをキャッシュすることが提案されている。gridAppIdは保存後に変更される可能性があるため、保存するたびにキャッシュを無効にする。このイベントは既にwixコードで扱われている。パブリッシュイベントをリッスンしていた場合、それが存在する方が良い。
ドメイン名/無料サイト名に変更がある場合−新しいドメインはキャッシュにないため、まずこの新しいドメインのフロー全体を再度実行してキャッシュする。
キャッシュは、最終接触時間に基づいたエビクションポリシーを有するべきである。
ユーザが計算関数を開発するとき−公開する前にウェブエンドポイントに「開発モード」を提供するべきではないだろうか。
新しい関数の場合−関数のコードがデータを操作する場合に役立つ。ユーザは、新しいコードが既存のデータを破損しないことを確認したいため、公開前にコードをテストすることを望む。加えて、計算関数が既に公開されており、例えば新しいプロトコルをサポートするために、ユーザが更新する必要がある場合、新しい関数のコードが期待どおりに実行しているようになると確信できるまで、関数の既存の機能を壊したくない。
この機能をどのように提供するべきであろうか。つまり、現在公開されているウェブエンドポイントと並行して動作する更新された関数をウェブに公開するという機能をどのように提供するべきであろうか。
・エディタクライアントがロードされると、そのSCARIがAPIディスパッチャサービスに送信される(IDEサーバ経由)
・APIディスパッチャサービスには、テスト用のドメイン→gridAppIdのマッピングがある
○エディタセグメント(テスト)とパブリックセグメント(公開サイトAPIアクセス)とを分離してみる。
○このgridAppIdは、エディタで現在開発されているバージョンを表し、公開後に変更が発生していない場合は、公開されたバージョンでも、新しく開発されたバージョン(保存されていないバージョン)でもよい。
・cloneCodeApp/duplicateCodeApp/createAppのwixコードサービスの呼び出しがあるたびに、新しく生成されたgridAppIdは、APIディスパッチャサービスに伝播される
・現在開発されているバージョンへのアクセスは、URIセクションに記載されている開発URIを介して行われる。
そして、api−devの要求がAPIディスパッチャにより受信されると、ドメインごとにgridAppIdのキャッシュを取得する。存在しない場合、公開されたサイトと同様のプロトコルにフォールバックし、最後に保存されたバージョンのgridAppIdをキャッシュする。
注意:エディタを開いているときにドメインが変更されると、問題が発生する可能性がある。そのようなイベントが存在する場合はリッスンし、それに応じてキャッシュを更新するか、制限を宣言する必要がある。
別の可能な代替策としては、エディタのロード時に、クライアントによって送信されたwixコードinstanceId→gridAppIdをキャッシュし(ドメインの解決なし)、実際のapi−dev要求で、上図のように同様のフローでドメインを解決し、およびドメイン→gridAppIdもキャッシュする。
次に、cloneCodeApp/duplicateCodeAppが発生すると、
前のgridAppIdで両方のキャッシュを更新する(gridAppIdによる逆インデックスもある)。
これにより、「ドメインの変更」問題も解決される。
これはいくらか複雑なメカニズムのようである。制限を設けて、テストの前に保存するように要求してはどうだろうか。または、APIをテストするための他の「オンデマンド」イベント、例えばAPIをテストするなど?
ウェブフックでのハッカソンの苦痛の1つは、バックエンドコードにデバッグ機能がないことであった。機能を追加する必要があり、これは製品の未解決の問題である。
ユーザは、こちらに似たconsole.log出力の連続的なストリームのためのウェブエンドポイントを有する。
[https://webtask.io/docs/api_logs]
このことは慎重に検討する必要があるが、これは大量にリソースを消費するものになり得る。
・ロギングAPIを提供し、サイトごとにローリングログファイルを用意し、これはユーザがエディタを介してダウンロードできる。
・特別なUIを開発モードで開くと、それらのログを印刷される
○実際には、これは上記の好ましい解決策に追加され得る
・開発者はヘッダ、例えばx−debugを提供でき、それに応じて要求に関するデバッグ情報を保持する一意のURLを含む応答ヘッダを受け取る。サイトごとに最大50個のURLである。情報は5分間メモリに保持される
○マシンごとに200のエレメントリがあることを考えると、これがエレメントリのインメモリに保持されている場合、メモリに関して問題はないはずである。
却下された設計時の態様の代替策
代替策1:ほぼjax−rs APIからのコピー/ペースト
@decoratorsを使用できればいいのであるが、利用できるのは、次のjavascriptの仕様であるES8のようである。
Babelトランスパイラは、いくつかの実験モードでサポートしている。
その後、反映を使用して、これらすべての計算関数メソッドを検索し、これらを構成に応じてマッピングできる。
//ウェブエンドポイントはGET HTTPメソッドのために公開される
//それは例えば以下のURLにおいてである。
//https://mydomain.com/_api/endpoints/example/path
//要求のためにアプリケーション/JSONコンテンツタイプを期待する
//期待される応答のコンテンツタイプを定義する
良い点:
・明確で簡単な宣言
悪い点:
・要求のアクセプトおよび応答のコンテンツタイプヘッダのこのようなマッピングは、例えばワイルドカードが使用されている場合、ディスパッチャにとって難しいようである。放棄するべきかもしれない
・ファイナライズされていない仕様の使用(現在ステージ2−https://github.com/tc39/proposal−decorators)
・関連するマッピングを見つけるために反映を必要とする
マッピングがユーザによって宣言される特別なメソッドを、事前定義された名前で提供できる。
//configは以下のメソッドを有する
//config.register(method,path,functionName)
//実行するためにHTTPメソッド、パス、関数をマップする
//関数は以下のシグネチャのものであることが期待される
//function someFunction(request,respons
e)
//正確なパスマッピング
//ワイルドカードパスマッピング。すべての/kukuのサブパスがこの関数にマップされる
良い点:
・非常に簡単な宣言
・反映の必要がない
・現在パブリックに利用可能なJSの仕様を使用する
悪い点:
・関数名が文字列として宣言され、タイプミスが発生し得る
・構成はメソッド自体にはほど「遠い」
例えばWixComputeFunctionsなどの計算関数のレジストラとして機能するグローバルオブジェクトがいくつかある。
//正確なパスマッピング
//パスおよびすべてのその子孫
良い点:
・簡単な定義、Expressに似たAPI
・構成はコードに近い
・反映の必要がない
・現在パブリックに利用可能なJSの仕様を使用する
悪い点:
・グローバルオブジェクトを公開する
・あいまいな定義が発生し得る−なんらかの優先順位アルゴリズムが必要
実行するためのHTTPメソッド、パス、および関数を構成するためのExpressに似たパターン。
//configは以下のメソッドを有する:get,post,use
//config.get(path,function)
//実行するためにHTTPメソッド、パス、関数をマップする
//use使用時は任意のHTTPメソッドが関数を呼び出す
//正確なパスマッピング
//ワイルドカードパスマッピング。すべての/kukuのサブパスがこの関数にマップされる
良い点:
・簡単な定義、Expressに似たAPI
・構成はコードに近い
・反映の必要がない
・現在パブリックに利用可能なJSの仕様を使用する
悪い点:
・あいまいな定義が発生し得る−なんらかの優先順位アルゴリズムが必要
Wix DB
概要
ドックストアは、データを管理するためのRESTful APIを公開する一般的なマルチテナントドキュメントスタイルのデータサービスである。すべてのテナントは、いくつかの個別の仮想データベースを持つことができる。サービスはまた、テナントのデータベースを管理したり、場合によりテナントを無効にしたりするための、管理サーバ間(ユーザ向けではない)APIを有する。
データの格納に使用される基礎となるデータベースはMongoDBであり、サービスはシャーディング目的で複数の物理MongoDBデータベースをサポートする。
最初の要求時および認証チェックを通過した後、各テナント仮想データベースはサービスが動作している物理MongoDBデータベースのうちの1つに割り当てられ、その時
点から、そのテナントのデータベースのすべての到来する要求はその物理データベースに対して実行される。
仮想テナントデータベースから物理データベースへのマッピングは管理データベースで維持され、ホットマッピングレコードはLRUベースのインメモリキャッシュに保持される。
各テナント仮想データベースには、1つまたは複数のドキュメントのコレクションを含めることができる。各仮想コレクションは、1つの物理MongoDBコレクションにマップされる。コレクションのマッピングは、シンプルなネームスペーシングシステムを使用して行われる。各物理コレクションには、<tenantId>@<vdb−name>@<collection−name>という名前が付けられる。したがって、要求が到来すると、認証チェックを通過した後、テナントID、ターゲットデータベース、およびコレクション名が解決され、物理コレクション名が構築されてアクセスできるようになる。
新しいテナントデータベースを導入する場合、永続的なターゲット物理データベースを割り当てる必要がある。物理データベースの選択は、現在のデータベースサイズに基づいて行われる。バックグラウンドタスクは、定期的に実行され、サービスが動作するように構成されているすべてのアクティブなデータベースから統計を収集するようにスケジュールされている。統計値はインメモリデータ構造に格納されるため、新しいデータベースを割り当てるときに、最小のデータベースをターゲットとしてすぐに選択できる。
$W API
$W API
$W APIは、ユーザがコードを使用してビューアコンポーネントと対話できるようにする方法である。SDKは、ユーザコード/拡張機能が実行されているワーカーとランタイム(別名ビューア)との間で使用される内部通信レイヤをラップするために使用される。以下は、論理アーキテクチャを表す図である。
RMIの内部モデルは、システムの一部のみを制御および修正したいユーザにとっては複雑すぎ、ドキュメント化されておらず、実行に必要なプロプライエタリ情報が含まれている。$W SDKはこれをラップし、要素を見つけて操作するより一般的なパターンにラップしたものを変換する。
コーディングパターン:
$w SDKでサポートされるコーディングパターンには、次の2つのパートが含まれる。
1.ページライフサイクルイベント:ライフサイクルメソッドを使用すると、SDKを使用したコードが、事前定義された段階においてトリガされる。これらの段階では、SDKが利用可能であり、コードは外部データのロード、コンポーネントの初期化、イベント登録などの様々なタスクを実行できる。現在、単一のメソッドが利用可能であり、これは、ページが提示される前に発生し、PageLoadと呼ばれる。javascriptにpromiseを返すことにより、コードはすべての非同期情報(wixデータまたは外部サービスからの外部データなど)がロードされるまでページの提示を延期できる。
2.選択:$wはページのグローバルコンテキストを表す。同様のコンテキストオブジェクト、すなわちリピータアイテムを描画するときの$itemが存在し得る。コンテキストを使用して、ユーザは、文字列クエリを使用して要素を選択する。セレクタは通常のCSSセレクタに似ているが、わずかな違いがある。選択すると、単一の要素または複数の要素が返され得る。例えば:
$w(’#myElement’)−これはmyElement IDを持つ要素を選択する
セレクタには次のタイプがある。
○IDセレクタ。ページの一意のIDを使用して選択する。
○タイプセレクタ。コンポーネントのタイプを使用して選択する。
○タイプのアレイセレクタ
○ロールセレクタ。これは、独自の事前定義された名前を使うことを選択するためにコントローラによって使用される。要素は、コントローラによって与えられてIDおよび複数のロールを有することができる。
3.要素の操作:要素への参照が取得されると、要素はそれを操作するメソッドを提供する。要素の非表示や表示など、一部のメソッドはすべての要素で利用可能である。一部のメソッドは、特定の要素でのみ利用可能である。完全なリストはSDK documentationで提供されている。
4.イベント登録:各要素は、事前定義されたイベントのセットをサポートする。SDKを使用しているコードは、これらのイベントに登録し、発生時に呼び出されるコールバックメソッドを提供できる。コールバック中に、選択および操作が可能である。
Claims (29)
- ウェブサイトの複数のウェブページに投入されるデータセットを含むバックエンドデータベースを更新するための非一時的コンピュータ可読媒体であって、前記コンピュータ可読媒体が、少なくとも1つのプロセッサにより実行された場合に、
ユーザインターフェースを介して複数のデータ要素を受信するステップであって、前記データ要素が少なくとも1つのデータ要素の1つまたは複数のグループに編成され、各グループがウェブサイトの個別のウェブページに表示するためのものである、ステップと、
前記少なくとも1つのデータ要素のグループをデータベースに格納するステップと、
複数の仮想ウェブページを生成するステップであって、各仮想ウェブページが、対応する実際のウェブページが稼働する前における前記対応する実際のウェブページのプレビューであり、前記対応する実際のウェブページのそれぞれが前記データベースを更新するための機能を備えて設計されていない、ステップと、
前記複数の仮想ウェブページのうちの個別のページに少なくとも1つのデータ要素の各グループを表示するステップと、
ユーザが前記複数の仮想ウェブページからの仮想ウェブページを編集できるように編集ツールを表示するステップと、
前記仮想ウェブページの前記編集を前記データベースのための更新に変換するステップと、
前記データベースに前記更新を格納するステップと、
前記仮想ウェブページに関連付けられた対応する実際のウェブページのライブビュー中に、前記プレビュー中に前記仮想ウェブページに対して前記更新を行った状態で前記対応する実際のウェブページを表示できるようにするステップと、
を前記少なくとも1つのプロセッサに実行させる命令を含む、非一時的コンピュータ可読媒体。 - 前記複数の仮想ウェブページのそれぞれが、前記ユーザインターフェースのエディタインターフェースに関連付けられたフレーム内に表示可能である、請求項1に記載の非一時的コンピュータ可読媒体。
- 前記ステップが、前記複数の仮想ウェブページのそれぞれを個別かつ動的に表示するために、前記ユーザが前記複数の仮想ウェブページにわたってナビゲートできるようにするユーザ選択可能機能を表示するステップをさらに含む、請求項1に記載の非一時的コンピュータ可読媒体。
- 前記ステップが、前記ユーザが前記複数の仮想ウェブページからの特定の仮想ウェブページを前記特定の仮想ウェブページの識別子に基づいて選択できるようにするユーザ選択可能機能を表示するステップをさらに含む、請求項1に記載の非一時的コンピュータ可読媒体。
- 前記特定の仮想ウェブページの前記識別子が、前記特定の仮想ウェブページに関連付けられたデータ要素に基づく、請求項4に記載の非一時的コンピュータ可読媒体。
- 前記ステップが、前記複数の仮想ウェブページのそれぞれに一意のURLを関連付けるステップをさらに含む、請求項1に記載の非一時的コンピュータ可読媒体。
- 前記複数の仮想ウェブページのそれぞれが、前記複数の仮想ウェブページのそれぞれの前記一意のURLを参照するサイトマップに基づいて生成される、請求項6に記載の非一時的コンピュータ可読媒体。
- 前記編集ツールが、前記データベースに前記格納された少なくとも1つのデータ要素のグループに対する編集を受信するように構成される、請求項1に記載の非一時的コンピュータ可読媒体。
- 前記編集ツールが、前記複数の仮想ウェブページの属性に対する編集を受信するように構成される、請求項1に記載の非一時的コンピュータ可読媒体。
- 前記編集ツールが、前記複数の仮想ウェブページを生成するために使用されるコードに対する編集を受信するように構成される、請求項1に記載の非一時的コンピュータ可読媒体。
- 前記編集ツールが、前記複数の仮想ウェブページを生成するために使用される実際のコードを表すスケルトンコードの複数のセグメントを表示するように、また前記実際のコードに対する編集に変換される前記スケルトンコードに対する編集を受信するように構成される、請求項1に記載の非一時的コンピュータ可読媒体。
- 前記データ要素が、外部ソースから前記ユーザインターフェースを介して受信される、請求項1に記載の非一時的コンピュータ可読媒体。
- 動作が、
前記複数の仮想ウェブページに関連付けられたソフトウェアベースのルータにアクセスすることと、
受信したURLの1つまたは複数のセグメントに基づいて前記複数の仮想ウェブページのそれぞれの異なるバージョンを生成するように前記ソフトウェアベースのルータを構成することと、
をさらに含む、請求項1に記載の非一時的コンピュータ可読媒体。 - 少なくとも1つのデータ要素の各グループのサブセットがリピータ機能により編成され、前記リピータ機能が少なくとも1つのデータ要素の各グループの前記サブセットの1つまたは複数の表示されたインスタンスを生成する、請求項1に記載の非一時的コンピュータ可読媒体。
- 前記対応する実際のウェブページの前記ライブビューが前記1つまたは複数のインスタンスを含む、請求項14に記載の非一時的コンピュータ可読媒体。
- ウェブサイトの複数のウェブページに投入されるデータセットを含むバックエンドデータベースを更新するためのコンピュータ実施方法であって、前記方法が、
ユーザインターフェースを介して複数のデータ要素を受信するステップであって、前記データ要素が少なくとも1つのデータ要素の1つまたは複数のグループに編成され、各グループがウェブサイトの個別のウェブページに表示するためのものである、ステップと、
前記少なくとも1つのデータ要素のグループをデータベースに格納するステップと、
複数の仮想ウェブページを生成するステップであって、各仮想ウェブページが、対応する実際のウェブページが稼働する前における前記対応する実際のウェブページのプレビューであり、前記対応する実際のウェブページのそれぞれが前記データベースを更新するための機能を備えて設計されていない、ステップと、
前記複数の仮想ウェブページのうちの個別のページに少なくとも1つのデータ要素の各グループを表示するステップと、
ユーザが前記複数の仮想ウェブページからの仮想ウェブページを編集できるように編集ツールを表示するステップと、
前記仮想ウェブページの前記編集を前記データベースのための更新に変換するステップ
と、
前記データベースに前記更新を格納するステップと、
前記仮想ウェブページに関連付けられた対応する実際のウェブページのライブビュー中に、前記プレビュー中に前記仮想ウェブページに対して前記更新を行った状態で前記対応する実際のウェブページを表示できるようにするステップと、
を含む、コンピュータ実施方法。 - 前記複数の仮想ウェブページのそれぞれが、前記ユーザインターフェースのエディタインターフェースに関連付けられたフレーム内に表示可能である、請求項16に記載のコンピュータ実施方法。
- 前記複数の仮想ウェブページのそれぞれを個別かつ動的に表示するために、前記ユーザが前記複数の仮想ウェブページにわたってナビゲートできるようにするユーザ選択可能機能を表示するステップをさらに含む、請求項16に記載のコンピュータ実施方法。
- 前記ユーザが前記複数の仮想ウェブページからの特定の仮想ウェブページを前記特定の仮想ウェブページの識別子に基づいて選択できるようにするユーザ選択可能機能を表示するステップをさらに含む、請求項16に記載のコンピュータ実施方法。
- 前記特定の仮想ウェブページの前記識別子が、前記特定の仮想ウェブページに関連付けられたデータ要素に基づく、請求項16に記載のコンピュータ実施方法。
- 前記複数の仮想ウェブページのそれぞれに一意のURLを関連付けるステップをさらに含む、請求項16に記載のコンピュータ実施方法。
- 前記複数の仮想ウェブページのそれぞれが、前記複数の仮想ウェブページのそれぞれの前記一意のURLを参照するサイトマップに基づいて生成される、請求項21に記載のコンピュータ実施方法。
- 前記編集ツールが、前記データベースに前記格納された少なくとも1つのデータ要素のグループに対する編集を受信するように構成される、請求項16に記載のコンピュータ実施方法。
- 前記編集ツールが、前記複数の仮想ウェブページの属性に対する編集を受信するように構成される、請求項16に記載のコンピュータ実施方法。
- 前記編集ツールが、前記複数の仮想ウェブページを生成するために使用されるコードに対する編集を受信するように構成される、請求項16に記載のコンピュータ実施方法。
- 前記編集ツールが、前記複数の仮想ウェブページを生成するために使用される実際のコードを表すスケルトンコードの複数のセグメントを表示するように、また前記実際のコードに対する編集に変換される前記スケルトンコードに対する編集を受信するように構成される、請求項16に記載のコンピュータ実施方法。
- 前記データ要素が、外部ソースから前記ユーザインターフェースを介して受信される、請求項16に記載のコンピュータ実施方法。
- ウェブページに投入されるデータセットを含むバックエンドデータベースを更新するために前記ウェブページを動的に編集できるようにするシステムであって、前記システムが、
複数のウェブページに表示するための複数のデータ要素を格納するように構成されたオンラインデータベースであって、前記データ要素が、少なくとも1つのデータ要素の1つまたは複数のグループに編成され、各グループがウェブサイトの個別のウェブページに表示するためのものであり、各個別のウェブページが前記オンラインデータベースを更新するための機能を持たない、オンラインデータベースと、
少なくとも1つのプロセッサであって、
少なくとも1つのデータ要素のグループに基づいて生成された第1のウェブページの編集可能なバージョンを表示するインターフェースを提供するための命令をブラウザにリモートで提供し、前記インターフェースによりユーザが前記少なくとも1つのデータ要素を編集でき、
前記インターフェースを介して受信した、前記第1のウェブページの前記編集可能なバージョンに対する編集を、前記オンラインデータベースのための更新に変換し、
前記オンラインデータベースに前記更新を格納し、
前記第1のウェブページのライブビュー中に、前記第1のウェブページの前記編集可能なバージョンに対して前記更新を行った状態で前記第1のウェブページを表示できるようにする、
ように構成される、少なくとも1つのプロセッサと、
を備える、システム。 - 前記少なくとも1つのプロセッサが、ウェブページの複数の個別の編集可能なバージョンを生成するようにさらに構成され、ウェブページの個別の編集可能なバージョンはそれぞれ、前記インターフェースのエディタインターフェースに関連付けられたフレーム内に表示可能である、請求項28に記載のシステム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2024040504A JP2024075645A (ja) | 2017-07-24 | 2024-03-14 | 仮想ウェブページのプレビュー中におけるデータベースの編集 |
Applications Claiming Priority (5)
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 |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2024040504A Division JP2024075645A (ja) | 2017-07-24 | 2024-03-14 | 仮想ウェブページのプレビュー中におけるデータベースの編集 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2020530610A true JP2020530610A (ja) | 2020-10-22 |
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 After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2024040504A Pending JP2024075645A (ja) | 2017-07-24 | 2024-03-14 | 仮想ウェブページのプレビュー中におけるデータベースの編集 |
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)
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 |
Citations (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2002202937A (ja) * | 2000-12-28 | 2002-07-19 | Ibi Kk | ウェブサイト自動作成装置、ウェブサイト自動作成システム、ウェブサイト自動作成方法、及び、記録媒体 |
JP2004005527A (ja) * | 2002-03-28 | 2004-01-08 | Yosuke Hiratsuka | 階層型サイト情報作成プログラム |
JP2004530191A (ja) * | 2001-02-22 | 2004-09-30 | アクセンチュア グローバル サービスィズ ゲーエムベーハー | ウェブ・サービスで構成された、インタネット・ホスティング・ビジネス・アプリケーションの開発システム |
JP2006146506A (ja) * | 2004-11-18 | 2006-06-08 | Image:Kk | Webサイト更新システム、Webサイト更新方法およびWebサイト更新プログラム |
JP2008535056A (ja) * | 2005-03-24 | 2008-08-28 | ヒューレット−パッカード デベロップメント カンパニー エル.ピー. | 埋め込みウェブベース管理方法 |
JP2009176296A (ja) * | 2007-12-27 | 2009-08-06 | Nippon Institute Of Agroinformatics Ltd | Web文書編集方法 |
JP2010140076A (ja) * | 2008-12-09 | 2010-06-24 | Fujitsu Ltd | Webページ編集プログラム及びWebページ編集装置 |
JPWO2012014248A1 (ja) * | 2010-07-25 | 2013-09-09 | 株式会社コアアプリ | ファイル公開管理コンピュータプログラム、ファイル公開管理コンピュータシステム |
JP2016519347A (ja) * | 2013-03-14 | 2016-06-30 | ウィックス.コム リミテッド. | データリストを利用したウェブサイト構築のデバイス、システム、および方法 |
Family Cites Families (130)
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 |
US20020165936A1 (en) * | 2001-01-25 | 2002-11-07 | Victor Alston | Dynamically branded web sites |
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 |
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 |
US8019749B2 (en) * | 2005-03-17 | 2011-09-13 | Roy Leban | System, method, and user interface for organizing and searching information |
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 |
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 |
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 |
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 |
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 |
-
2018
- 2018-07-24 US US16/044,461 patent/US10209966B2/en active Active
- 2018-07-24 CA CA3060362A patent/CA3060362A1/en active Pending
- 2018-07-24 EP EP23180890.8A patent/EP4235461A3/en active Pending
- 2018-07-24 WO PCT/IB2018/001028 patent/WO2019038588A1/en unknown
- 2018-07-24 US US16/044,383 patent/US10915300B2/en active Active
- 2018-07-24 EP EP18848030.5A patent/EP3593254B1/en active Active
- 2018-07-24 US US16/044,469 patent/US10719300B2/en active Active
- 2018-07-24 US US16/044,365 patent/US10521198B2/en active Active
- 2018-07-24 ES ES18848030T patent/ES2970458T3/es active Active
- 2018-07-24 AU AU2018319444A patent/AU2018319444B2/en active Active
- 2018-07-24 US US16/044,457 patent/US11106860B2/en active Active
- 2018-07-24 JP JP2020503801A patent/JP2020530610A/ja active Pending
- 2018-07-24 BR BR112019024309-7A patent/BR112019024309A2/pt unknown
- 2018-07-24 US US16/044,460 patent/US10331420B2/en active Active
-
2019
- 2019-01-10 US US16/245,139 patent/US10326821B2/en active Active
- 2019-04-19 US US16/389,604 patent/US10379820B1/en active Active
- 2019-04-19 US US16/389,613 patent/US10397305B1/en active Active
-
2020
- 2020-01-08 IL IL271915A patent/IL271915A/en unknown
-
2021
- 2021-08-29 US US17/460,225 patent/US11875104B2/en active Active
-
2024
- 2024-01-12 AU AU2024200221A patent/AU2024200221A1/en active Pending
- 2024-01-15 US US18/412,656 patent/US20240220706A1/en active Pending
- 2024-03-14 JP JP2024040504A patent/JP2024075645A/ja active Pending
Patent Citations (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2002202937A (ja) * | 2000-12-28 | 2002-07-19 | Ibi Kk | ウェブサイト自動作成装置、ウェブサイト自動作成システム、ウェブサイト自動作成方法、及び、記録媒体 |
JP2004530191A (ja) * | 2001-02-22 | 2004-09-30 | アクセンチュア グローバル サービスィズ ゲーエムベーハー | ウェブ・サービスで構成された、インタネット・ホスティング・ビジネス・アプリケーションの開発システム |
JP2004005527A (ja) * | 2002-03-28 | 2004-01-08 | Yosuke Hiratsuka | 階層型サイト情報作成プログラム |
JP2006146506A (ja) * | 2004-11-18 | 2006-06-08 | Image:Kk | Webサイト更新システム、Webサイト更新方法およびWebサイト更新プログラム |
JP2008535056A (ja) * | 2005-03-24 | 2008-08-28 | ヒューレット−パッカード デベロップメント カンパニー エル.ピー. | 埋め込みウェブベース管理方法 |
JP2009176296A (ja) * | 2007-12-27 | 2009-08-06 | Nippon Institute Of Agroinformatics Ltd | Web文書編集方法 |
JP2010140076A (ja) * | 2008-12-09 | 2010-06-24 | Fujitsu Ltd | Webページ編集プログラム及びWebページ編集装置 |
JPWO2012014248A1 (ja) * | 2010-07-25 | 2013-09-09 | 株式会社コアアプリ | ファイル公開管理コンピュータプログラム、ファイル公開管理コンピュータシステム |
JP2016519347A (ja) * | 2013-03-14 | 2016-06-30 | ウィックス.コム リミテッド. | データリストを利用したウェブサイト構築のデバイス、システム、および方法 |
Also Published As
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP2020530610A (ja) | 仮想ウェブページのプレビュー中におけるデータベースの編集 | |
Kouzis-Loukas | Learning scrapy | |
US9361390B2 (en) | Web content management | |
JP2009543166A (ja) | ページによってページ・レイアウトを定義するためのコンピュータで実行される方法、コンピュータ・プログラム、およびデータ処理システム | |
US20170185686A1 (en) | App Onboarding System for Developer-Defined Creation of Search Engine Results | |
Paz | Beginning ASP. NET MVC 4 | |
Rizzo et al. | Professional SharePoint 2010 Development | |
Rad et al. | Pro Power BI Architecture | |
Ragupathi | Learning ASP. NET Core MVC Programming | |
Manfield | Joomla for Developers | |
Vogelsteller et al. | Meteor: Full-Stack Web Application Development | |
Prettyman et al. | Interfaces, Platforms, and Three-Tier Programming | |
Gaspar | Learning Pentaho CTools | |
Satav | News on world map | |
Arellano Bartolomé | Open Personalization: Involving Third Parties in Improving the User Experience of Websites | |
Root et al. | Creating Reports with SSRS | |
SIKORA | ADMINISTRATION INTERFACE FOR INFORMATION SYSTEM FOR MUSICIANS | |
Latifi | Architecture patterns in web applications and implementation of find local food |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20210721 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20220628 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20220630 |
|
A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20220927 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20221128 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20230322 |
|
A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20230622 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20230817 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20231114 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20240314 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20240315 |
|
A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20240409 |