Linuxは、開発環境が40年前と同レベル (819ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) ﾚｽ栞 あぼーん
222(1): 2018/09/09(日) 12:21:19.06 ID:gnEdZr1c(1/59)調 AA×
>>221>>1
外部ﾘﾝｸ[html]:help.adobe.com
外部ﾘﾝｸ:ns.adobe.com
外部ﾘﾝｸ:example.com
224(2): 2018/09/09(日) 12:23:23.57 ID:gnEdZr1c(2/59)調 AA×
外部ﾘﾝｸ:example.com
226: 2018/09/09(日) 12:35:12.24 ID:gnEdZr1c(3/59)調 AAS
だから最初からそう言ってる。
XML設定ファイルは、アプリが個々に要素を定義するんじゃなくて
共通の仕様を作るべきだったと
そうすれば設定ツールは汎用のものを別に開発できて、
全てのXML設定ファイルをそのツールで設定でき
開発者も独自の設定ツールを作ることがなくて楽になってたんだよ。
GUI大嫌いって開発者でも、XML設定ファイルにするだけで
テキストエディタでも設定できるし、設定ツールでも設定できるようになってた
さらに作り込めば使いやすいUIを作れるし、多言語化もできてた
だから間違った方向に進んだよなーって思ってるわけだよ。
228(2): 2018/09/09(日) 15:38:52.98 ID:gnEdZr1c(4/59)調 AAS
>>227
> 特定目的設定XMLで表現できない項目が出てきたらどうすんだ
結論を先にいうとそういうのはないと思ってる
設定のしやすさは別として（後述するがこれは解決できる問題）
どんな設定であっても、キーとバリューのリストで設定できる
例えば、Firefoxのabout:config の例
設定名: devtools.performance.timeline.hidden-markers
型: 文字列
値: ["Composite","CompositeForwardTransaction"] (JSON文字列かな？）
このような単純なキーとバリューのリストで保存されている。
これを見る限り、型としては最低限、文字列、整数値、真偽値 があれば必要十分なのだろう
まあJSON文字列とか卑怯な物使ってるからねｗ
もう少し便利にするならば、レジストリを参考して「複数行文字列」「変数展開が可能な文字列」や
キーバリューのリスト型みたいなものがあるといいだろう
で、開発の初期段階であれば、どんなに複雑な項目であっても
最悪JSON形式の文字列でテキストエディタで保存すればOKということ。
JSON設定ファイルなんてものがあるんだから、それぐらい苦じゃないだろう？ｗ
でも、設定のしやすさの問題が残っている。エンドユーザーにとってはJSON文字列で設定するのは大変。
そこで出てくるのが・・・というかもったいぶって言うほどのことではなくウェブが
すでにその問題を解決してる。CSSとJavaScriptでインターフェースを作ればいい。
そしてその値をフォームにマッピングする（例えばJSON形式で保存）
当然外部CSSとJavaScriptを使うため、設定ファイル自体はシンプルな状態を保つことができるし、
テキストエディタで編集したい人はそのまま編集できる。
それでいて設定ファイルをシームレスにユーザーインターフェースへとつなげることができる。
ウェブ技術の応用だからUIを作れる人は多いだろうし、なによりUIの作り込みは後からやれるから開発者の負担も減る
230: 2018/09/09(日) 16:03:23.98 ID:gnEdZr1c(5/59)調 AAS
>>229
ぜんぜん？ だって>>224を見てよ。
タグは使い方を変えただけ。本質的には今の使い方と変わらない
今までと同じようにテストエディタで編集できる
それに加えて汎用の設定ツールの開発が可能になる。
設定ツールの仕様がブラウザ並みに大変になる思うかもしれないが、
CSSやJavaScriptはオプショナルに過ぎない。搭載は必須ではない。
ネスケ4とかガラケーやテキストブラウザレベルのものがあれば
設定ツールとして機能する。膨大でもなんでもない。
どうせ今だって複雑な項目をテキストエディタで編集してるんだろ？
ならそこだけ諦めて <textarea>で編集すればいいだけだよ。
そして将来高機能な設定ツールが登場すれば、CSSとJavaScriptで
リッチなUIが使えるようになるし、それがでるまでは
テキストエディタやテキストブラウザ等で設定できる
そして設定ツールは汎用なので独立して開発できる。
なにかアプリを作ったときエンドユーザーが簡単に使えるようにと
アプリ開発者がオリジナルの設定ツールを作る必要はないわけだ。
231: 2018/09/09(日) 16:11:00.00 ID:gnEdZr1c(6/59)調 AAS
重要なのは、テキストエディタで編集するのなら、
今のXML設定ファイルとほぼ同じ使い勝手でありながら、
将来的に拡張していけるということ、
今よりも悪くなっているところがなにもない
233: 2018/09/09(日) 16:15:20.76 ID:gnEdZr1c(7/59)調 AAS
一言悪口を言わないと気がすまないようだなｗ
何かわからなかったら言えば説明するし、
わかったなら、そのことについてコメントしろよ。
なんで書いてあることをいつも見なかったことにして悪口だけ言うんだ？
お前の言うことには中身がない。
頭悪そうに見えるのはお前の方だよ
235: 2018/09/09(日) 17:00:12.12 ID:gnEdZr1c(8/59)調 AAS
人の指摘ってどれのこと？
238(1): 2018/09/09(日) 17:34:43.42 ID:gnEdZr1c(9/59)調 AAS
>>236
お前がわかってないじゃんｗ
XMLは何の略か知ってる？ eXtensible Markup Languag
日本語にすると「拡張可能なマークアップ言語」
「拡張されたマークアップ言語」ではないんだよ。
拡張可能が意味する所は、拡張して使いましょうってこと。
XMLの仕様を変える？XMLの仕様のどこが問題なんだ？
ODFなど様々なXMLベースの仕様が作れるほど拡張可能な素晴らしいマークアップ言語だろ
ただ世の中XMLを間違った拡張をした独自の設定ファイル形式が多いってだけ
それはXMLの仕様や進化とは関係ない。そもそもXMLの仕様はシンプルではずっと前から
安定していて、仕様を変える必要性もないほど柔軟で拡張可能に作られている
俺はXMLの仕様自体には文句をつけていない。アプリ独自の拡張方法に文句をつけてる
俺が言ってる意味ちゃんと理解できてる？XMLがどういうものかもわかってないでしょ？
君どうも知識が浅いよ。具体的じゃなくてどうとでも取れるようなことしか言ってない。
> マークアップも一応プログラミング言語だから
ぜんぜん違う。チューリング完全であることはプログラミング言語に要求されることの一つだが、
マークアップ言語はチューリング完全ではない
そういうポロッと素人レベルのことを漏らすから、知識浅いとわかる
> PC上でできることは何でもできる。っていうだけのことでしょ。
そんな意味のないことは一言も言ってない。お前が理解してない証拠。
（俺が言ってることを理解出来ないが）きっと誰でもわかるようなことを言ってる違いないと
お前が思って、誰でもわかるようなことを言ってる例として出しただけでしょ？
239: 2018/09/09(日) 17:37:49.44 ID:gnEdZr1c(10/59)調 AAS
>>237
何が言いたいの？
俺はXMLベースの設定ファイルの多くが間違った拡張をしてると言ってるだけ？
で、お前は？オントロジー？
XMLベースじゃなくても、頑張ればなんでもできるって
一般的な話をしてるだけ？
俺はそんな話はしてないよね。
240(1): 2018/09/09(日) 17:40:08.49 ID:gnEdZr1c(11/59)調 AAS
変な所にはてながついちゃったｗ
俺はXMLベースの設定ファイルの多くが間違った拡張をしてると言ってるだけ
俺は今の現実を批判してるのであって、
お前みたいに存在しないものを作るなんて話はしてない
架空の世界の話はしてないんだよ
241: 2018/09/09(日) 17:41:01.71 ID:gnEdZr1c(12/59)調 AAS
> 膨大なアプリじゃないと言い切るならどんなブラウザでもそのくらいはできるし大丈夫だよね。
XMLベースならテキストエディタで変更できるんでー
大丈夫ですよーｗ
243: 2018/09/09(日) 17:42:10.71 ID:gnEdZr1c(13/59)調 AAS
だからテキストエディタで設定できるって（笑）
何度も言わせんなや
248(2): 2018/09/09(日) 17:54:57.06 ID:gnEdZr1c(14/59)調 AAS
>>246
それの何処が矛盾してるんだ？
・XMLは拡張可能なマークアップ言語
・いろんな人が拡張してるが、アプリ独自の設定ファイルは
間違った拡張をされている
・設定ファイル用のXML拡張の仕様を作れ
やっぱり何も間違ってないな。
お前がXMLを理解してないから、矛盾に見えるんだろう？
249(1): 2018/09/09(日) 17:55:36.13 ID:gnEdZr1c(15/59)調 AAS
>>247
>>220に書いた
254(1): 2018/09/09(日) 18:34:01.45 ID:gnEdZr1c(16/59)調 AAS
>>250
XMLの拡張の意味も知らないで突っかかってきてるのかよｗ
XMLの言葉の意味の通り
「eXtensible Markup Language」
「拡張可能なマークアップ言語」
XMLの拡張とは何を意味しているかは、
XMLの意味を調べればわかる（すでにこのスレに書いた）
俺が書いたことが信用出来ないならググれ、と言おうと思ったが、
仮にググったら、良い説明があったので以下を読め
外部ﾘﾝｸ[html]:www.atmarkit.co.jp
↑にはどういう勘違いがあるかも書いてあるから、
XMLが本当はどういうものかがわかるぞｗ
255: 2018/09/09(日) 18:34:25.00 ID:gnEdZr1c(17/59)調 AAS
>>251
すでにこのスレに書いた
256: 2018/09/09(日) 18:34:46.46 ID:gnEdZr1c(18/59)調 AAS
>>253
その話はしてないと言ったはずだが？
258: 2018/09/09(日) 19:53:37.52 ID:gnEdZr1c(19/59)調 AAS
>>257
それ俺が質問してるんだわ
XMLは何の略か知ってる？ eXtensible Markup Languag
日本語にすると「拡張可能なマークアップ言語」
「拡張されたマークアップ言語」ではないんだよ。
259: 2018/09/09(日) 19:54:10.63 ID:gnEdZr1c(20/59)調 AAS
おれがXMLとはなにか知ってる？と聞いてるのに
聞き返してるのは知らないってことなんかね？
260: 2018/09/09(日) 19:58:25.24 ID:gnEdZr1c(21/59)調 AAS
いつものことだがこういう輩は自分で説明すると
（どこがも言わずに）それは違う。やっぱりわかってないって
いうだけで逃げるので、ソースを出すことにしてる
外部ﾘﾝｸ:support.office.com
XML タグを利用することで、自分が見ているデータの種類がはっきりわかります。
たとえば、それが猫に関するデータであることがわかります。猫の名前や年齢などを簡単に見つけられます。
ほとんどすべてのデータ構造を定義するタグを作成できることから、XML は "extensible (拡張可能)" と呼ばれています。
262: 2018/09/09(日) 20:02:41.74 ID:gnEdZr1c(22/59)調 AAS
すでに何度も書いてる。このスレを検索しろ
263: 2018/09/09(日) 20:03:32.86 ID:gnEdZr1c(23/59)調 AAS
というか、調べればわかることをわざわざ書かせるのは
揚げ足取り目的だってわかってるからさぁ
264: 2018/09/09(日) 20:05:15.01 ID:gnEdZr1c(24/59)調 AAS
外部ﾘﾝｸ[htm]:park18.wakwak.com
266: 2018/09/09(日) 20:09:51.26 ID:gnEdZr1c(25/59)調 AAS
ODFを展開して出てくるXMLそれぞれが
XMLを拡張（独自タグを定義したもの）になってる
で、揚げ足取りは？ｗ
268: 2018/09/09(日) 21:18:19.71 ID:gnEdZr1c(26/59)調 AAS
？
メタフォーマットであるXMLのフォーマットを決める、スキーマを定義する、ことにすぎないことを
XMLの拡張というんですよ？
なんだろう？最もすごいものじゃないと拡張と言っちゃいけないとでも思ってたの？
へんだなぁ。俺じゃなくて
XML（eXtensible Markup Language）という名前をつけた人に
言うべきことでしょう？
XMLは拡張可能なマークアップ言語ですよ？
269: 2018/09/09(日) 21:19:09.68 ID:gnEdZr1c(27/59)調 AAS
なんでも自在な機能がもてるとか誰が言ったんですかねぇ。
270: 2018/09/09(日) 21:27:25.69 ID:gnEdZr1c(28/59)調 AAS
俺「XMLとは拡張可能なマークアップ言語です」
馬鹿「拡張といったな？」
俺「言ったけど？」
馬鹿「ぼくのかんがえたさいきょうの設定ファイルってことだな？」
俺「（そんなことなにもいってないけど？）」
馬鹿「スキーマを定義することにすぎないことをXMLの拡張なるものと思い込んでるな？」
俺「（そのとおりだろ？）
馬鹿「XMLの拡張というものは・・・・そのとおりだ」
俺「（思い込んみは間違いだ！って言うんじゃないのかよ？）」
馬鹿「拡張という言葉を使うと自在な機能を持ってると思ってるな？」
俺「（何言い出してるんだろうこいつ？）」
馬鹿「妄想も拡張しているようだ。」
俺「（それ言い出したの全部お前じゃん）
271: 2018/09/09(日) 21:34:42.68 ID:gnEdZr1c(29/59)調 AAS
あー、>>267が言いたいことがわかったわｗ
XMLを拡張して作るXMLベースの設定ファイルのスキーマ
今のアプリの設定ファイルが間違ってると言ったろ？
>>267はその間違ったXMLベースの設定ファイルに
基づいて発言してる。
つまり>>267は、アプリケーション固有のスキーマを作る話をしてるから
スキーマを定義すると、アプリケーションを機能追加（拡張？）できなくなると言ってる。
あほやな。いや、大部分のXMLベースの設定ファイルは
アプリケーション固有のスキーマを作ってるから、
>>267も含めてみんな間違ってるなーっていうことか
汎用のXML設定ファイルっていうのは（どういうものかは上に書いたので探せ）
アプリケーション固有ではなく、スキーマを定めたところで、
アプリケーションの機能追加を妨げるものじゃない
固定するのは設定ファイルのスキーマだけ
そのスキーマにはアプリケーション固有のスキーマ定義はないから
アプリケーションは自由に「拡張」できる。
272: 2018/09/09(日) 21:37:24.67 ID:gnEdZr1c(30/59)調 AAS
だいたいHTMLを参考にしてる点で気づかんかな？
HTMLなんかスキーマが定められてフォーマットが固定されてるのに
いろんなサイトやウェブサービスが作れるだろと
274: 2018/09/09(日) 22:04:39.82 ID:gnEdZr1c(31/59)調 AAS
>>273
えとさぁ、お前、設定ファイルの話とアプリの機能をごっちゃにするの止めたら？
馬鹿らしい。
設定ファイルの形式なんて、レジストリとか見れば、固定でいいってわかるだろ。
固定っていうのは（最低限）キーとバリューの組み合わせが保存できればいいってこと
どうせお前は馬鹿だから、キーの名前を固定にするのと
ごっちゃにしてるんだろうけどなｗ
ともかく、HTMLのフォームが、inputとselectとtextareaとグループ分け程度の
少ないスキーマ定義で、実際にいろんなウェブサービスに
対応できてるんだから、現実を受け入れようね？
278: 2018/09/09(日) 22:17:01.61 ID:gnEdZr1c(32/59)調 AAS
また>>220をコピペすればいい？
>>216
何の意味って、最初に言ったとおり、
世の中はXMLの使い方を間違ったよなーって話をしてるだけ
>>217
標準化しようじゃなくて
世の中はXMLの使い方を間違ったよなーって話をしてるだけ
>>218
仕様を書く必要はないよ
世の中はXMLの使い方を間違ったよなーって話をしてるだけ
>>219
世の中はXMLの使い方を間違ったよなーって話をしてるだけ
279(1): 2018/09/09(日) 22:18:37.74 ID:gnEdZr1c(33/59)調 AAS
>>275
俺は最初から、設定を記録するのに必要なスキーマの話しかしてない
世の中のアプリは、アプリ固有のオレオレスキーマを作成して
単に編集しにくいだけで、XMLを使用する意味をなくしてしまってる。
世の中はXMLの使い方を間違ったよなーって話をしてるだけ
281(1): 2018/09/09(日) 22:23:04.42 ID:gnEdZr1c(34/59)調 AAS
そして馬鹿は極端だから、
「固定っていうのは（最低限）キーとバリューの組み合わせが保存できればいいってこと」
と書いていても、（最低限）の部分を
もうすっかり忘れているｗｗｗ
284: 2018/09/09(日) 22:28:22.35 ID:gnEdZr1c(35/59)調 AAS
>>280
CSVだったら入力インターフェースが作れない
設定の値しか書いてないから、設定が取りうる値などがわからない
例えば、sambaのmap to guestという項目は「Never」「Bad User」「Bad Password」の
いずれかの値を入れることができるが、そのことが設定ファイルには書かれていない
（コメントとして書かれている場合があるかもしれないぐらい）
設定ファイルでありながらHTMLのフォームと同じような
スキーマを採用することで、設定ツールを作ることが可能になる
あー、何度言えば良いんだろうｗ
スキーマにはアプリ固有のものは含まれないから、
HTMLが、まさにHTMLがそうしているように、
汎用の設定ツールで設定が可能になる。
アプリ開発者は単に設定ファイルにHTMLフォームライクな
XMLを拡張して作った汎用のXML設定ファイルを採用するだけ
アプリ開発者は設定ツールを作ること無く、
初心者は汎用の設定ツールを使って設定できるようになる。
何度言えば理解しますかね？
285: 2018/09/09(日) 22:28:56.81 ID:gnEdZr1c(36/59)調 AAS
>>283
>>216
何の意味って、最初に言ったとおり、
世の中はXMLの使い方を間違ったよなーって話をしてるだけ
>>217
標準化しようじゃなくて
世の中はXMLの使い方を間違ったよなーって話をしてるだけ
>>218
仕様を書く必要はないよ
世の中はXMLの使い方を間違ったよなーって話をしてるだけ
286(1): 2018/09/09(日) 22:31:43.54 ID:gnEdZr1c(37/59)調 AAS
今の設定ファイルはコメントで、設定方法が書かれているが、
まあこれがまさにテキストエディタ用のインターフェースなわけだが
設定値のみ書かれていればいいならコメントは要らない
コメントはまさにテキストエディタで編集する人が
読むためのもの
でも設定ファイルのコメントは英語でしか書かれていない。翻訳の仕組みがないからだ。
あるとすれば設定ファイルにずらーっと何カ国後もコメント書くぐらいだなｗ
こういう問題も、まともなXML設定ファイルを作れば多言語対応も可能になるだろう
289(1): 2018/09/09(日) 22:33:37.24 ID:gnEdZr1c(38/59)調 AAS
>>287
主張できるが？
だからなに？
290: 2018/09/09(日) 22:34:00.31 ID:gnEdZr1c(39/59)調 AAS
>>288
上に例を書いた。探せ
292(2): 2018/09/09(日) 22:40:24.55 ID:gnEdZr1c(40/59)調 AAS
例えば、sambaのmap to guestという項目は「Never」「Bad User」「Bad Password」の
いずれかの値を入れることができるが、そのことが設定ファイルには書かれていない
いやコメントでこう書かれているかもしれない
# ○○をするための項目です（という英語）
# 「Never」「Bad User」「Bad Password」のいずれかの値を入れられます。
# デフォルトは「Never」です。
map to guest=Never
というものが書いてあってもここから設定ツールは作れない
CSV形式でも設定ツールは作れない。
HTMLのフォームライクなXML設定ファイルにすれば設定ツールを作れる
<label for="map-to-guest" >"○○をするための項目です（という英語）</label>
<select id="map-to-guest" name="map to guest">
<option selected default>Never</option>
<option>Bad User</option>
<option>Bad Password</option>
</select>
この中には設定値、設定の候補、デフォルト値が含まれている。
今までどおりテキストエディタで編集もできる
293(1): 2018/09/09(日) 22:40:58.34 ID:gnEdZr1c(41/59)調 AAS
> そしてお前のさいきょうXMLで表現できない設定記述機能要望（アプリの機能じゃねえぞ）はどうするの？
ない
295: 2018/09/09(日) 22:42:14.10 ID:gnEdZr1c(42/59)調 AAS
>>294
あ、その事（笑）
ExcelでCSV編集しても、値しか入れられないだろ。
取りうる値なんかわからない
297(1): 2018/09/09(日) 22:44:22.51 ID:gnEdZr1c(43/59)調 AAS
>>296
アプリの機能じゃねえぞ
どんなアプリが増えようが、設定はすべて
キーとバリューだけで表現できる
（便利だと思うならその他の形式をいくつか増やしてもいいが）
298: 2018/09/09(日) 22:45:36.68 ID:gnEdZr1c(44/59)調 AAS
ほんとなぁ、設定の値の話をしてるのに
結局、ID:3OE6BV46 自身が、アプリの種類が増えたらどうするの？
なんて言ってるんだもんなぁｗ
アプリの機能を気にしてるのはお前じゃん
301: 2018/09/09(日) 22:50:45.48 ID:gnEdZr1c(45/59)調 AAS
>>299
え？テキストエディタを使った場合の話？
アプリ独自にテキスト形式で、map to guestをmap to guestoooooと書くのを防ぐ方法あるんですか？
CSV形式で、以下同文
テキストエディタを使っている以上不可能でしょｗ
そんなの当たり前。
だから設定ツールが重要になるわけですが？
でもアプリ独自のテキスト形式やcsv形式だと、その設定ツールを
アプリごとに作らなければいけない
あぁ、無駄無駄。時間の無駄
HTMLのフォームライクなXML設定ファイルなら、
その設定ツールで間違った値を設定することはありませんね。
そして汎用で使えるから、アプリ開発者の負担が減りますね。
今のXMLはアプリ固有のスキーマになって、汎用の設定ツールなんか
作れないから、世の中はXMLの使い方を間違ったよなーって話をしてるだけ
303(1): 2018/09/09(日) 22:52:23.35 ID:gnEdZr1c(46/59)調 AAS
>>300
バイナリデータを含む全てのデータは、
エンコードすることで、テキスト文字列で表現可能だから
（必ずしもそうしろと言ってるわけじゃない）
305(1): 2018/09/09(日) 22:53:22.42 ID:gnEdZr1c(47/59)調 AAS
>>302
それお前なｗ
アプリがどんな機能を持ってようが
設定は（最低限）キーとバリューの組み合わせが保存できれば十分
306(1): 2018/09/09(日) 22:54:22.25 ID:gnEdZr1c(48/59)調 AAS
>>304
証明どころか実装がある。
Base64はどんなバイナリデータであっても
テキスト文字列に変換できる
308: 2018/09/09(日) 22:56:06.10 ID:gnEdZr1c(49/59)調 AAS
>>307
頭が悪いなｗ
バイナリデータをテキスト文字列に変換できるのなら、
お前が不安に思ってる、どんな表現であっても
単一のテキスト文字列に変換できるってことだよ
310(1): 2018/09/09(日) 22:57:46.53 ID:gnEdZr1c(50/59)調 AAS
JSONなんか、文字列、数値、真偽値、配列、連想配列
たったこれだけのもので、どんな複雑なものでも表現できるからな。
一体何が表現不可能だと思ってるのか
わけがわからない
311(1): 2018/09/09(日) 22:59:00.55 ID:gnEdZr1c(51/59)調 AAS
>>309
やっぱりさ、お前
まーた、アプリ固有のスキーマの話してるだろｗ
アプリ固有のものなんて無いんだから、
どんなアプリのものだって対応可能
いい加減アプリの機能と設定をごっちゃにするの止めたら？
314(1): 2018/09/09(日) 23:00:13.64 ID:gnEdZr1c(52/59)調 AAS
>>312
なんで実装があるのに証明にこだわってるの？
Base64でエンコードすれば、どんな設定だって
文字列で保存できるじゃん
316: 2018/09/09(日) 23:03:42.68 ID:gnEdZr1c(53/59)調 AAS
>>313
だって>>312でまた「全ての」アプリの設定記述を満たすものがあるのかとか言ってるじゃん
つまり「一部の」アプリ設定記述を満たすものはあるって
納得してるんでしょ？
そして「一部」に含まれない、もっと別の高度なアプリの機能の
設定記述を満たすものはあるのかー！！！って
アプリの機能を気にしてるじゃんｗ
317: 2018/09/09(日) 23:06:51.23 ID:gnEdZr1c(54/59)調 AAS
>>315
> テキストファイルとテキストエディタがあればどんな設定でも記述できるという主張かね？
そりゃそうだろうね
使いやすいかどうかは別として
最初からそう言ってるんだが。
どんな設定だろうが、テキストに変換できる以上
テキストエディタで編集は可能。
ただし便利なインターフェースを作るためには
設定値だけでは無理。
メタ情報が必要。XML設定ファイルであれば
そういうメタ情報を入れることはたやすいが、
世の中間違って使い方をして、独自のXML設定ファイルばっかり作るから
汎用の設定ツールを作ることができない
318: 2018/09/09(日) 23:07:46.41 ID:gnEdZr1c(55/59)調 AAS
今日はあと一時間切ったぞ。
100レスまであと45もあるじゃないか
319: 2018/09/09(日) 23:18:33.21 ID:gnEdZr1c(56/59)調 AAS
>>228ですでに書いたこと（わざとなのか知らんが、すでに答えたことを繰り返されるのは面倒だ）
> 特定目的設定XMLで表現できない項目が出てきたらどうすんだ
結論を先にいうとそういうのはないと思ってる
設定のしやすさは別として（後述するがこれは解決できる問題）
どんな設定であっても、キーとバリューのリストで設定できる
例えば、Firefoxのabout:config の例
設定名: devtools.performance.timeline.hidden-markers
型: 文字列
値: ["Composite","CompositeForwardTransaction"] (JSON文字列かな？）
このような単純なキーとバリューのリストで保存されている。
これを見る限り、型としては最低限、文字列、整数値、真偽値 があれば必要十分なのだろう
まあJSON文字列とか卑怯な物使ってるからねｗ
もう少し便利にするならば、レジストリを参考して「複数行文字列」「変数展開が可能な文字列」や
キーバリューのリスト型みたいなものがあるといいだろう
で、開発の初期段階であれば、どんなに複雑な項目であっても
最悪JSON形式の文字列でテキストエディタで保存すればOKということ。
JSON設定ファイルなんてものがあるんだから、それぐらい苦じゃないだろう？ｗ
でも、設定のしやすさの問題が残っている。エンドユーザーにとってはJSON文字列で設定するのは大変。
そこで出てくるのが・・・というかもったいぶって言うほどのことではなくウェブが
すでにその問題を解決してる。CSSとJavaScriptでインターフェースを作ればいい。
そしてその値をフォームにマッピングする（例えばJSON形式で保存）
当然外部CSSとJavaScriptを使うため、設定ファイル自体はシンプルな状態を保つことができるし、
テキストエディタで編集したい人はそのまま編集できる。
それでいて設定ファイルをシームレスにユーザーインターフェースへとつなげることができる。
ウェブ技術の応用だからUIを作れる人は多いだろうし、なによりUIの作り込みは後からやれるから開発者の負担も減る
320: 2018/09/09(日) 23:19:48.26 ID:gnEdZr1c(57/59)調 AAS
俺は面倒だから、基本的にIDを見てないんだが、
みてみたら同じやつじゃんｗ
なんで繰り返しおんなじ質問するのかね？
321: 2018/09/09(日) 23:24:45.36 ID:gnEdZr1c(58/59)調 AAS
言い方を変えてもいいな
どんな荒唐無稽な設定データを想像してるのか知らんが、
テキスト形式の設定ファイルでは設定できないデータが
あるというのなら諦めればいいだけだろう。
バイナリデータでさえBase64で保存できるというのに
それがどんなものが設定ファイルに書けないのか、
俺にはわからんが、それは諦めるという方向でいい。
で、諦めなければならないもの例をあげてくれ。
俺には全く思いつかない。まあ無いんだろう。
そういや今はCSSファイル（当然テキスト形式）に
画像データをBase64エンコードして入れられることを思い出した。
322(2): 2018/09/09(日) 23:34:50.22 ID:gnEdZr1c(59/59)調 AAS
おとなしくなったようなので、続き（？）を
汎用のXML設定ファイル形式（おれのかんがえたさいきょうってやつｗ）は、
HTMLのフォームを参考にすれば良いと言ったが、欠点もある
そこはHTMLフォームを厳守しろっとは言ってないので変えればいいだけだが、
リストやハッシュデータの扱いが難しい。もちろんできないわけじゃない。
PHPやRubyはフォームの名前を工夫することでリストやハッシュを表現している
例えばこんな感じだ
<form>
名前：<input type="text" name="personal[name]">
住所：<input type="text" name="personal[address]">
電話：<input type="text" name="personal[telephone]">
</form>
これで少なくともJSONなみの表現力は得られるわけだがやっぱりダサいと思う
<form>
<fieldset name="personal">
名前：<input type="text" name="name">
住所：<input type="text" name="address">
電話：<input type="text" name="telephone">
</fieldset>
</form>
こんな感じで直感的な仕様にしたほうが良いだろうな
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 1.667s*