ちがうよ、そのメロンパン屋の名前がメープルだったから間違えたんだよ。

>>44
ドキュメント強化月間は終わりました。残念！

Mapleを理解するにはMojaviとSeaser2を理解するのが早道という罠｡
Ethnaも相当わかりにくいが｡

でも来月MapleDay(仮)というのが大阪であるらしいので､そこから盛り上がるかも｡

Springの解説書よりMapleのソース全部読んだほうが速いかもｗ

>>56
確かにｗ

でもフレームワークの概念自体が分かっていない人が
あのソースを見て理解できるかはちと疑問。
MapleはDIやAOPを志向しているので、とっかかりに
その手の解説書読むのはいいかも。

ぶっちゃけ、DIとか言われても、なんの事だかさっぱりわかりません。
依存性注入？なに？
具体的に言うとナンなのさ？

詳しくはないが
オブジェクトを入れられることを前提に
オブジェクトを作ることと理解してる。
シンプルに言えば
まんこ方式だね。

>>59
> まんこ方式だね。

わかんねーよｗ

自演オッツ！

いいかげんにチュートリアルの続きを書いてほしい

もう、やめたんじゃないのか？

Mapleって作った本人も使ってないっぽくない？
作って満足しちゃってるみたいな所が感じられる。

Ethnaは自分で使うために作ってたら機能アップしていった感じ。
Greeでも使われてるみたいだし。

ブログではああしたい、こうしたいって書いてあるのに。
ドキュメント強化月間とかも言ってたけど、あれはなんだったの？

まぁ僕たちは作ってもらったものをタダで使わせてもらってるだけなんで
偉そうな事は言えません。

喩えて言うならエロ動画を配布する人と媚売る取り巻きの図。

やると約束したことを1年以上たっても進まないのは人間性の問題。
瞬発力はあるが、継続ができない。
勢いで一気に作って「わからないことは聞いてね」って放り投げる。
（悪気はないので聞けば丁寧に教えてくれる。）
こういう人はドキュメント（自分には必要ないから瞬発力が沸かない）
作成作業をしようとしても無理です。人格の否定じゃなくて、
適材適所ということです。だれかをいい意味でノセテ協力してもらえばいいのに。

>>69
まさしく、そんな感じだな。

熱狂的ですね。
Mapleって愛好家がいるんだね。
愛好家と言うか信者の域だね。

今度Maple使ってみます。

本人が管理できてない以上は、
プロデューサー的な人間を引っ張り込まないとダメだろうね。

しかし、わざわざ自分のプロジェクトの進行を他人に管理してもらって、
やりたくもないことをやらされるようにする物好きも多分あんまりいないだろう。

こういうのは自分がやりたいからやってるんだろうしねぇ。
小さめのオープンソースプロジェクトで、上から仕事を指図されたら貢献する奴はたぶん逃げるよね。

混乱してるようだが自己管理ができていない訳で
それをMapleの管理として考えるのはミスリードと思う。
仲間内の新年会や、河原でのバーベキューパーティは
音頭取りは居るけれど、上から指図するばかりじゃないでしょ。
（個人の魅力で上から指図できる人もいるのだがそれは別格）
ノセテいくというのはそういうこと。
blogみると、それができない人とも思えないんだけどな…。
無理してるのかな。ご自愛ください。

まぁ Maple 自体が仕事なわけではなく個人の自由時間を使って開発してるんだろうしな

だからなおさら個人の範疇からプロジェクトの範疇に拡大してしまって
自分は楽をしつつ開発に専念してくれれば、と思う

ユーザー少ないから仕方ないような・・・。
ユーザーがdocやら勝手に作っていかないと流行りもしない。

吠えるなら手伝えば言いだけの事だと思うが・・・。

というような
「その責任の所在はユーザーにあり、その責務を果たせ」
といった論調では協力者は得られない実例でした。

単純に忙しいだけと思うが…。

>>77
ユーザーが付かない事が問題で、
つまりユーザが付かない代物ね。
もうMojaviでいいかあ。って事。

>>79
日本語変だよ

ゴメソ

フレームワークって敷居が高いから、早々ユーザも増えない。
中途半端になってるチュートリアルくらい、なんとか最後まで作ってほしいと思った。
稲刈りするには田植えから…、って感じじゃないか？

チュートリアルを書くのは別に作者じゃなくてもよいのにと思った。

今日、 Maple Day でしたっけ？
行った方いらしたらどんな感じだったか教えてください。

自サイトをフレームワーク使って再構築しようと思って
MapleとEthnaで迷ったけど、結局ドキュメントに勝るEthnaにした。
正直、Javaとか触ったことのない自分にとって、
Mapleには分からないところが多い。
概念的な説明より、チュートリアルを充実してほしいと思った。
でも、期待しているので、今後も温かく見守っていきたい。

>>84
なんかでも作者の目的は Maple そのものじゃないんでしょ？
Maple 以外の話も、なんて言ってるけどそれって Maple そのものに
もうあんまり興味ないってことじゃないのかなぁ。そういうことって
自分でもあるから別にそれ自体は否定しないんだけどさ。だったら
そうはっきり言ってくれた方がユーザーにはありがたい気がするよ。

kunitさんはもっと周りの人に頼っていいんじゃないかな。
自分が忙しいなら他の人にやってもらえばいい。
コア部分はHawkさんにまかせたり
ドキュメントとかのユーザ方面はBobchinさんにまかせたりして
自分は理想を追い求めたりそれを熱く語ったり全体を調整したりActiveGatewayとか好きなものを作ったりしたらいいとおもう。
あと互換性云々で次バージョンが遅れるぐらいなら互換性無しでいいよ。
きっと誰かハックしてくれるよ（kumatchさんあたり）。
行きたいとこまで行っちゃってください。

なんにせよ待ちこがれてますよってことで。

「互換性云々で次バージョンが遅れるぐらいなら互換性無しでいいよ」に一票

どうせ今の Maple は多かれ少なかれ手を入れて「俺Maple」にして使ってる人が多いだろう
現在のサイトのMaple部分だけを入れ替えてワーイ新バージョンだーなんてことが可能な人はほとんどいないだろうし
だったら次回のサイトで新Mapleがいち早く使えるように非互換上等で新バージョンを公開してほしいね

どれでもphpのフレームワークならそのまま使うやつはいねーだろ

自分の狭い基準で決め付けるバカがいるな

>>87-88
漏れも新バージョン早くみたいー

確かに互換性気にする程、使ってる人いなそう。

>>93
皮肉？

>>94
別に皮肉ではなく、どのように実装しているのかを
知りたいだけです。

>>95
勉強というならなおのこと、探すのも勉強のうち。
AOPは実装されてないよ。DIもセッタだけ。
いっぱい改造してAOPフィルタ（？）公開してください。
簡単なSQL発行しかできないO/Rマッパなんかよりも、
DBトランザクションやエラー処理の記述が簡単にできる仕組みの方が
フレームワークに必要と思う今日この頃。

>>96
あれ？MapleってAOP実装してませんでしたっけ？
ちなみに、DIがセッタだけっていうのは、
セッター・インジェクションのことですか？
それだけではまだDIって不完全なのでしょうか？
ちょっとまだ知識が浅いので教えていただけるとうれしいです。

>>97
不完全という表現は違うと思うが例えば
$foo = new HogeClass(new HugaClass);
って時、どうする？

>>98
つまりDIコンテナに格納するクラスがコンストラクタで
引数を受け取るタイプの場合どうするかってことですか？