のくす牧場
コンテンツ
牧場内検索
カウンタ
総計:126,363,637人
昨日:no data人
今日:
最近の注目
人気の最安値情報

    元スレ【PHP】PHPフレームワーク総合スレ14

    php覧 / PC版 /
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : - mayaa + 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。
    ←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitter

    901 = :

    クラスの実装をどうするかは、ここでは問題ではない。文字列をオブジェクト型にする事にどういう意味があるか?が問題。

    905 = :

    >>904
    クラス名が紛らわしいな・・・文字列操作で無く、エスケープを主体にしたクラスだよね。
    HtmlStringじゃなくてEscapedHtmlという感じの方がしっくりくるな。

    てか大抵のシステムではエスケープはビューの出力時に一度行えば良いはずなので、
    わざわざ文字列をクラス化するメリットは薄い気がするわ。

    907 = :

    まあ、実装はケースバイケースで適切にすればいいんだ。拡張性を考えるなら、処理を別メソッドに分割した方が良いし、速度を考えるなら、出来るだけメソッド呼出しは減らした方が良い。

    910 = :

    こういう流れ好きだわw

    912 :

    うるせえ!だまってやれ

    913 = :

    一概に言っても

    ・基底フレームワーク
    ・アプリケーションフレームワーク

    とあるからなぁ、一般的にはオープンソースのフレームワークを基底に、独自のフレームワーク(っぽい実装)を作るよね?
    その独自部分のノウハウとかテクニックを聞きたいです先輩!

    914 = :

    Cakeみたいなフルスタックをベースにすると、ビジネスロジック以外の独自な実装をする余地がほぼ無いです。
    むしろビジネスロジック以外で独自色を出そうとするとメンテ性が悪くなり謎の挙動不審に陥りハマりまくる。

    ただし、これは多分、SymfonyやCIも同様。 (・∀・)イイ!! は知らん。

    ちいたんとかは、よく知らんが基本設計がよければ俺色に染め甲斐がありそうだ。

    Zend FWに関しては、みんなどんな風に使ってるのかよくわからん。
    Zend_ToolをベースにしてオレオレFWを作ってるのか、
    オレオレFW用ライブラリ集として活用してるのか、
    Zend_Toolをベースに完全にZend謹製のものをつかってZend準拠なやりかたでZend Wayしてるのか。

    915 = :

    >>914
    独自色というか、FWの仕様と微妙に合わない実装を強いられた時に、
    独自クラスでラップする事はよくあると思うんよ。

    すると
    >むしろビジネスロジック以外で独自色を出そうとするとメンテ性が悪くなり謎の挙動不審に陥りハマりまくる。
    となるわけで・・・ここらへんのうまい落としどころとかテクニックが合ったらいいなぁと思ったのさ。

    916 = :

    View周り以外で、既存のものとすりあわないものっていうと、どういうのがあるだろう

    917 = :

    CakePHPの可読性の悪さにビックリしたよ。

    PEARやZend Frameworkのコードに慣れているからかもしれないが、
    CakePHPを使って、まともなコードのWebアプリは作れない。

    よくあんなのが人気あるのか不思議だ。
    CakePHPには、ソースコードの良し悪しが分からないド素人しか食いつかないんじゃないかなぁ。

    てわけで、俺はZFに一票。

    919 = :

    最初は命名ルールの縛りから逆にチーム開発には有用だしと半分我慢しつつ使ってきたけど
    array地獄でIDEの補助も受けられないし、人間の負担が変に大きすぎる。

    920 = :

    素人なんだけど、arrayはミスがあっても気づかなくてすごく時間を無駄にする。
    けど、一気に設定を流し込む場合にこれ以外の良い方法はあるの?

    921 = :

    >>920
    クラスにするとか。

    922 = :

    別形式で書いて機械的に変換掛ける
    俺俺バリデーターを作って実装前にチェック掛ける
    PHPをやめる

    923 = :

    ZFは自分好みに拡張してなんぼじゃないかな。
    取捨選択しやすくて拡張の土台として都合がいい。
    その分、素体のまま開発始めようとした場合のご利益は少ないと思う。

    あとはソース見てクラス設計の参考に使うのも結構いいかも

    924 = :

    基底クラス郡

    925 = :

    >>917
    可読性が悪い理由は簡単で
    互換性を重視しているからだよ。

    PHP4に対応するために、あえてPHP5の機能を
    使わないで作られている。

    いまどきPHP4なんてと思うかもしれないが、
    CakePHPが人気が出たときはPHP4のサポートは終了しておらず、
    PHP5への移行期だったから人気が出た。
    いまだに古いRHELとかPHP4を搭載したディストリが
    サポート期間中だったりする。

    926 = :

    PHP5の機能を使わなくたって、可読性の良い
    コードは書けると思う。

    927 = :

    フレームワークの良し悪しは好みかもしれんが、
    ZendFrameworkの明確なコード規約は素晴らしいと思う。

    冗長と感じるかもしれないが、IDEとの親和性が抜群に良いのでチーム開発する上では必須。

    931 = :

    改行とかの規約はPEARにも明記されてるし、
    べつにCakeにないからどうという話じゃないと思う
    レイヤーが違うというか

    933 = :

    >>931
    誰もCakeを否定していないし、何故PEARが出てくる。

    935 = :

    >>934
    その4つの規約にも、それぞれメリットデメリットがあるし、規約も含めてのフレームワークだと思うよ。

    個人的には最も枯れているPEAR記法をベースにしたZend規約がベターで、
    PDT(ZendStudio)との親和性も高いと感じたのさ。

    937 = :

    実行時に動的にバインドする系のはヒントが出ないよね

    940 :

    なんでnamespaceが実装された昨今
    Zend風の命名規約にするかなぁ。

    941 = :

    >>970
    5.2を完全に切り捨てるのはまだ早いからかと。

    あと、PHPのnamespaceはお世辞にも使いやすいとは言えない。
    (PEAR&Zend形式から乗り換えるメリットがほっとんど無い)

    まず、

    ・クラスの完全修飾にバックスラッシュが入る
     → 文字列にクラス名入れる時に面倒がおこる

    ・名前解決が無駄に複雑
     → 同ネームスペース内であれば、記述が楽になるかもしれんが、
       大抵の場合は \ で始まる絶対パスで記述する事になる。


    5.3の他の機能は素晴らしいと思うが、
    Zend形式でなく、namespaceを使う明確なメリットを教えて欲しい。

    943 = :

    バックスラッシュはエスケープにも使うからなぁ

    944 = :

    やっぱり型あり言語がいいよ

    946 = :

    普通って何?
    ていうか普通は省略しない。

    949 = :

    まだPHP4対応で書かなきゃいけない可哀想な人なんだ察しろよ


    ←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / php一覧へ
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : - mayaa + 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。

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


    トップメニューへ / →のくす牧場書庫について