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

【PHP】フレームワー� ..

554:nobodyさん
08/05/15 18:06:50
>>550
返ってくるデータが二次元の表だけって面倒だよね。

たとえばアドレス帳があったとして、電話番号を複数登録できるようにしたい。
まあ、普通は正規化する。んで、それを取得すると

ID, 名前, 電話番号ID, 電話番号
1, 山田, 1, 090-0000-0000
1, 山田, 2, 090-0000-0001
1, 山田, 3, 090-0000-0002
2, 佐藤, 4, 090-0001-0000
2, 佐藤, 5, 090-0001-0001
2, 佐藤, 6, 090-0001-0002

こうなる。階層的に取得できたらどんなに使いやすいか。

555:nobodyさん
08/05/15 18:07:41
()が省略できる言語は
ダサいって流れじゃないのか？ｗ
VBやRubyはダサい。

556:nobodyさん
08/05/15 18:13:49
できるかどうかならできた方が当然良い
関数と変数の区別をはっきりつけたいから使おうとは思わないけど

557:nobodyさん
08/05/15 18:30:45
きっちりルール決めて統一してくれたほうがいい、って意見もあると思うぜ

558:nobodyさん
08/05/15 18:36:25
その辺はコーディング規約でやるべきじゃないの？
いろんな人がいるだろうし

559:nobodyさん
08/05/15 18:37:54
>>554
PDO使えばできる

560:nobodyさん
08/05/15 18:52:47
あれは賛否両論だろ。
引数省略に付随する問題も一緒に抱えるのに
手放しで喜ぶ馬鹿は死んだほうがいい

561:nobodyさん
08/05/15 21:30:45
>>559
できねーよ

562:nobodyさん
08/05/15 21:31:41
>>561
できるーよ

563:nobodyさん
08/05/15 23:37:08
>>554
それがリレーショナルDBだから。
オブジェクトで扱いたいなら、ORMじゃなくって、OODBを使えばいいんだよ。誰も使ってないけど。
もっともその例って、単なる配列のデータ構造を表してるだけで、オブジェクトとは関係ないと思うけど。

564:nobodyさん
08/05/15 23:50:37
>>563
そりゃ、元のレスが
> 連想配列ですべて解決する。
だからだろうね。

RDBの結果なら連想配列で全て表すことができるっていうだけの書き込みに対して、
それが便利なのか？っていうつっこみなんだろうと思った。

>>554が例に挙げてる様なデータなら、多次元の配列で処理する人も多いだろうし
O/Rマッパとはまた違う次元の話の様な気もするｗ

565:nobodyさん
08/05/16 00:41:02
というか、そんな陳腐な工夫を語れるような小さくて整ったデータベースしか扱ってないんだな、おまえら。

566:nobodyさん
08/05/16 00:51:22
PHPですよ？しかも（主に配布されてる）フレームワークのスレ。

そんなに複雑でビジネスロジックとその他もろもろの制約によって
アドホックばりばりのシステムの話なんてするところじゃないじゃ無いか

567:nobodyさん
08/05/16 05:20:25
PHPでビジネスロジックや「そのたもろもろ」の制約を必要とするよーな設計するか？
そういう制約が意味あるのって、DB専門班とぎっちぎちに分業するようなケースだしなあ。
null拒否くらいならデバッグの意味はあると思うけど
PHPみたいな上層で使うモンなら正規形も凝らんでそ
制約意識するくらいなら処理ロジックや自前キャッシュ手法に凝った方が百倍マシ
PHPが生かせるケースじゃない

なんか元コメ辿ると、bindやprepare使えば十分だろ的な思惑も感じるけど

568:nobodyさん
08/05/16 17:52:55
言語で設計が決まるわけじゃない

569:nobodyさん
08/05/16 19:19:07
むずかしいことばのかいせつ

アドホック - Wikipedia
Wikipedia項目ﾘﾝｸ
アドホック（ad hoc)は、「特定の目的のための」「限定目的の」などといった意味のラテン語の語句である。
ヨーロッパ諸語では様々な語句と組み合わせて用いられている。

ad hoc quering アドホック・クエリ
情報科学分野の用語。
アドホック・クエリを使えば、カスタマイズされたクエリを簡単に作成することが可能になる。
通常、データベースの原理やSQL 文を深く理解していなくても、GUIを使って行うことができる環境が提供されている。
ただし、このような方式のクエリが多用されるとデータベースシステム全体のパフォーマンスにも影響が出かねないため、直接に"生"のデータベースを対象とするのではなく、"生"のデータベースを定期的に複製したものを対象にクエリを作成する、というようなことも行われる。
そのような複製は「データウェアハウス」などと呼ばれることもある。

570:nobodyさん
08/05/16 19:20:35
アドホックとは - はてなダイアリー
URLﾘﾝｸ(d.hatena.ne.jp)
アドホックあどほっく
【ad hoc(羅)】取ってつけたようであるさま。
この意味より，「恒久的でない」とか「反復的でない」ような形容に使われる

571:nobodyさん
08/05/16 22:43:59
>>562
どうやって？サンプルコード示して。

572:nobodyさん
08/05/16 22:47:17
マニュアル読めーよ

573:nobodyさん
08/05/16 22:53:58
ま、そーやって逃げるのは分かってたからいいけど

574:nobodyさん
08/05/16 22:59:30
低脳おーつ

575:nobodyさん
08/05/16 23:36:11
お前、ほんと残念なやつだな

576:nobodyさん
08/05/17 00:30:15
しょーもない煽りあいｗｗｗ

577:nobodyさん
08/05/17 00:50:50
反応するおまえもだよｗ

578:nobodyさん
08/05/17 03:55:36
PEAR使う時ってラップしたクラス書く？
そのまま使う？

579:nobodyさん
08/05/17 04:45:21
時と場合によーる

580:nobodyさん
08/05/17 09:38:16
PDOで階層構造表現できるの？まじ？

581:nobodyさん
08/05/17 13:16:01
マジ。ただし、O/Rマッパーが必要

O/Rマッパー最高！！！

という流れですね。わかります。

582:nobodyさん
08/05/17 13:43:24
>>581
それはPDOだけでは不可能で、
PDO無くてもORMがあれば可能という話ではないのか。

583:524
08/05/17 19:36:50
>>549
そうだね。
「ハッシュの配列では扱いにくい」と言ってるってことは、
PDOが連想配列で返すのを不便だと感じているという事だもんね。

俺は>>550と同意見だった。
オブジェクトが返ってくる事自体にまったく利点を感じないのだ。

