保守

手始めに、サイトのリニューアルついでにSmarty入れてCMS'っぽく'してみる。

お？サンプルか？

勉強すればするだけフレームワーク使えば手っ取り早いことがわかった。

自作のモチベ下がっちまったい。

自作する理由は楽するためじゃないだろう

もっと手っ取り早く使えるフレームワークをつくるために勉強すればいい

元々目的としては自サイトで使うための軽量フレームワークを作るために勉強してたの。

で、既存のフレームワークのマニュアルとかソースを参考にしながら作ってたんだけど、取り込むつもりが逆に呑まれた形。

凄く難解なソースを引き継ぎさせられて、途方にくれかかった。
で、市販のモジュールを使うなどして０から作り直すなどの方法を
模索したが、結局は引継ぎしたソースを解読して手を加えるのが
楽で、早い道であることが分かった。みたいな話かな？ｗ
PHPではないが、俺はちょうどこんな感じの体験をしたことがあるｗ

まぁ、たぶんそんな感じ。
要するにフレームワークの魅力に気付いたわけですよ。

先に気づいてからやれば良かったな

そういうのは簡単に気づけないだろう。
プログラムは体感して分かっていくものなのだから。

俺としては魅力に気付けただけでも大きな進歩だ。

自作云々は別にして。

あけおめ

では、その気づいた魅力的な部分をここなどで紹介してみるというのはどうよ？
PHPでOOPのスレの趣旨に添ってると思うし、他の人の意見を聞いて
参考になる部分もあると思うのだが。

>>4
宣伝乙

えらく昔の書き込みにレスしてるな。

フレームワークの魅力についてまとめてみるか？

どうぞ

>>667
wikiにしてもらえるなら俺も手伝う

いや、俺はそんなに文章がかけるほど知識は無い。申し訳ないが、サポートに回る

なぜにフレームワークの魅力をまとめようと？

>>662 ≠ >>667
だからね。
俺は人に語れるほどまだ理解してないから。

なんだ教えて君か

おまえもな

サポートするといってるんだから、教えてじゃないだろｗ

http://q.hatena.ne.jp/1188498291

>>676を読んでみて、PHPに限らず、ASP.NETを体感してみると、フレームワークの
メリットやデメリットがみえてくるんじゃなかと感じた。
あれは、ポストバックとか独自の理論があって、それを学ばないと使えるようになれない。
しかし、ページをまたがってデータの受け渡しをする際は、非常に便利な機能であり、
使いこなせるようになると、生産性が向上する。

一問一答形式でwikiでも作るか

visualstudioが優秀すぐる

Java とか C#やったほうが飲み込みは早くなるのかな。
でも両者とも動かせるサーバって高いからなぁ。
Web以外にも用途はあるけど。

>>680
いろいろな言語に触れてみると、その分視野は広くなることだろう。
共通して実装している機能を見ることで、OOPの概念をつかんだり
出来るはずだし。
しかし、広く浅くにとどまっていると、何も作れないで終わるので、
物を作る際は、一つの言語に絞り込んでいた方が良い。

なので、java や C# においてはローカルで稼動させるのにとどまらせて
おいたらどうかな？ASP.NET だと、Webアプリでもローカルでテスト動作
させる環境が Express にもついてるし。

ウェブアプリの範囲なら、どの言語のどのフレームワークでも大差ないよ。
ASP.NETは、デスクトップアプリケーションからのアプローチなんで、これだけちょっと勝手が違うけど。
プログラミングを仕事にするなら、最初は型ありの言語をやった方がいいと思う。
JavaとかC#が理解出来れば、PHPやPerlはすぐに分かる。

でも、perlってすぐ忘れちゃうよな...

>>683
それはそれで良いのではないかと思っている。
perlのモットーがあわないのであれば、PHPを使うで良いと思うし。

PHP では OOP を学べないという意見があるが、結論だけ
いうのではなく、その理由の部分を述べていくといいかもね。

別に学べるのでは？

ん、どこかにPHPでは学べないと書いてあるのかな？

個人的には、純粋にOOPを学びたいのであれば別の言語がいいかなーとは思う。
理由は、Webは身近だし使い慣れてると言えるかもしれないが
PHP以外のHTMLやらJSやらHTTPプロトコル等知らなければいけない知識が多くあるから。
その辺を知っていれば問題はないと思うけどね。

オブジェクト指向を本格的に勉強したければ、GUIのプログラムを書いた方がいい。ウェブアプリじゃオブジェクト指向が出る幕はない。

出る幕はあると思うが、最終的にフレームワークを構築することになると思う。

いきなりWEBフレームワークを作ることは難しいので、
実際に存在するフレームワークのソースを追いかけ、参考にしながら、
オレ的フレームワークを組み上げることで、様々な知見を得ることができると思う。

また、これらのフレームワークはたいてい、何らかのデザインパターンやアークテクチャパターンが使われているため、併せてこれらも学習する必要があると思う。

WEBアプリでもActionScript3なら、バリバリOOPだYO!

まあ、いつかはサーバサイドはAPIを提供するだけで、クライアントのUIはFlashとかJavaScriptに任せるような時代がくるのかも。

>>691
エンタープライズならそんなケースいくらでもあるだろｗ

>>689
俺的フレームワークなんて作らないほうがいい。
自己主張ばかり強い勘違いになりがちだし、遠回り。
良い先人の手本を眺めるほうがよっぽど効率的だわ。

>>693
ホントにそうだとしたらとっくに淘汰されて現状のフレームワークの乱立状態にはならないと思うが

>>692
聞いたことないな。そんなことするぐらいなら、Windowsアプリケーションなり、Accessなりで直接DBを参照するから。

クライアントマシンの性能がこれだけアップしているのに、
クライアントマシンの性能を利用しないなんて
どれだけ無駄なんだかｗ

ぶっちゃけサーバサイドのフレームワークは制作の効率のためであって
性能うんぬんは考えてないんだよな

勉強不足で申し訳ないんだが、制作の効率より性能うんぬんを優先したフレームワークを教えて欲しい

つーか開発効率は性能に含まれるだろう

は？