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

php覧 / PC版 /

みんなの評価 : ○

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ

/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで

201 = :

>>199
Javaもですが・・

202 = :

Mixinを提供しているRubyだけがCSSと肩を並べているということですね

203 = :

つまり、いや、やめておこう

204 = :

>>185
pythonもメソッド名は、アンダースコアが一般的かな。
クラス名はキャメルケースだけど。

205 = :

最後の文字だけ大文字にする逆キャメルケースにしてる人いる？
geThogEとか

206 = :

>>205
どうでもいいけど、読みづらくね？

207 = :

ゲソォグイーと読んでしまった

208 = :

>>205
まずそうしようと思った意図はなんだｗ
さすがにこれは利点も考え付かんｗｗ

209 = :

難読化とかｗ

210 = :

<?php
class Class_Name
{
public function methodName( )
{
functionName($valOne, $valTwo);
if ($a == 1){
$b = 2;
}
}

命名規則、俺の結論はこのあたり。
http://framework.zend.com/manual/en/coding-standard.naming-conventions.html
http://solarphp.org/manual:project_standards:naming_conventions
Zend, Solarあたり守っとけばPEARの規約でも問題ない。あとクラス名は_で区切っとかないとauto loaderがめんどい。

212 = :

>>210
>あとクラス名は_で区切っとかないとauto loaderがめんどい。
kwsk

213 = :

>>212
>>210じゃ無いけど、ディレクトリ構造を反映ってことじゃない？
Perlのモジュール風？

Zend_Db_Table_Rowクラス => Zend/Db/Table/Row.php

ってな感じじゃないかと想像

215 = :

へー

217 = :

細かい話になってくるが、DBとかPDFとかいう略語の場合、
DBなのかDbなのか、PDFなのかPdfなのか、っていう違いも
あるねｗ

これがまた人によってまちまちだし、同じ人でも場合によって
違う場合がある

219 = :

デザインパターン使うときはデザインパターンも名前に入れてる
例えばSolar_Auth_Adapter_Sql はパッケージ名はSolarで認証クラスをアダプターでSQLクラスで実装してるクラス。
Solar/Auth.php
Solar/Auth/Adapter.php Solar_Auth_Adapterクラスで抽象クラスを定義
Solar/Auth/Adapter/Sql.php Solar_Auth_Adapter_Sql クラスでSolar_Auth_Adapterクラスを実装

220 :

みんな努力してるんだなー。
参考になります＾＾

221 :

>>205
意味不明で面白い。ウケる。

222 = :

>>219
> デザインパターン使うときはデザインパターンも名前に入れてる

それ、使うときもあったり使わないときもあったり、

クラスに単一のパターンしか適用されない場合、
そのパターンの為のクラスの場合には、そういう名前付けられるけど

一つのクラスに複数のパターンが適用される場合困るんだよな。

223 = :

俺様フレームワークをやめようと思って、CakeかSymfonyを導入しようと思うけど
結局どれがいいんだ…

224 = :

逆に俺様フレームワークを公開して
スタンダードにしてやれ

225 = :

結局はちいたんでいいじゃんっていうレスがつく未来が見える

226 = :

ちいたんは、その名前が失敗の理由のひとつである。

227 = :

>>225
結局はちいたんで（ｒｙ

228 = :

>>227
早いわｗ

229 = :

まあ増えすぎたよね
機能追加しすぎで扱いにくいWEBサービスのようだ

230 = :

>>225
まあ徴兵制だろうね。
戦前（に成人した）世代と戦後世代の日本人を見比べれば一目瞭然。

231 = :

なんだ？この妙に右よりの誤爆は

232 = :

PHPプログラマーの方でPHP用フレームワークを使っている方へアンケート！ ※フレームワーク導入を検討中。先輩方は何を使っているのか？好んでいるのか？をアンケート。.. - 人力検索はてな
http://q.hatena.ne.jp/1210442237

Pradoが圧倒的ですねｗ
http://www.pradosoft.com/

235 :

symfonyってページネーション機能はあるんですか？
ネットで検索しても「ajaxでページネーション」はあるんだけど・・・

237 :

>>236
でもそれも機能たいしてなくないか？
CakePHPみたいに同一ページの複数モデルに対応してないでしょ？

っていうか、ページネーションって掲示板ですら絶対に必要になる機能なのに
なんで標準で付けないんだろ

238 = :

>>237
最適化が難しいから。

一度でもページネイションの機能を作ったことがあればわかると思うが、
DBから全データ読み込んでから絞り込むのか、検索条件を考慮したデータを
取得しておいてからそれを絞り込むのか、なんだかんだ。

基本的に、データの「件数」がわからないとページング出来ない。
（それを無視してやるページングもあるが。）

どうせライトユーザ向けには、DBやらと連携したページングを求め
られるんだから、「始めからつけてない」は、ある意味賢明な選択だよ。

・・・↑が不満なら、PEARとか使えばいいじゃん、全く。

239 = 237 :

>>238
いや俺もたいしたやつじゃないけど作ったことあるし、
CakePHPのソースを解析したりしてみたけど、
そんなに難しくはないと思うけどな（だったらそれ使えばいいじゃんと言われるかもしれないが・・・）

＞基本的に、データの「件数」がわからないとページング出来ない。
これは渡せばいいだけ

240 = :

>>239
うん。だから、>>238の二行目
>最適化が難しいから
と、最終行
>・・・↑が不満なら、PEARとか使えばいいじゃん、全く。
が、結論なんだけどなｗ

「フレームワークに標準で付いていない」ってのが問題じゃ無かったのか？

241 = 237 :

>>240
PEARは使いたくない

まあ、付いてないことがはっきり分かったからもういいです

243 = 237 :

まあそれが普通だよな

244 = :

＞基本的に、データの「件数」がわからないとページング出来ない。
CakePHPはよくできてる。
データの件数ってのは、データ用のSQL文のうち条件は同じでselectするものが、
フィールド名の変わりにcount(*)になっただけ。

そこの部分（フィールド名の変わりにcount(*)）への変換を
自動でやってくれるから、データ用のSQLに相当する部分のみを書けばいい。
また、データ用のSQLにlimitを主導で追加する必要もない。これも自動で追加される。

つまり、「データを取ってくるSQL」を書いて「ペジネーション」処理を使うだけで内部的に、
「データを取ってくるSQL」には、自動的にlimitが追加されて発行され
「データを取ってくるSQL」には、自動的に件数を取得するcountに変更される。（当たり前だがこっちにはlimitはつかない）
（もちろんSQL直書きではなくモデルの操作だが）

最適化って話なら、データ件数を取得する関数をオーバーライドできる。（上のやつはデフォルト動作）
こういう目的でオーバーライドされるために存在するメソッドが用意されている。

245 = :

>>244
うーん。それは、例えばファイルベースのデータとかには適用できないよね。
メールボックスを漁るとか、さｗ
無理矢理使おうと思えば、いっぺんDBに放り込む必要がある。

そんな（SQLで全部済む）フレームワークばかりではない、っていう前提に
立てば、ページネイションの機能は汎用的なものにならざるを得ない。

データの件数と一ページ辺りの取得件数から、データ開始位置（番号）と
データ終了位置を取得する、みたいな。
SQLで言えば、OFFSET とそこからの LIMIT を取得するだけ、っていう。

んで、そんなクラスが乱立しても仕方ないので、PEARなりZendなり使えって
結論で多分無問題。
と思うんだけどなぁ
もちろん、>>244みたいな全自動？ページネイションを否定するわけではないけど。