元スレ【PHP】フレームワークについて語るスレ13【総合】

php覧

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで

751 = :

RubyとかYAMLとか、いろいろ便利だし優れてるっておもうところはたくさんあるけど
導入コストに見合うメリットが足りないんだよねー

752 = :

>>750
行数や階層が増えると構造を理解しにくくない？
XMLならビューワによるけど、タグ単位で閉じたり開いたり出来るから行数が増えても無問題なんだけど。

754 = :

> ・スペースインデントが面倒、またはエラーの温床になる。
それで思い出したが、XMLはスペースの扱いが大変。

たとえば、
<tag></tag><tag></tag>
と
<tag></tag>
<tag></tag>
は別物。</tag>と<tag>の間に改行があるかないかが違う。

<tag><tag></tag></tag>
と
<tag>
　　　<tag></tag>
</tag>
も別物。改行と先頭のタブ（空白）が違う。

無理やり合わせるために、こういう表現で書く場合もあるくらいだｗ
<tag
　　　　><tag></tag
></tag>

参考
http://www.atmarkit.co.jp/fxml/rensai/xmlwomanabou10/learning-xml10.html
http://www.ibm.com/developerworks/jp/xml/library/x-c14n/

755 = :

>>754
お前XML理解してないだろｗ
空白や改行はルートノードの子にあたるテキストノードなんだから別に不思議でも大変でも無いわけだが。


> <tag
>　　　　><tag></tag
> ></tag>

見たことねぇわｗ
パーサ側でホワイトスペース除くなり、該当ノード以外は無視するなりするのが定石じゃね？

757 = :

そろそろ>>663からの壮大なスレ違いの流れが100レスを超える

というわけで、

ここからは「自分の好きな設定ファイルのフォーマットを語るスレ」になります。
俺俺フレームワークで用いるもよし
パスの設定のみに使うもよし
PHPのバリデーションコード自体を仕込むもよし
ではどうぞ

ちなみに俺はCSV

758 = :

今オススメのフレームワークってある?
俺はCakeしか使ったことがないけど、サクッと作るのにオススメのフレームワークとか他にある?

759 = :

ちいたん

っていう流れをもう何度見たことか

762 = :

>>759-761
ありがとう。
fitzgerald、CI、kohana、ちぃたんを検討してみる。
これらでCakePHPよりおすすめな理由ってあれば話題ついでによろしくお願いします。

ちぃたんはまじめにオススメしてくれてるんだろうか・・。

765 = :

>>755
> 見たことねぇわｗ

リンク先も読めないのかよｗ
http://www.ibm.com/developerworks/jp/xml/library/x-c14n/

> <?xml version="1.0" encoding="UTF-8"?>
> <doc>
> <a
> a2="2" a1="1"
> >123</a>
> </doc>

> パーサ側でホワイトスペース除くなり、該当ノード以外は無視するなりするのが定石じゃね？
なんで見やすくしようと思っただけで、
パーサー書き換えないとならんのだ。本末転倒だ。

766 = :

>>765
実践でそんな書き方してる人見たことねーよ。
５年前の情報だよソレ･･･

>> パーサ側でホワイトスペース除くなり、該当ノード以外は無視するなりするのが定石じゃね？
> なんで見やすくしようと思っただけで、
> パーサー書き換えないとならんのだ。本末転倒だ。

リンク先に書かれた書き方が「見やすい」の？
XMLの仕様を理解していればそんな書き方しないで該当ノードのみを抽出するなり、ルートノードに属するテキストノードを削除するなりすると思うんだけど。

ちなみにPHPのXMLパーサは普通に対応している。
PHP読み込み時には空白データとなるが、仕様としては正常なので、
不要ならデータ処理時に省けばいいだけ。

767 = :

>>765
見やすさで言えばリンク先の書き方の方が本末転倒なのではｗ

768 = :

>>766
> 、ルートノードに属するテキストノードを削除するなりすると思うんだけど。
そんなことをしたら意味が変わるだろｗ

> 見やすさで言えばリンク先の書き方の方が本末転倒なのではｗ
XMLの限界だよ。
気づけよｗ

XMLは機械が生成して機械が読み込むためのものであって
人間が読み書きするものじゃない。

769 = :

反論したいなら、きちんと>>754からの流れを読んで書けよな。

>>768
>> 、ルートノードに属するテキストノードを削除するなりすると思うんだけど。
>そんなことをしたら意味が変わるだろｗ

流れ的に、改行とかスペースだけの不要なテキストノードを削除しろって意味だろ？
データ的には正しい仕様なんだから、パーサのせいじゃない。

>> 見やすさで言えばリンク先の書き方の方が本末転倒なのではｗ
>XMLの限界だよ。

何がどう限界なの？改行や空白だけのデータを保持出来ない形式に変えろって事？
お前の頭の理解の限界ってこと？


>XMLは機械が生成して機械が読み込むためのものであって
>人間が読み書きするものじゃない。

ｗ　普通は機械が読み書きする専用のデータにテキスト形式なんて用いないんじゃね？
人間が読むために視覚化されてるんだろう･･･

770 = :

> 流れ的に、改行とかスペースだけの不要なテキストノードを削除しろって意味だろ？

だからそれやったら意味が違うだろｗ

改行やスペースもも立派なデータだ。
スペース1個と空文字は意味が違う。

771 = :

>>770
だから仕様的には正しいって書いてるだろｗ
>>754が、改行やスペースも立派なデータって事を認識しておらず、XMLは面倒とか書いてるから反論してるだけだ。

