- バックアップ一覧
- 差分 を表示
- 現在との差分 を表示
- 現在との差分 - Visual を表示
- ソース を表示
- データアクセス へ行く。
- 1 (2011-10-05 (水) 01:01:17)
- 2 (2011-12-14 (水) 01:29:17)
- 3 (2012-09-20 (木) 07:29:11)
- 4 (2013-03-20 (水) 22:35:06)
- 5 (2013-03-20 (水) 23:16:04)
- 6 (2013-03-20 (水) 23:27:12)
- 7 (2013-03-20 (水) 23:32:18)
- 8 (2013-03-20 (水) 23:44:50)
- 9 (2013-03-20 (水) 23:48:35)
- 10 (2013-03-21 (木) 00:10:34)
- 11 (2013-03-21 (木) 00:19:45)
- 12 (2013-03-21 (木) 11:24:26)
- 13 (2013-03-22 (金) 20:01:28)
- 14 (2013-03-22 (金) 23:14:28)
- 15 (2013-03-25 (月) 05:01:55)
- 16 (2013-04-11 (木) 14:14:01)
- 17 (2013-05-09 (木) 04:41:00)
- 18 (2013-11-09 (土) 20:02:56)
- 19 (2013-11-29 (金) 00:25:29)
- 20 (2013-11-29 (金) 01:11:48)
- 21 (2013-11-29 (金) 01:13:33)
- 22 (2013-11-30 (土) 07:39:40)
- 23 (2014-02-18 (火) 00:28:47)
- 24 (2014-02-24 (月) 06:39:31)
- 25 (2014-03-01 (土) 03:18:50)
- 26 (2014-03-25 (火) 00:55:03)
- 27 (2014-11-01 (土) 18:52:20)
- 28 (2014-11-01 (土) 18:59:13)
- 29 (2014-11-02 (日) 08:58:17)
- 30 (2014-11-08 (土) 00:49:20)
- 31 (2014-11-08 (土) 00:58:10)
- 32 (2014-11-21 (金) 08:51:05)
- 33 (2015-01-05 (月) 00:24:36)
- 34 (2015-01-11 (日) 02:54:18)
- 35 (2015-01-11 (日) 03:10:20)
- 36 (2016-02-26 (金) 00:53:18)
- 37 (2016-08-11 (木) 00:39:56)
- 38 (2016-08-14 (日) 21:50:49)
- 39 (2016-08-15 (月) 16:09:08)
- 40 (2016-08-15 (月) 16:33:11)
- 41 (2016-08-15 (月) 18:30:27)
- 42 (2016-08-15 (月) 18:49:44)
- 43 (2020-11-16 (月) 23:53:56)
- 44 (2021-09-24 (金) 20:25:32)
- 45 (2024-03-03 (日) 02:30:31)
ページの中の要素を指定する記法。
「全てURIで」のURIでも使えるように。ページ名に続いて要素指定。
Wikiの設定／構築に使ったり、クライアントアプリから使ったり、他アプリとの連携用にしたり。
APIとしても使える。MediaWikiでのapi.php(prettified)のようなもの。でもMediaWikiのはページ/本文は投稿されたままのテキスト(WikiText)。Xではページ/本文内の表やリストをデータ構造にしたい。
データアクセス † 
:t/データアクセスより †
未分類 †
あとで:t/データアクセスも追加。
データコンテキストでの呼びだされ時と同じ †
使われるコードはデータコンテキストで呼ばれた時と同じもの。
データコンテキストではどのメソッドを呼び出すかが文脈で決まるが、プログラムコード内では普通にメソッドを指定していい。
セレクターで指定された要素を呼び出す †
要素は別の要素で囲むと、装飾や封印ができる。
打ち消し線で抹消されているなら、データアクセスでも抹消された情報として取得したい。
通常通りを再現するため、データアクセスを「セレクターで指定された要素以外の戻り値を無視するだけのこと」と定義することもできるけど、そうはしない。
データアクセスは、指定された要素だけに問い合わせること。再現性を重視するならルート要素や、上位にある適当な要素に問い合わせればいい。
両方必要？？
セレクター記法 †
CSS Selector風。querySelectorAllで指定する書式。
XPath風(document.evaluate風)も"/"区切りのURIやページ名とひと続きになっていい。(ページ名区切りは変更可能だけど)
旧検索[?]で探す †
要素を選択する処理。
要素を選択するには要素のインスタンス名やクラス名で。旧検索は値（内容）で探すもの。データアクセスからは使わない。
下位展開／埋め込み解決後に †
下位展開の基準から下位ページにアクセス可能に。
埋め込まれた要素にもアクセス可能に。
埋め込み／下位展開後でなければアクセス不可能な要素ができてしまうし、閲覧時に見た通りに使えなければ分かりにくい。
見た通りなので下位展開された下位ページの要素にもアクセス可能にしないと。上位に下位が付いてくるので「継承」とは呼ばない。方向が逆。
:Done/下位展開で下位のページ属性は参照できるか
…はページ/属性（へのデータアクセス）なので別領域の話。ページ/内容にある要素にはデータアクセス可能。つまり下位展開分にもデータアクセス可能。
下位展開ではページをまとめないので、単一ページの場合と同じ。
普段通りの挙動 †
データアクセスでも他の呼び出し方でも処理は同じ。コードも同じ。
HTMLを要求してもHTMLヘッダーも無い断片が返ってくる。
HTMLヘッダーがいるなら連鎖の始まりにあたるデータコンテキストをそういう指定にして、各要素がそれに対応するようにして。
URIもコンテキスト †
URIのクエリー文字列にページ/要素を書くと、そこ専用のデータコンテキストで展開される。
URIのクエリー文字列で指定して呼ぶとき、HTMLとかRSSとかの形式を指定するには基礎となる要素を付け足す。付け足す要素はページ内に存在しなくてもよくなる。リクエスト時だけの即席要素。
URIに書くときはパラメーターの指定がしづらいので、指定できるのはパラメーターを1つしか受けない要素だけ。コンテキストを作るだけの要素なのでURIでしか使い道がない。
（RSSの場合はビュー別のテンプレートのほうで基礎部分を作ったほうがいい）
指定しなければデフォルトのコンテキスト。ページと同じコンテキストを作る要素。
連鎖はできなくていい †
URIでは要素のパラメーターを書きにくいので、（URI上では）複数の要素を組み合わせられなくてもいい。
組み合わせるならページに書いて。それを呼び出すようにして。
記法の代わりになるもの †
セレクター記法の代わりに要素セットやページセットも渡せるように各要素が考慮する。
型別にパラメーター名を変えてもいいし、ひとつのパラメーターを複数の型に対応させてもいい。
インポートと近い †
JSONインポートと実装が一部共通。
フォーマット †
参考に、MediaWikiの例。
http://www.mediawiki.org/wiki/API:Data_formats#Output
データアクセス/ †
- データアクセスでやること[?]