元スレ【PHP】PHPフレームワーク総合スレ15
php覧 / PC版 / みんなの評価 : △
前へ
451 = :
デザイナーもグラフィカルに編集できるものを目指してるんしゃないのか
452 = 447 :
CMSがフレームワークに置き換わる日
http://blogs.itmedia.co.jp/yoshimasa/2011/06/cms-f1f8.html
今の時代、フレームワークを土台にして作るのではなく、
CMSを土台につくったほうがいいんですかね。
フレームワークも便利ですけど
RSS発行とか、フォーム作成とか
自分でプログラム組まないとだめじゃないですか。
フレームワークでは数時間かかるRSS発行処理作成とか
CMSでは数クリックでできるし
処理されたデータを、どう煮るか焼くかは
CMSもフレームワークも変わらないし。
ただ
>>393さん
みたいに、高度な改変となるとCMSは
プログラムの解析が大変という意見もありますし、
何を作るかによってかわってくるんでしょうが
フレームワークに自作関数や、自作ライブラリを相当作りためてでもいないかぎり
ＣＭＳを使ったほうが効率がいいんですかね。
453 = :
プログラミングができない人から見るとそうなのかもね。俺は全く別物だと思うけど。
CMSで事足りるならそれでいいのではないかと。要件を満たすかどうかの問題。
454 = :
フレームワークは高機能で便利な魔法のツール、みたいに思っているのかもしれないけど
それ以上に大事なのは、制限やルールといった枠組みを与えることで、
人それぞれバラバラになりがちな開発の手法や方向性を統一できること。
って誰かえらいひとが言ってたような気がする。
455 = :
表示系はなんとかなるけど、
DBから取り出す条件設定の制御が面倒な事多くね？
クエリ直接書かせろ！みたいな…
456 = :
官公庁はCMSが主流
457 = :
オリジナル要素が高くなければCMSで良いかもね
458 = :
CMSが勝手のいいフレームワークで作られていれば良い
459 = :
WordPressやEC-CUBEがが使いやすいMVCフレームワークで作られてればよかったのに…と何度思ったことか
カスタマイズつらいです…
460 = :
ワープレって、MVCじゃないのか。
MVCじゃなかったらプラグインひとつ作るのも
かなり手間かかりそうなんだが・・・。
461 = :
違うね。共通ファイルは分けてるけど、細かくビュー分けはしていない
EC-CUBEは独自フレームワークだけど、
こちらも複雑すぎてどこがどこにあるかわかりづらい
462 = :
複雑ってのは俗に言うスパゲッティってことだな
463 = :
そうそう。EC-CUBEは色んな開発者が共同で作ってるらしいから
どうしてもスパゲティになるよね
464 = :
EC-CUBEはソースひどいよな。トランザクションとかちゃんとしてなさそうだし、いくらでも穴がありそう。
// これで勘弁してください…
的なコメントが書いてあったりするし。ジョーク系のサイトでよく似たネタ見るけどオープンソースでは初めて見たわ。
465 = :
ソースの具体例は？
466 = :
>>463
＞色んな開発者が共同で作ってるらしいからどうしてもスパゲティになるよね
いや、その理屈はおかしい
467 = :
>>466
おかしくないよ。だって規約が統一してないんだから。
開発者が違うって言っても社内じゃなくて、他社って意味だし。
468 = :
スパゲティの意味をまずわかってください
469 = :
>>467
外部の異なる組織からフリーランスまでさまざまな開発者が
参加して作ってるオープンソースソフトなんて山ほどあるんだが
さすがにそれらのほぼ全てがスパゲティだなんて話は聞かないよ
470 = :
>>469
ほぼ全てのOSSの話しじゃなくて、あくまでEC-CUBEの話しな
471 = :
どうしてもスパゲティになる
を他のソフトにも適用するのはやめたまえ
472 = :
なんで他のOSSが大丈夫で、EC-CUBEだけ
スパゲティになるんだよｗ
473 = :
いやぁ、WordPressのごちゃっぷりは良いレベルよー
474 = :
PHP自体がスパゲティだよ。
標準関数の首尾一貫性の無さはスゴすぎ！
475 = :
>>472
普通、OSSって特定のグループ・会社が作ってないか？
OpenPNEなら手島屋って会社が作ってるし、
phpBBも海外のグループが作ってたはず。
一方、Wordpressは開発者はいるけど
プラグインで拡張していくから開発者も違うし、一貫性がない
476 = :
すべてのOSSを調べてから言えよハゲ
477 = :
OpenPNEもひでえソースだったなあ
478 = :
OpenPNEのカスタマイズは断念したな
479 :
逆に、このフレームワークは美しいソースだったなぁってのはないの？
480 = :
symfony2
ソースの見てくれの代わりに使い勝手が犠牲になったけど。
481 = :
PHP自体が美しくない
482 = :
そもそも「美しさ」の感じ方は個人差によるからな
484 = :
EC-CUBEはあんなソースでそこそこ動いちゃってるのが不思議なくらいだな
管理とかちゃんとなってない会社なんだろうな
スキルの低いエンジニアが会社の床で寝ながら泥沼のようにして作った印象
あのスタイルで書いたコードのデバッグをやりきるには大変な根性が要るはず
485 = :
俺の見立てではわざとやっていると思う。
OpenPNEもそうだけど、わざとソースを複雑にして
有償サポートを狙っている気がする
※あくまで個人の感想です
486 = :
PHPが汚いとえば
文字コードを変換する
mb_convert_encoding の配列版はないかいな思って調べたら
mb_convert_variables という関数を見つけた。
早速使ってみると、ちっとも機能しない。
なんと、
mb_convert_encoding は変換したいソース元を第一引数に入れるけど
mb_convert_variables は 第三引数にいれるという仕様！
そして
mb_convert_encoding は、
$hoge = mb_convert_encoding みたいに再度代入してやらないといけないけど
mb_convert_variables 代入しなくてもよいという仕様！！
そもそも mb_convert_variables というネーミングセンスなんなの?
mb_convert_encoding_array とかにでけんかったの？
487 = :
>>485
実は確かな技術を持った賢い集団で
自分らの開発は綺麗なソースで行い、リリースの際特製コンバータを通すと
あら不思議、ぐちゃぐちゃスパゲティコード＆意味不明コメント入りオープンソースのできあがり
てな感じか
488 = :
一貫性のなさはPHPの悪習
名前の付け方も引数の並べ方もこの上なく下手糞
490 = :
>>487
俺の場合とは異なるかもしれないけど、
外部に公開するソースは難読化してるわ。コメントも削除してるし。
491 = :
PHPの難読化ツールでおすすめのある？
安ければ無料じゃなくてもいいけどなるべく無料で
493 = :
>>487
オープンソースにする意味ないな
494 :
オープンソースです!!って謳うだけでもたらされる効果ってのもありそう。
495 = :
FREE商法の一種だからな
496 = :
頭の中がぐちゃぐちゃなのを晒すだけ
497 = :
オープンソースです！
↓
SEX
こういうわけだな
498 = :
>>486
そこら辺は俺も学習時に感じたなー
PHPの初期に引数の順番や命名規則を統一していなかったら
もうどうしようもないよね。
499 = :
PHPは馬鹿が何も考えずに作った言語だからな
500 = :
どうやらこのスレには天才がたくさんいるらしいから
後世に残る画期的な言語が生まれるのも時間の問題だな
みんなの評価 : △
php一覧へ類似してるかもしれないスレッド
- 【PHP】PHPフレームワーク総合スレ14 (1001) - [97%] - 2010/12/11 10:32
- 【PHP】フレームワークPharonスレ (306) - [75%] - 2022/10/10 20:00
- 【PHP】フレームワークMapleに舌鼓 (470) - [62%] - 2017/12/31 9:31
- 【PHP】フレームワーク Akelos (129) - [59%] - 2019/5/9 7:46
- 2ch有志がPHPフレームワークを作るスレ (81) - [55%] - 2019/5/9 7:46
- 【PHP】Laravel【フレームワーク】 Part.11 (870) - [53%] - 2022/8/28 15:45
- 【PHP】Laravel【フレームワーク】 Part.12 (314) - [53%] - 2023/1/30 18:45
- 【PHP】Laravel【フレームワーク】 Part.10 (446) - [53%] - 2022/6/6 19:30
トップメニューへ / →のくす牧場書庫について