772 = :

スペースが入っちゃまずいような値とかはAttributeにしときゃ
そもそもこんなアホな話題にならない

っつーかすれ違いいい加減どっか他所でやれよ

773 = :

ああ、少し勘違いしていた。そういう話題じゃないか
どっちにしてもスレ違いだけどな

774 = :

話題の発端自体はスレ違いじゃないんじゃね？ >>663
各フォーマットの信者がムキになっちゃってるみたいだけど･･･

個人的にはPHPなら

ini ＞ xml ≧　php　≧ JSON ≧ YAML

の順かなぁ･･･ケースバイケースだろうけど

ｉｎｉはシンプルで誰にでも解りやすいと思う
xmlは親和性の高さと、拡張性の高さが魅力
phpは簡単な設定振り分けコードも埋め込めるのが魅力
JSONはJSとの親和性が高く、他言語含めパーサの選択肢が多いのも魅力
YAMLは発展途上で、パーサ、知名度的に未知数

という感じ

775 = :

iniは表現力に劣るからなあ。

777 = :

>>775
XMLは冗長だからなあ。

要件に合わせて選択すればいい。

778 = :

>>769
それは間違ってる
汎用のバイナリーフォーマットなんて極わずか

779 = :

>>774
CSVはどの辺に入るかな。
偶に使われるよね、単なる設定でも。

780 = :

>>778
根拠は？

>>779
CSVは設定よりデータとして扱う事が多いかな

781 = :

結局良いとこどりをしたのが
今流行っているYAMLってわけだ。

ini・・・表現力に劣る
XML・・・冗長すぎる。見にくい。
php・・・データではない。コードを入れられてしまう。
JSON・・・コメントが入れられない。

YAML・・・完璧☆

783 = :

>>781がFA

784 = :

YAML も複数行データは面倒じゃん。
つか、YAML を採用する新規オープンソースは少ない、
というか、ほとんどなくない？

785 = :

フレームワークの神、Ruby on Railsをなんと心得ておる

787 = :

YAMLは良いとこどりしたつもりが、中途半端になった良い例。
ケースバイケースで ini / XML / php / JSON を使い分ければいい。

YAMLの利点？無いよｗ
プログラム側で無理矢理YAMLをいかそうとする設計にでもしない限りな。

788 = :

>>785
Rails や Symfony 以外にも
いろんな WAF あるけど、YAML 採用のほうが少ないし、
sf.net にあるのにしても、YAML 採用なんて少ないよね、ということなんだけど。

789 = :

> YAMLの利点？無いよｗ

結局良いとこどりをしたのが
今流行っているYAMLってわけだ。

ini・・・表現力に劣る
XML・・・冗長すぎる。見にくい。
php・・・データではない。コードを入れられてしまう。
JSON・・・コメントが入れられない。

YAML・・・完璧☆

790 = :

>>789
YAMLはシンプルさにかけて、冗長に書くとXMLより読みづらく、PHPのような利点も無く、JSONのようにブラウザとの親和性も無い
って事？

791 = :

YAMLはシンプルで読みやすく安全でJavaScriptからでも読み込めるライブラリがあるってこと。

792 = :

設定ファイルでの用途について話してたんじゃねーの？なんだよブラウザって。

794 = :

YAML厨はこんな所で机上の空論を展開していないで、実績を作ればいいと思うよ。

795 = :

RubyならYAMLなんだけどな
YAMLは好きだが、PHPだと標準で読み出せないってのが大きな減点材料
サーバ立てるたびにspycインストールするのも面倒だし

796 = :

PHPERの実務に役立つ資格って何ですか？
Zendｻｰﾃｨﾌｨｹｰｼｮﾝなんとかとかいう奴いつの間にか終わっててワロタ

797 = :

>>794
それだとこのスレ解散でいいな

798 = :

>>797
ここはフレームワークを語るスレだ

799 = :

Rubyの場合はRubyが使える鯖を探すのから面倒だしどのみち使いづらいわなぁ

800 = :

>>795
> サーバ立てるたびにspycインストールするのも面倒だし

え？　君、既存のライブラリ一切使わないの？

一昔前の人でも、PEARとか使うでしょ？

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / php一覧へ

類似してるかもしれないスレッド

• 【PHP】フレームワークについて語るスレ10【総合】 (1001) - [98%] - 2008/8/24 19:04 ○
• 【PHP】フレームワークについて語るスレ10【総合】 (1001) - [98%] - 2008/12/23 16:48 ○
• 【PHP】フレームワークについて語るスレ12【総合】 (994) - [98%] - 2009/3/19 13:46 ○
• 【PHP】フレームワーク CakePHP　3ホール目【本命】 (1001) - [59%] - 2008/6/19 7:19 ○
• 【PHP】セッションについて語ろう！【PHP】 (829) - [58%] - 2018/6/27 23:16 ○
• 【PHP】フレームワーク CakePHP　4ホール目【v1.2】 (1001) - [57%] - 2008/12/19 21:06 ○
• 【PHP】フレームワーク CakePHP　6ホール目【v1.2】 (933) - [57%] - 2009/8/19 2:06 ○
• 【PHP】フレームワーク CakePHP　5ホール目【v1.2】 (985) - [57%] - 2009/3/7 4:53 ☆
• 【PHP】フレームワーク CakePHP　7ホール目【v1.2】 (1001) - [57%] - 2010/3/18 1:18 ○