データベースエンジンの差異を吸収するのはORMの副産物だと思うし、
それをやってくれるORMじゃないライブラリは好きなので、
やっぱり俺は世にあるORMにはあまり意義を感じていないのかも知れない。

バリエーションって何？

584:nobodyさん
08/05/17 21:39:55
>>583
そもそもオブジェクト指向に意義を感じてないんじゃない？

585:nobodyさん
08/05/18 00:27:53
オブジェクト指向で分析→設計→実装するとき、オブジェクト指向プログラミングの形とマッチしますね。
URLﾘﾝｸ(itpro.nikkeibp.co.jp)

モデリングの過程がオブジェクト指向じゃないと、あまり劇的に便利という実感は湧かないかな？

586:nobodyさん
08/05/18 00:44:42
>>583
RailsのARとか使ったことあるの？

587:nobodyさん
08/05/18 02:08:18
公開されたキモゲータウンのフレームワークがPerlで作られててPHP脂肪ｗｗｗ

588:nobodyさん
08/05/18 04:15:22
むしろ歓喜しているように見える

589:nobodyさん
08/05/18 08:26:46
ひさびさに脂肪ネタ来たｗ

590:nobodyさん
08/05/18 18:14:47
CSSもDRYを求められるよな
単にデザインセンスだけでなくプログラマ的な素養が必要
お前らのデザイナはDRYでびゅーちふるなCSSを書けるの？
それともお前らが手直しするの？

591:nobodyさん
08/05/18 22:23:00
なんでそれをこのスレで聞くん？

592:nobodyさん
08/05/18 22:31:44
>>590
因みに俺のところでは手直しも指導も回答も全部俺がやっている。
つうか、エディタを使う作業は、たいがい俺に回ってくる。
一度も書いたことがないASをいきなり書けたら天才呼ばわりされた。
ほとんど使わないエクセルでマクロをいきなり書いたときもそうだった。
冗談じゃない、感心するなら金くれと言いたい。
うぇぶでざいなー（笑）の100倍は貰って当然だろ、本気で。

593:nobodyさん
08/05/19 00:14:19
DBの結果セットをそのままクラスにするなんてJava屋の発想だな。もしくはアカデミックな人の発想だ。実戦的じゃない。
ウェブアプリって、一覧画面なら連想配列の配列、詳細画面なら連想配列でDBから情報を取得して、HTMLという静的な状態に移す、ほとんどはそれで済む話。
複雑なロジックを伴うクラスが必要な場合だけクラスにすればいい。そういうクラスはDBからだけで構成されるわけじゃない。ORMからさらにDAOと2重にラップする必要はない。

594:nobodyさん
08/05/19 22:23:22
まあぶっちゃけJavaには連想配列はないから、どうやったってオブジェクトにはなるんだけどな
それをモデルとして便利にする方向はある意味自然か

595:nobodyさん
08/05/20 17:15:34
Zendが身売り準備開始してPHPリアルに脂肪ｗ

596:nobodyさん
08/05/20 17:39:18
これか、
URLﾘﾝｸ(jp.techcrunch.com)

PHPそのものはともかく、ZendFrameworkとかは影響うけるかもね。

597:nobodyさん
08/05/20 17:46:06
買収先「ZendFrameworkぅ？なんだこの糞FWは！？捨てろ！

ってなるに500ペリカ
ZFなんかを使っていた先見の明ない奴ら涙目ｗｗｗ

598:nobodyさん
08/05/21 11:31:16
もしPHPが有料の製品になったらどうする？
俺は捨てるｗｗｗ

599:nobodyさん
08/05/21 15:22:14
なるわけねえだろ。さすがに。

600:nobodyさん
08/05/21 15:48:10
Microsoftが買収したら、なにやらワケが判らぬフレームワークが前提になって、
そのフレームワークの機能はIISでしか動かないみたいなのはあるかもよ。

あぁ、想像しただけで嫌だ。

601:nobodyさん
08/05/21 22:30:45
MSにはASP.NETという洗練されたフレームワーク、VisualStudioという高機能なIDEがある。ガキのおもちゃのようなPHPと一緒にするな。

602:nobodyさん
08/05/21 23:44:23
ASP.NETってどこで使われてるの？
GoogleとかYahooとかAmazonとか楽天とかMixi見たいな大手で。
もちろんMicrosoftのサイトは除いて。

直感だけど、MSのフレームワークが前提になったらPHPは確実に死ぬと思う。

603:nobodyさん
08/05/22 00:36:44
>ASP.NETってどこで使われてるの？
うちJavaに次いで.net/レガシーASP案件が多いよ
でもASPはイントラ用途での案件ばっかりだな
IISに.netにMSSQLにPowerShellにVSSと、MSモノで固めた場合は
けっこういい環境だと思うんだけどねー。
MSモノだけやる訳じゃないせいか、誰もVisual Studio使ってないけどw

つまり、MSモノで固められるケースが限られるのが問題なんだろう。
レン鯖とかでも（Javaともども）機能制限しにくい故にユーザに提供しにくいしな。
その隙間をPHP需要が埋めているんじゃないかい。

604:nobodyさん
08/05/22 01:06:04
ASP.NET → PHP.NET

まさかのM$大逆転

605:nobodyさん
08/05/22 01:06:57
>>603
結局さ、ASP.NETが良いのってSIerにとってでしかないと思うんよ。
小さく使われる、汎用性がないプログラムとしてと言うか。

そういう前提がなければ PHPなりPythonの方が有用だから、大手のサイトでは
ＰＨＰやPythonなんかが使われてるじゃかなろうかと思ってる。

仮にＭＳに買収されたら、PHPはPHPらしさを残せるかのかなぁ。かなり不安。

606:nobodyさん
08/05/22 01:11:58
VisualBasicの後継はVisualPHPで

607:nobodyさん
08/05/22 01:22:14
どうVisual・・

っていうかDreamWeaverとかじゃねえのそれ

608:nobodyさん
08/05/22 13:40:13
ASP.NETくらい作りこまれたフレームワークはない。コミュニティベースのフレームワークとは出来が違う。VisualStudioもそうだけど。
ただ、イントラ以外の、一般のウェブサイトの場合、結局凝ったデザインを実現するための泥臭い部分に多くの労力を割かれるので、ASP.NETのメリットは薄れる。
後は、LAMPみたいに全部無料ではないので、中小規模の場合、LAMPを選択することが増えるだろうな。

