ผลต่างระหว่างรุ่นของ "CuneiForm"

CuneiForm (ดูต้นฉบับ)

รุ่นแก้ไขเมื่อ 09:35, 9 เมษายน 2567

เพิ่มขึ้น 2,482 ไบต์ , 9 เมษายน 2567

→‎Getting Data

Tenko

ผู้ดูแลระบบสิทธิแต่งตั้ง, ผู้ดูแลระบบอินเตอร์เฟซ, ผู้ดูแลระบบ

1,844

การแก้ไข

@@ บรรทัดที่ 236: / บรรทัดที่ 236: @@
 ==== Getting Data ====
-By default, a CuneiForm only displays either the default values (as specified during form definition) or the values fed explicitly before the page is sent. Once the page components are loaded, the form can then ask for data from the server in a separate HTML request. These attributes below dictate the form's behaviours regarding data request:
+Under the normal work flow, CuneiFox sent only blank components to the client first to render the page. At this stage, a CuneiForm only displays either the default values (as specified during form definition) or the values fed explicitly before the template is sent. Once the page components are loaded, the elements (including CuneiForms) can then fetch data from the server, each using a separate HTML request.
-* '''populate_route''' ''(url_for_string)''
-* '''populate_suppress''' ''([str,])''
+These attributes below dictate the form's behaviours regarding data request:
-* '''populate_id''' ''([str,])''
+* '''populate_route''' ''(url_for_string)'': Route to which a data fetch request is to be sent. (The attribute defaults to {{code|lang=python|False}} for a form that does not need this function.)
+* '''populate_suppress''' ''([str,])'': The list of data fetch modes to suppress. (Refer to Note #1 for available fetch mode.) A most common reason to prevent any single CuneiForm to send a fetch request is so that a page-wide fetch request can be used in its stead. A page-wide request fetch the data for several components on the same page and populate them at once (See [[Multi-component Page]]).
+* '''populate_id''' ''([str,])'': (Defaults to {{code|lang=python|False}} if not specified otherwise.) The list of fields whose data are to be parts of a data fetch request. For example, if a fetch request needs to know the {{code|id}} of the fetch target, then the content of the {{code|id}} field needs to be a part of the fetch request. Members of this list may take the formats listed below, and refer to Note #2 for additional information:
+** '''{{code|lang=python|<field_name>}}''' (like {{code|lang=python|'id'}}) refers to a field of the same CuneiForm
+** '''{{code|lang=python|master.<field_name>}}''' (like {{code|lang=python|'master.id'}}) refers to a field of the Master CuneiForm or CuneiTable. (Usually the header form of a [[Multi-component Page]], see the article to learn how to declare a master.)
+** '''{{code|lang=python|window.<field_id>}}''' (like {{code|lang=python|'window.pagenav'}}) refers to a field with id {{code|lang=python|'<field_id>'}}.
+*** If {{code|lang=python|<field_id>}} contains a dash sign ({{code|lang=python|-}}), the prefix {{code|lang=python|window.}} can be safely omitted. This is to facilitate references to a field of another arbitrary CuneiForm which normally goes by id {{code|lang=python|<form_id>-<field_name>}}
+'''NOTE #1:''' CuneiForm only has one fetch mode: '''{{code|lang=python|'grab'}}'''. However, the attribute {{code|populate_suppress}} takes a list format to mirror a similar attibutes in [[CuneiTable]], which supports more fetch modes.
+'''NOTE #2:''' On the client-side, CuneiFox automatically binds {{code|lang=javascript|'change'}} event on the listed elements to the re-fetch and re-populate actions. If such an event-binding is not desirable, prefix the member in {{code|populate_id}} with {{code|#}}. For example, {{code|lang=python|'#id'}} and {{code|lang=python|'#master.docdate'}}.
 ==== Sending Data ====