609:nobodyさん
08/05/22 15:06:08
実際、WEBアプリ業界って言ったら、Windowsサーバに抵抗感があるというか触ったことのない
会社・技術者も多いんだけどね。特にCGI等の設置運用あたりからぽこぽこ出来た会社はｗ

610:nobodyさん
08/05/22 15:43:18
泥臭い部分で真価を発揮できない作りこまれたFWとかｗ
そういう仕事を片付けるためのFWじゃねーのかよ

コミュニティベースかそうじゃないかで
出来が云々とかいかにもMSのバカ顧客らしい発想だ
その作りこまれたFWとやらで死ぬまで
綺麗で泥のないアプリを作りつづけてろ

611:nobodyさん
08/05/22 16:11:39
>>608
想像だけど、確実にMS　は　Yahoo みたいな超大規模なところには、ほとんど無料で使えるような
営業をかけてると思う。仮に　Yahooのサイトが ASP.NETで運用されれば、広告効果大きいし。

だから、ASP.NETが PHPとかPythonより大規模なサイト構築に向いていれば、使ってないはずがない。

パフォーマンスの問題か、セキュリティに対する透明性の問題か、生産性の問題化は判らんが、
大規模なサイトにおいては ASP.NETは　PHPとかPython以下という評価がされているだけだと思う。

中規模なところには普通にしか販売しないだろうから、ASP.NETはイントラみたいな小規模なところでしか
使われない気がする。SIerとしては、そっちのほうがマーケットが広いだろうから、そんなに悪い話でもないけど。

612:nobodyさん
08/05/22 17:50:15
MS製品はしょっちゅうトロイとか埋め込まれてる印象

613:nobodyさん
08/05/22 23:15:21
いや、大企業ほどIISの比率が高いから。金がかけられるところはJavaやASPが多い。
Apacheが強いのは予算のないところとか、２ちゃんみたいにひたすらウェブサーバの数を増やしたい大規模なサイト。

614:nobodyさん
08/05/22 23:18:13
補足しておくけど、大規模なサイトと予算の大きなサイトは別物だから。

615:nobodyさん
08/05/23 00:01:10
でも結局ネットでビジネスやってるようなシステム運用に詳しくて、大規模なトラフックがあるところは
あんまりASP.NETを使用してないんでしょ？やっぱ本質的な問題があるんじゃないの。

事例見ても、イマイチぱっとしないし。
URLﾘﾝｸ(www.microsoft.com)

616:nobodyさん
08/05/23 00:55:23
実際MSを全面的に信用してる奴は少ないと思うよ。
本質的な問題、とやらがあるのかどうかは判らんけど、
「ソースが公開されてていざとなれば力技が効く」世界とは180度方向性が違うからねえ。

その事例のリード文で処理規模謳ってるのはセガダイレクトくらいか
「.aspx」で終わるURLぐぐるといろいろ出て来るけど、大規模サービスって感じのはないなー。
リネ2のwebとかJR東の運行情報とかパンヤのwebとか地図閲覧サービスとか
まあそれなりに規模あって安定性が望まれるサービスも垣間見れるね。

致命的な弱点があるようには見えないな
オープンソースじゃない事、ってのは一つの理由になると思う。

617:nobodyさん
08/05/23 01:25:55
htmlエスケープどういう方針でしてる？
俺は文字列と、文字列が入った配列を再帰的にエスケープして、
オブジェクトはそのままviewに渡してるけど

618:nobodyさん
08/05/23 06:55:54
>>617
本質的にはhtmlを生成するときにその場でコンテキストにあわせてエスケープするのが適当だよ。
htmlに入れ込むといってもテキスト要素として入れ込む場合と属性値としてクオートの中に入れるばあいなんかに分かれるから。

619:nobodyさん
08/05/23 10:28:17
日本はApacheのシェアが高い。
日本は今でもApacheしか対応してないレンタルサーバ屋が多いけど、アメリカは昔からレンタルサーバ屋がIISとApache両方対応してた。
Fortune1000を対象にしたシェア調査が少し前に話題になったけど、大企業のコーポレートサイトなど、予算のかけられるところはJavaやASPが強い。
PHPで名もないウェブサイトしか作ってないと、そういう実感はないだろうけど。

620:nobodyさん
08/05/23 10:29:53
ApacheやLinuxのカーネルハックできる人材なんて、その辺のウェブ屋にはまずいないから。オープンソースか否かなんて関係ない。

621:nobodyさん
08/05/23 10:52:28
誰もWebServerとしてIISが劣るとは言ってないんだが、何を言ってるんだろ。
それにしても2回に分けて書くのは芸風か。

622:nobodyさん
08/05/23 13:01:37
>PHPで名もないウェブサイトしか作ってないと、そういう実感はないだろうけど。
↑俺のことですねｗ

Webアプリは、PHPとJavaしか使ってない★
ASP.NETじゃないと実現できない機能は今のところ無し(・∀・)
どうしてもASP.NETじゃないと無理なら手を出しますが、他の実現方法を探すかな？
…というかMS製品しか使っていない客には当たったことないです（ラッキー！？）

623:nobodyさん
08/05/23 13:04:32
大手のSIerではPHPを使う案件はやってないんですか？
大手＝PHPを使わない企業という定義でOKですか？
そんなわけねーだろｗｗｗｗｗｗ

624:nobodyさん
08/05/23 13:14:15
PHP→名もないウェブサイト→人生負組みのツールでもいいじゃん
自分が便利だと思ったら使えばいい

他人の判断、他人の価値観を気にして、他人に認められたいと思う演技を続ける人生は、勝ち組じゃない
奴隷じゃないなら、最後は自分の判断で決めろ

…俺はRuby、Pythonの準備をしときますｗ

625:nobodyさん
08/05/23 13:28:14
>>623
Javaなんかだと顧客側が動作環境を WebsphereとかWeblogicに限定してるところ
は多いでしょ。SI案件だとフリーの環境は一切使いたくないってのは普通だし、
そういう客のほうがカネ払いもいいだろうし。

ただ、そういうのは技術的な判断じゃないから、これをもって技術的にも良いはずって
言うのは愚かしいと思う。

626:nobodyさん
08/05/23 17:03:53
>>618
よくいるよな、おまえみたいな無知ｗ
属性値はいわばRCDATAなのでHTMLエスケープに関してはPCDATAと全く違いなし。
現在のほぼ100%のUAが、属性値もエスケープされていることを見込んでパースしている。

627:nobodyさん
08/05/23 21:22:09
>>626
618じゃないけど
RCDATA、PCDATAという用語は初めて知った。
参考になったよ、ありがとう

データ形式一覧
URLﾘﾝｸ(bakera.jp)

#PCDATA (構文解析対象文字データ) の解説
URLﾘﾝｸ(bakera.jp)
PCDATA は Parsed Character Data の略で、「構文解析対象文字データ」です。

RCDATA (置換可能文字データ) の解説
URLﾘﾝｸ(bakera.jp)
Replaceable Character Data、「置換可能文字データ」です。

628:nobodyさん
08/05/24 00:03:21
>>626
じゃあ、その上で、
どの時点でどのような処理をしてエスケープすればよいかを具体的に教えて。

629:nobodyさん
08/05/24 22:02:37
>>626
RCDATA言いたかっただけなんですね、
ええ、わかります。

630:nobodyさん
08/05/24 22:37:13
まるごと Ruby! 発売でPHP斜陽の感ありありｗｗｗ

631:nobodyさん
08/05/25 11:29:57
YahooとMicrosoftの仲人はPHP？

PHP on IIS - MicrosoftがPHPをフルサポート
URLﾘﾝｸ(www.microsoft.com)

【Special Seminar】 PHP on IIS - あなたの可能性を広げる、Windows 環境へ -
URLﾘﾝｸ(msevents.microsoft.com)

632:nobodyさん
08/05/25 13:35:47
P++

633:nobodyさん
08/05/25 16:38:21
>>626
javascriptのエスケープはコンテキストによって、
ブラウザによって必要とされるものは違うでしょ。

「HTMLエスケープ」っていう言葉が悪い気はするけど。

634:nobodyさん
08/05/25 22:06:40
>>633
どう違うの

635:nobodyさん
08/05/26 04:04:46
>>633
遠回しに言ってんじゃねーぞハゲ
HTMLエスケープはHTMLエスケープであって
それ以上でも以下でもない

636:nobodyさん
08/05/26 09:16:56
>>634
>>635
URLﾘﾝｸ(www.google.co.jp)

637:nobodyさん
08/05/26 09:25:06
テンプレートでデフォルトでhtmlspecialcharsされるようにしてる。
ユーザ入力でタグの中に何かを出力する場合(ほとんど無いけど)は、
ホワイトリスト方式。

638:nobodyさん
08/05/27 23:55:46
フレームワークのせいで後々のメンテの度に長時間取られる。
PHPなんて、なーんも考えずに工夫せずにコピペ最強でサクっと済ませられる「フレームワーク」なんだがな。

639:nobodyさん
08/05/28 01:02:34
規模によるって
話を単純化し過ぎ

640:nobodyさん
08/05/28 01:55:54
そうだよなぁ。
規模がでかいと、謎エラーの出所が分かんない場合あるよね。
何回も呼んでるフレームワークの関数で、止まる時とかさ。

大概人的ミスだから、CVSとかで誰がやったか、すぐにばれるんだがな。
そんな時はブーブー文句垂れるおｗ

641:nobodyさん
08/06/06 02:37:05
FW使うとメモリ喰うから
apacheのプロセス数が増えるとメモリが圧迫されてmemcacheが消えるね
一台の鯖で稼働できるプロセス数かなり減らね？

642:nobodyさん
08/06/06 07:32:19
一番メモリ食わない言語って何？
やっぱPerl?

643:nobodyさん
08/06/06 08:14:24
アセンブラ

644:nobodyさん
08/06/06 08:18:17
今時アセンブラでウェブアプリ書いてる奴いるわけねーだろ
はてなもPerlだし、やっぱPerlなのかな？

645:nobodyさん
08/06/06 08:56:45
軽いと言われるciですら、現在メモリ700KB
1リクエスト毎にドラクエ4の全容量以上のメモリを食うって一体…

646:nobodyさん
08/06/06 08:57:39
perlも良いフレームワークがあればもっと流行るんじゃない？
まぁ、続きは向こうで。

【Perlフレームワーク】Catalystを語る人
ｽﾚﾘﾝｸ(php板)

647:nobodyさん
08/06/07 08:06:42
PHPの場合、ウェブフレームワークがすべてのモジュールを内蔵していて、外部に独立してるのはせいぜいSmartyくらいだけど、
Perlの場合、Catalyst含めて、独立したモジュールが集合して構成されるので、PHPのようなウェブフレームワークとは意味が違ってくる。

648:nobodyさん
08/06/07 12:29:05
Perlでライブラリとして提供されてるものが
PHPでは関数やエクステンションで提供されてるだけの話で
本質的にはたいして変わりなくね？

649:nobodyさん
08/06/07 19:46:49
PHPはテンプレートエンジンもORMも、フレームワークごとにバラバラだから。

650:nobodyさん
08/06/07 21:25:56
なんでSmartyもしくはFlexyを敬遠するのかな、とは思ったことがある。
大体だれかが野良クラスで対応するじゃない。
パフォーマンスにしたって、それ以外の部分でがっつり重いFWも結構あるし。

もうViewクラスを作るのはほぼ共通なんだから、Zendがなんか作ってくれ
ないかな。if と foreach と変数展開（オブジェクトのメソッド呼び出し含む）と、
スクリプトでregisterしたヘルパメソッドのみが使えるとかいう感じで。

PDOみたいに組み込みクラスで速ければ、とりあえず俺は多分それを使う

651:nobodyさん
08/06/08 13:31:14 oe9fgjbi
そこでPECLですよ

652:nobodyさん
08/06/08 23:13:03
一番速いテンプレートエンジン - Blitz - Do You PHP はてな
URLﾘﾝｸ(d.hatena.ne.jp)

653:nobodyさん
08/06/09 02:02:29
一番速いテンプレートエンジンはPHPそのものに決まってるだろ。

654:nobodyさん
08/06/09 13:52:03
PHPそのものだと、構文がテンプレートっぽくない。

BlitzはPHP拡張として作られているから、PHPそのものといえる。
SmartyもPHPそのものに変換されるから、PHPそのものといえる。

655:nobodyさん
08/06/09 14:03:38
ところでPieceFrameworkはフロー定義を書き換えるたびにクッキー消さなきゃならんというガッカリな仕様は直ったのかな？

656:nobodyさん
08/06/09 14:28:34
テンプレートエンジン派ってデザイナにテンプレート書かせてるんだよな？
それ以外にテンプレートエンジン使ってる奴がいたとしたら救いようがないうつけ者だな

657:nobodyさん
08/06/09 17:37:34
>SmartyもPHPそのものに変換されるから、PHPそのものといえる。
これは違うだろ。うぇぶでざいなあが作る段階でPHPじゃないのだから。

658:nobodyさん
08/06/10 00:15:51 00QPcxQH
>>656
WEBデザイナー兼WEBプログラマーな私はSmartyを使っておりました。
最近はテンプレートは生PHPで充分ということに気付き、原点回帰しました！

659:nobodyさん
08/06/10 05:28:42
よく知らんのだが、「PHPそのもの」って言ってるやつのFWでも、それはあくまで記法だけで、
スコープを確保するためにファイルを読み込んでeval()してそうな気もするんだが、違うのかな。

それとも、グローバルにオブジェクト（や関数）を置いて、それを参照するのを前提にrequireなの？

660:nobodyさん
08/06/10 09:31:44
requireすると、呼び出し場所のローカルスコープで
実行されるので、別にeval()する必要は無かろう。

っていうか、そんなPHPフレームワークあるの?
RoRはerbでevalしてるが。

661:nobodyさん
08/06/10 11:18:10
ZF勉強していて思った。
MVCはいいけど、そのためにいろんな「専用の」クラスの使い方
を覚えなければいけないし、覚えてもZFのみってことは、
別のFWに変更するときや、ZF自体が消滅（ありえない？）するときには、
その資産がチャラになっちまうんじゃないの？
大規模開発に向いている、プログラミングの標準化ができるってのが
ウリだと思うけど、FW乗り換えなんかを考えるとデメリットも大きいよな。
そんなんだったら、自分のシステムに必要なクラスを自分で作って
充実させていったほうがいいのかな．．．．とも思う。
まあ、その維持管理が大変といえば大変だが、資産が消滅することや
方針変更で別のものに作り変えるときでも、ノウハウが残るから、
長期的なスパンでみるとメリットがあるんじゃないのかなあ。

特にシステム開発環境を選択している人、そういう問題点ってどう考えている？

662:nobodyさん
08/06/10 12:12:38
>>661
俺俺FWは、俺しか使えない。
他人が使うと、学習コストがかかる。
ましてや、俺と仕事するときにしか使えない。

その点、ZF等のFWは既に学んでいる人々がいる。
その人たちと共同で仕事ができる。

独りでできるもんっ♪なら俺俺でFA
既に学習した人たちのTips等を利用したり、
共同で作業したいなら、
既存のFWでいいんじゃね？

663:nobodyさん
08/06/10 12:15:11
ZFが無くなったときの心配は、ZFが無くなってからすればいいんじゃないか?
大体、オープンソースなんだからZF自体が消えてもコード資産はまるまる残るだろう。

まぁノウハウって奴を蓄積したいのならべつにどうぞ

664:nobodyさん
08/06/10 12:27:28
俺俺ラッパー書いてそこからZFなり呼び出すようにしたら
ZFが死んでもなんとかなるじゃん

665:661
08/06/10 13:05:21
>>662
確かに俺俺FWは俺しか使えないけど、共通処理をクラス化したときに、
その内容を整理して文書にすればいいんじゃないのかな。
それ以外は素PHPでいいわけだから、ZFのようにいろいろな制約が
無い分だけPHPを使える人は多いし、知らない人もちょいと学習すれば
使えるようになる。

>>663
ZFが消滅してもオープンソースだから残るだろう。
でもセキュリティホールや新しい技術は一切入ってこないよねえ。

>>664
ラッパーという手はあるが、実際簡単にいく？

666:nobodyさん
08/06/10 13:13:11
>>665
なんかもう>>661の中で結論決まってる予感。

667:nobodyさん
08/06/10 13:17:29
> でもセキュリティホールや新しい技術は一切入ってこないよねえ。
だからさ、その心配はZFが無くなってからすればいいってこと。
そんなもん心配していまから俺フレームワーク作るわっていうのなら、
セキュリホールだのなんだのはどっちみち全部自分で面倒みるんだろう?

668:nobodyさん
08/06/10 14:27:18
> 確かに俺俺FWは俺しか使えないけど、共通処理をクラス化したときに、
> その内容を整理して文書にすればいいんじゃないのかな。

その文章を読まないといけないだろ？
初めて会った人が、あんたが書いたオレオレ文書を
すでに読んでいるなんてことはまずありえない。

その点ZFなら読んでいることはありえる。

> それ以外は素PHPでいいわけだから、ZFのようにいろいろな制約が
オレオレFWの制約を受けるだろう。

何の制約もないフレームワークがあったとしたら、それは
フレームワークじゃなくて、ただのライブラリだ。

> 知らない人もちょいと学習すれば使えるようになる。
使えるということと、開発の早さ・楽さは別の話。

> でもセキュリティホールや新しい技術は一切入ってこないよねえ。
オレオレFWは、すでにセキュリティホールや新しい技術は一切入ってこないよねえ。

669:nobodyさん
08/06/10 14:50:32
FW乗り換えたら全てチャラっていう前提がおかしな話
WEBアプリのFW全般に対するノウハウってのもあるし
現に今のFWはほとんどMVCベースなわけで
基本的なコンセプトが大きく変わるわけじゃない

個人的なFWを作って使うのも別に悪くはないと思うけど、
オープンソースで開発されているFWが
どれだけレビューされてテストされた上で
リリースされているかよく考えてみるべき

乗り換えたら全部チャラだし俺俺FWの方がいい、
と安易に考える奴は自惚れてるとしか思えない

FWが変わったら覚えた事が全て無駄になる、ってのは
結局表面的な部分でしかFWを扱えてないわけで
FWに「使われている」プログラマでしかないよ

670:nobodyさん
08/06/10 15:11:29
いきなり俺俺は無謀だな
一回メジャーなFW使ってみてから手を出すならともかく

671:nobodyさん
08/06/10 16:42:19
オレオレFWを公開して普及させようと言うならともかく、自分に必要な仕組みだけ
自分で作るのが、そんなに悪い選択とは思わないけど。

672:nobodyさん
08/06/10 17:28:40
単純にZF死んだら困るから自分で作るよ!っていう理由に納得できないだけだろう。

673:661
08/06/10 17:29:20
>>669

FW乗り換えでも、MVCの考え方やノウハウは残るが、
現実的にアプリはすべて書き換え。
数十本ならそうでもないが、1000本単位なら相当な手間。
「FWに使われているプログラマ」はいいけど、現実的に手間を
掛けられないというところをわかってないのは問題。
同じFWに縛られ続けていくのはいいが、消滅しちゃったとき
どうやって資産をメンテしていくのか。
そういう意味でチャラって書いた。

だから　>>665　が書いたようにオープンソースであること
を考えると、そういった問題が解決できそうだ。
また多くの人が使ってこなれている面はメリットだよな。

それで、実際どれだけのモンがFWで構築されてんだろ。
cakePHPなんかも有名だが、ZFが出て乗り換えを考える
人もいるだろうし、どうするんだろ。

674:nobodyさん
08/06/10 17:32:43
zfに乗り換える人なんていないでしょ
ショボfwじゃん

675:nobodyさん
08/06/10 17:35:53
どうやって資産をメンテしていくっていうか、
それは普通にソースツリーをフォークしてメンテするだけだろう?

自分でゼロから作るよりは随分と楽だと思うが。

676:nobodyさん
08/06/10 19:10:47
>>673
採用しているFWが変わったからって
既に出来上がってるアプリをそのFWに
全て書き換えるケースなんてそうそう無いだろ
完全な自社コンテンツでアクティブなものか
コンテンツ自体を総リニューアル時に合わせて移行、くらいなもんで
元から運用してるものは普通そのままメンテだろ？
千本単位とかそれこそ非現実的じゃないか？

677:nobodyさん
08/06/10 19:46:40
たとえばsymfony作られたサイト
世界全体でも1000もないだろｗ

678:nobodyさん
08/06/10 21:11:39
とりあえずDISる
↓
少し釣れる
↓
ツンデレ教えて君

こうするとggrksと言われないんですねわかります

679:nobodyさん
08/06/10 21:26:00
数字おおげさに言い過ぎる
↓
突っ込まれる
↓
雲隠れですねわかります

680:661
08/06/11 09:37:45
>>676
なるほど、すべて書き換えないケースもあるな．．．．
しかし、千本単位が非現実的なら、「大規模開発」って
謳っているのはどのくらいの規模なんだろうか。

>>677が書いたように、事実上PHPのFWはまだまだ
浸透していない、PHPでの開発は結局小規模なもののみ
ってことなんかな。

681:nobodyさん
08/06/11 09:58:12
>>680
大規模開発って、ふつうプロジェクト数のことじゃなくて、
ユーザ数とか、高信頼性を確保するために大きいシステムを組むってことだろう?

そんなものは、当然一件ごとに何年もかかることがままあるから、
大規模なプロジェクトを千なんてオーダーで抱えてるとこなんてありえないよ。

ていうか、自分が抱えてもいない数のプロジェクトの事と、
(まだつぶれていない)ZFが潰れることを心配して
自分で作った方がいいと思ったの???

682:nobodyさん
08/06/11 23:15:02
どれもこれも、今となっては、PHP4で書き続ける理由に説得力が伴っていないわな。
もうとっくに殆どの環境はPHP5に移行している。
lib/php内やフレームワークのコードだけがPHP4。
自分で書く時、例えば、varなんて使う機会が無い。
そのせいで、細かく曖昧さを指摘する目に見えないエラーがリクエスト毎に何10何100と出ている。

683:nobodyさん
08/06/11 23:37:36
>>681

>>661 ではないけど、大規模開発って言ったら、コード量をイメージするなぁ。
大規模サイトだと、ユーザ数が多いって意味なのかなぁって感じもするけど。

外部のフレームワークの適用については、例えばバグとかセキュリティホールが
あるからバージョンアップしてくださいって言われても、影響範囲が読めないと
二の足踏むし、かといってそのままってのも気持ち悪いし、自作しても知れてる
程度の使い方しかしないのなら、使いたくないってのは良く分かる。

684:nobodyさん
08/06/12 00:08:14
S2Container.PHP5 を勉強しようとセットアップのページ読んでるんですが、解りづらくないですか？
一番初めに書いてあるS2Container.version.tgzを落としてきたら拡張子が.tgになってるし、
＞S2Container.php と S2ContainerSplAutoLoad.php を require して下さい
って何のファイルに書けばいいのか書いてないし・・・。

685:nobodyさん
08/06/12 00:18:48
>>684
pear installコマンドって、ダウンロードした後、勝手にセットアップまでしてくれんじゃないの？

で、PEARのディレクトリってPHP5を入れた時点でパス通ってて、
ソレを、これから加工と思ってる空のPHPにrequire_onceで例に書いてあるとおりに書けばいいんじゃないの？

違うの？

686:nobodyさん
08/06/12 04:04:39
>>685
個人的に、pearコマンドを使わないインストール方法をきちんと書いてくれないFWは信用できない。
S2Containerは触ったこと無いけど。

最初からPEAR必須ライブラリも把握できるし、必要最低限の設定等がわかっていれば、環境を
変えるときも対処しやすいと思う

687:681
08/06/12 12:13:00
>>683
つまり、アップデートのパッチを調べる労力 > 自分で書く+メンテする労力
ならば自分で書いてもいいってことね。で、コード量が少ないなら
書くのもメンテするのもたいした労力はいらないからそれもあり、と。
まぁそういう理由なら納得できる。

個人的にはFWを導入した時点で自分で書く+メンテしてもいいと思える
コード量を越える気がするけど、そこはまぁヒトそれぞれ。

大規模開発ってやつについては、言うとおりコード量もあると思う。
なんていうか、大規模開発っていうのはプロジェクト一件あたりの
必要な金、期間や人力がデカいっていうことで。

688:nobodyさん
08/06/12 13:50:39 5LtH7vFx
JavaもどきのFW使うなら、素直にJava使えばいいと思う
Seaserは簡易版のTeedaに期待

689:nobodyさん
08/06/12 23:10:10
Webのページ上でボタン押したり、何かした時の処理は、
全部 Ajax 経由でいいと思う。
何かする度に、フォームの全ての値がサーバに送られて
画面全体がリロードされるのって変すぎる。
で、Ajaxと一体になってるフレームワークって何かありませんか？

690:nobodyさん
08/06/12 23:17:19
>>689
極端な意見ｷﾀｰ
っていうかそれならもうMS製品で作っちゃえよ・・・
その方向で少し間違えると、キーを押したりマウスを動かしたりするたびにリクエストの発生する
糞サイトになるぞｗ

で、そんなFWはこれから大流行するだろうから、しばらくのんびり待ってたら？AIRとかもあるしね

691:689
08/06/12 23:58:39
>>690
作ってて違和感あるんだよね。なんだかばかばかしい。
.NETって言われるだろうなと思ったけど、MSに閉じた技術ってのがね。

Ajaxから戻ってきたデータによって、JavaScriptで画面上の
変化部分を更新するとか、ある程度自動でできる仕組みがあると嬉しい。
更新したデータは、セッション変数で保持してればいい。
かと言って、ブラウザにプラグインが必要になるような技術もいやだな。
今のWebと親和性をなるべく保ちながら、より自然な開発がしたい。
もうちょっと真剣に探してみるかな。

692:nobodyさん
08/06/13 00:15:02
>>690
>AIRとかもあるしね
あれは勧めちゃいかんわさ。MSの.net以上の勘違い製品。

どうしてもその手の処理が必要な時は
「ユーザに断ってから」Applet立ち上げれば今時でさえ通じるもんだ
他不要

693:nobodyさん
08/06/13 00:25:04
>>691が感じている違和感がどの辺にあるのかよくわからないけど
サーバサイドはPHPで、クライアントはJavaScriptなりFlash(ActionScript)なりっていうのが
面倒ってこと？

>>691で書いているくらいやりたいことが決まっていれば、例えばW3CとECMAScript標準に
完全準拠の理想フレームワークなら、作ろうと思えば作れるかもね

どのみちデザインのためにHTMLで小細工しなくちゃいけないなら、それがやりにくい様なフォー
ムデータの扱いを強要するFWは結局流行らないだろうと思う
Ajaxを含むJavaScriptやFlashの技術は、まさにクライアント依存の妥協案というか手法というか、
っていう部分なんだから、それをサーバ側の組み方と違うと言って敬遠していては現状何も作れ
ない、とみんなそう思ってるんじゃないかなあ

だから、俺は今日もしこしこ正しいかどうか解らないJavaScriptを書きますよ、と。

694:691
08/06/13 01:22:41
>>693
違和感ってのは、>>689に書いた内容です。
画面の一部を変更したい時でも、画面全体に影響があるので、
プログラムがそれを考慮した構造になり、分かりにくいものになってしまいます。
GETとPOSTを分けたりすると、更に分かりにくくなります。
WindowsのGUIプログラミングのような開発ができたらいいなと。
イベントドリブンで感じで。
サーバサイド言語 + JavaScript (Ajax含む) でそういう仕組み
になってるフレームワークがないかなと思ったんですよね。
今の自分の作り方が悪いだけかもしれませんが。

695:nobodyさん
08/06/13 02:12:02
>>694
イベントドリブンって言葉だけに反応すると、
PRADOとか、PHPのフレームワークはイベントドリブンらしいよ。

後、Ajaxだと、AjaxCoreとかってフレームワークがあるみたいだけど、ここら辺組み合わせたらなんかできるのかな。

696:nobodyさん
08/06/13 02:15:42
まあ、HTTPやHTMLはビジネスアプリケーションを実装するために考えられたものじゃないからな。
Windowsフォームのアプリケーションと同じことをウェブに求めるのは無理がある。
凝ったウェブデザイン（というか、普通のエンドユーザ向けウェブサイトで求められるデザイン）を、DOMによるCSSの操作だけでデザイン対応するのは相当無理がある。
そこまで機能性を求められるアプリなら、.ウェブアプリじゃなくてNETのアプリにするのが妥当と思うし、マルチプラットフォームにしたいならJavaでも使えばいいと思う。

697:nobodyさん
08/06/13 20:10:11
>>696
だが不可能ではない。
そして確実に流れはそちらに向かっている。

698:nobodyさん
08/06/13 23:34:10
向かってねー与。

699:nobodyさん
08/06/13 23:43:31
googleやadobeの動向も知らないのか？

700:nobodyさん
08/06/14 00:22:27
PhotoShopがFirefoxのプラグ印になるといいね。

701:nobodyさん
08/06/14 00:27:33
>>699
kwsk

運用上でも昨今のAjaxライブラリの伏魔殿具合見ても、
けっこ前に壁にぶちあたったきり進歩がないしな。
javascript1.7以上が普及してくれれば、スコープ汚しまくりで
setTimeout地獄な糞Ajaxの現状を打破できるのかもしれないが。

air入れてる奴もsilverlight入れてる奴も見ないしな

Ajaxは割り切って使うに限る。
GoogleはFlashも使ってる。必要に応じて適用してるだけじゃないのかね

702:nobodyさん
08/06/15 14:13:27
muninのグラフ見てたらiowaitで埋まってる時間があるんだけど原因がわからんちん
mysqlのスロークエリみたいに
処理速度が遅ければログ取る機構とか付けてる？
てかそんなのフレームワークの標準機能で付けとけよ

703:nobodyさん
08/06/16 12:59:18
HD壊れかけ？

704:nobodyさん
08/06/18 02:05:34 ZYTHmHR0
データが飛んで初めて分かる、バックアップの重要性＞＜

705:nobodyさん
08/06/19 21:58:18
バックアップ？ああ、そういやPHPやってる雑魚どもはSVN使わんな。どいつもこいつもWindowsでeclipseを使いつつ、subclipseを入れてないｗ

706:nobodyさん
08/06/19 22:29:31
何この頭の悪そうな書き込み

707:nobodyさん
08/06/20 00:37:33
お手軽にCVS使って、時々圧縮・暗号化したのをYahooブリーフケースにおいてる。

708:nobodyさん
08/06/20 00:41:52
svnって開発時には使うけど稼働時に使うか？

709:nobodyさん
08/06/20 01:08:36
>>708
稼動時でもバグが見つかれば更新しないといけないから
稼働環境でもマージ作業せなあかんやろ

710:nobodyさん
08/06/20 02:15:40
何この頭悪そうな話題のずれて行き方

711:nobodyさん
08/06/20 12:38:43
PRADOわかる人いる？

712:nobodyさん
08/06/23 10:47:52 isKyS0yI
以前、使ってみた（というか実験してみた）ことある。

以下、個人の感想だが、設計は面白いが、web用のフレームワークとして間違った方向に行ってる気がしたので、実践では使ってない。
フレームワークの勉強をするにはいいとは思うよ。

713:nobodyさん
08/06/23 16:04:32
>>712の言うweb用のフレームワークとして間違った方向とか正しい方向とかは意味不明だが、
PRADOは構築ルール縛りをするには良いとおもう。
開発効率は生だとものすごく悪いので、Radを待つか自前でつくるなりしないと使い物にならん。

714:nobodyさん
08/06/25 00:06:13
そういや、Kohanaって話題になったことある？
CIからforkして、PHP5 Strictと安定性・堅牢性を進めると聞いてるけど。
ググっても日本語サイト少ない・・・

715:nobodyさん
08/06/25 01:09:00
Kohana使ってるよ。
日本語情報どころか英語の情報もあまりない。

716:nobodyさん
08/06/25 11:12:53 2TehNRcN
>>713
詳しく書かないでｽﾏﾝ。

自分の感じた事を伝えようと思って、昔実験したサンプルを見ながら今書いてるんで現在のバージョンとは違うかもしれんけど

home.page
<com:TForm>
<com:TButton Text="Click me" OnClick="buttonClicked" />
</com:TForm>

確か、テンプレート風にこう書いて

Home.php
class Home extends TPage
{
public function buttonClicked($sender,$param)
{
$sender->Text="Hello World!";
}
}

で、アクションはこう書くだろ？
なんか、symfonyだと（というか、俺の主に使ってるフレームワークがsymfonyなのでそれとの比較になるが）request、responseっていうのがあって、webアプリなんだなぁ、と見るからに分かるんだが、
Pradoの場合、これ見るだけだとwebアプリだって分からないんじゃない？と思って「間違った方向」って言ってしまったんだ。
あくまで個人的な感想だと思って「間違った方向」については受け流してくれ。

# 改めて見るとやっぱり面白いフレームワークだとは思うな。
# ただ、実際に使うのは、request responseが無いとか、どうしても実装に何か無理がありそうな気がしてしまう、というのが感想な訳だ。
# バリバリに使ってる人の感想を聞いてみたい所かも？

717:nobodyさん
08/06/25 13:22:19
Webアプリ、しかもPHPでDelphi丸出しは厳しいものがあるよね

718:nobodyさん
08/06/25 17:48:03
>>716
なるほど。２．０の仕様だな。

719:nobodyさん
08/06/25 19:18:36
突然すんません。

いまいち『フレームワーク』ってのがわからないんです。

ググって調べたりしてるんだけど、『？』な感じなんです。

すご～くカンタンでいいんで説明してくれる方いませんでしょうか？
あと、こんなオレにおすすめの本あったら紹介して下さい。

プログラムは一応、データベースとか使って基本的なCMSとかつくれます。

今度、作ろうと思ってるサイトがあるんですが、『フレームワーク』ってのを
使った方がいいような感じがしてここへきました。

よろしくお願いします。

720:nobodyさん
08/06/25 19:20:21
ググれ

721:nobodyさん
08/06/25 19:39:02
>>719
framework
【名】
1. 骨組み｛ほねぐみ｝、フレームワーク、枠組み｛わくぐみ｝、下部構造｛かぶこうぞう｝、骨格｛こっかく｝

なんか作るときに土台が出来てると楽だろ？
でもその土台に制限されてしまうこともある。

722:nobodyさん
08/06/25 19:49:30
>>721
ありがとうございます。

ググってました。

『車』で例えるとしたら、
”キーを回すとエンジンがかかる”とかの仕組みができていて
一から作らなくてもいいってことなんでしょうか？

『いろんな仕組みのセットがあって、ボタンひとつで簡単に組み込める』
みないな感じですかね…？

723:nobodyさん
08/06/25 20:15:21
>>722
家を建てるに当たって、その骨組みが出来ているって感じ。
で、その骨組みに合わせて作っていくので、やりやすいよと。

>>722の車の例えだと、PEARとか見たいなライブラリだね。フレームワークではない。

724:nobodyさん
08/06/25 20:27:52
>>723
ありがとうございます。

ってことは、一戸建ての骨組みができている状態からスタートして
中身の部屋とかキッチンとかを入れて（？）いく。ような感じ？

フレームワークの違いってのは、その『骨組み』がマンションだったり一戸建て
だったりするってことなんでしょうか？

今、悩んでいるのは、フレームワークを使った方がいいのか、今までのように
普通（？）に作るのがいいのか。という所なんです。

725:nobodyさん
08/06/25 20:34:00 gyu7FUKS
直訳すると枠組み、だと思うんだが、骨組みの方が俺的にもしっくり来るね。

PHPを粘土と例えて、像を作ってみよう、という事になった時の事を考えてみると
いきなり粘土で像を作る事はできると思うが、やっぱり、予め骨組みあった方が作りやすいだろ？

でも、骨組みが、犬の骨組みだとしたら、人間の像を作るのは却って難しいと思う。

>>716
なるほど。という事は現在は大分変わってるのか。
そのうち、また見てみる事にするよ。

726:nobodyさん
08/06/25 20:34:34
>>724
そういうところで悩む人は、多分人のソースなんかあんまり読まない様なタイプの
人だろうから、いっぺん使ってみるのは勉強になるんではないかと偏見だけど思う。

まあ業務に使うかどうかは置いておいて、PHPでお仕事しているんなら触って損は
無いかと思う。

727:nobodyさん
08/06/25 20:40:00
こんな抽象的な話を聞いて何が分かるんだろうｗ

728:nobodyさん
08/06/25 20:41:46
>>724
ページの遷移部分だとか、データの検証(バリデーション)部分だとかが簡単に出来たり、
フレームワーク自身が持っているライブラリが便利だったりとか。
データベースへのアクセスに関しては各フレームワーク共に工夫されてて凄く使いやすいです。

＞フレームワークの違いってのは、その『骨組み』がマンションだったり一戸建て
だったりするってことなんでしょうか？

そうですね。「ちいたん」見たいなライトウェイトなフレームワークは一戸建てな感じで、
synfonyやEthnaやCakePHPなんかはマンションみたいな巨大なプロジェクトの開発に向いてるかと。

＞今、悩んでいるのは、フレームワークを使った方がいいのか、今までのように
普通（？）に作るのがいいのか。という所なんです。

フレームワークは、できるなら使ってみたほうがいいと思います。
開発の規模や趣味趣向によって合う合わないってのはあると思いますが、
プログラムを組む上での手法として、勉強になる部分は大きいですし。

とりあえず、賛否両論歩けど、CodeIgniterなんかを触ってみてはいかがでしょう。
日本語のマニュアルが充実しているのと、割かしライトウェイトなので、扱いやすいのではないでしょうか。

729:nobodyさん
08/06/25 20:43:00
>>725
ありがとうございます。

>>でも、骨組みが、犬の骨組みだとしたら、人間の像を作るのは却って難しいと思う。
これ気になります…

>>726
ありがとうございます。

自分はまだ、人のソースをじっくり見て分かる所まで行ってないと思います。
なんか、好きなようにしたくて。ソースはかなり変かもしれません。

今『CakePHP』の関連サイトを見てました。
CakePHPってどうでしょうか？

明日、ジュンク堂とか行って関連本探してこようと思います。

次ページ