3

現在、最も人気のあるWebアプリフレームワークには、Ruby-on-Rails、Django 、およびDrupalやJoomlaなどのさまざまなPHPフレームワークが含まれます。しかし、私はWeb開発へのアプローチが異なると主張するいくつかの「次世代」Webアプリフレームワークについて読んでいます。

おそらく最もよく知られている例は、Smalltalk言語に基づいて構築されたSeasideフレームワークです。[概要]ページから、 4つの主要な機能が一覧表示されます。

  1. プログラムによるHTML生成
  2. コールバックベースのリクエスト処理
  3. 組み込みコンポーネント
  4. モーダルセッション管理

複雑なインタラクティブフォーム、タスクフロー、多くのグラフとビジュアル、UIの柔軟性と再利用（多くのウィジェット）など、デスクトップアプリに似た機能を必要とするかなり複雑なシミュレーションWebアプリを開発しているので、Seaside's機能2、3、および4は非常に魅力的に聞こえます。

したがって、他の（高度な）Web開発者から、オープンソースの「次世代」Webアプリフレームワークが存在すること、Django / RoRなどのより使い慣れたツールよりも「優れている」理由、およびどのようなアプリについて聞いてみたいと思います。古いフレームワークでは困難/苦痛を伴うこれらの新しいツールを使用して構築できます。たとえば、Seasideの継続ベースのセッション/状態管理により、ステートフルアプリケーションがグローバルセッション変数よりもはるかに簡単になることを理解しています。それはどれほど役に立ちますか？

あなたの経験と洞察を事前に感謝します！

4

6 に答える 6

3

Haskell 言語に基づく Yesod フレームワーク。

于 2010-07-12T19:05:21.257 に答える
3

MFlowは、Seaside と同様に Haskell で書かれた Web フレームワークですが、継続の問題 (永続性とスケーラビリティの問題) はありません。

Web 開発の主な問題は、HTTP のステートレスな性質です。これにより、あちこちで参照される変数やイベント ハンドラーの安全でない識別子でいっぱいのイベント処理プログラミング モデルが強制されます。イベント ハンドラーは変数のスコープを共有しないため、ほとんどの場合、状態は動的に型指定されたデータのハッシュ テーブルの形式になります。

ocsigen (ocaml) や seaside (smalltalk) などの継続ベースのフレームワークは、戻るボタンを適切に処理し、通常の変数に状態を保持し、ナビゲーションはコードを読むことで理解できます。そして、それらはほとんどが特定のレベルまで RESTFul です。しかし、これらのフレームワークはスケーラブルではなく、継続に固有の問題による永続性の問題があります。

Web アプリケーションのもう 1 つの問題は、HTML の型のない性質であり、不一致や実行時エラーが発生する可能性があります。

MFlow では、各ページだけでなく、ナビゲーション全体がコンパイル時に安全であり、上記の問題を共有しません。継続ベースのフレームワークの優れた特性を備えていますが、継続の代わりにログとバックトラッキングを使用するため、スケーラブルです。標準の Haskell Web ライブラリ (WAI、formlets、stm、blaze-html) を使用します。プラグ可能な自己完結型コンポーネントのシステムがあります。

これは 3 ページの完全なアプリケーションです。ループでは、2 つの数値を要求し、合計を表示します。好きなだけ戻るボタンを押してください。設定ファイル、ページ、ソース コードのあちこちに配置しなければならない魔法の識別子はありません。

module Main where
import MFlow.Wai.Blaze.Html.All

main= do
  addMessageFlows  [("sum", transient . runFlow $ sumIt )]
  wait $ run 8081 waiMessageFlow

sumIt= do
  setHeader $ html . body
  n1 <- ask $  p << "give me the first number"  ++>  getInt Nothing
  n2 <- ask $  p << "give me the second number" ++>  getInt Nothing
  ask $ p << ("the result is " ++ show (n1 + n2)) ++> wlink () << p << "click here"

少し変更するだけで状態を永続化できます。

http://hackage.haskell.org/package/MFlow

ここに例とハウツーがあります: http://haskell-web.blogspot.com.es/

于 2013-04-27T23:24:17.257 に答える
3

シーサイドは私たちにとってうまくいっています。私たちは Pharo で開発し、Gemstone OODB を使用して VPS に展開しています。現在、前の会社で ASP.NET MVC を使用していたときの約 5 倍の速さで開発しています。

データベース コードなし、生成された html (テンプレートなし)、および javascript (Scriptaculous/jQuery/RaphaelJs) の組み合わせは、非常にうまく機能します。

ポイント1は本当に重要です。十分に DRY なテンプレート ベースのシステムを見たことがありません (ただし、Lisp ベースのシステムはおそらく存在します)。

私はカプチーノの初期リリースでも遊んだことがあり、ココア/ネクストステップのバックグラウンドがあればいいのですが、(最初の公開リリースから数か月後) 私たちにとって十分な完成度ではありませんでした.

于 2010-07-13T18:49:01.103 に答える
2

Smalltalk の Seaside フレームワークに相当する Python はNagareです。これは有能なシステムのように見えますが、現在、ドキュメントの深さ/幅に一貫性がなく、オンラインで多くの開発者の話/経験を見つけていません. 継続のサポートにStackless Pythonを使用していることも興味深いです。

于 2010-07-12T18:45:36.907 に答える
2

率直に言って、サーバーとの間のすべての UI インタラクションを往復している限り、「デスクトップのような」エクスペリエンスを得ることはできません。私はほとんどサーバー側のフレームワークを放棄しました。私の Web アプリは JavaScript と Web サービスであり、サーバー側のコードの量を最小限に抑えようとしています。残りはわずかですが、Zend Framework にラップしますが、データの永続化と検証レイヤーにはそれほど多くのコードは必要ありません。

私はJavaScript コードにExtJSを使用していますが、いい JavaScript フレームワークがたくさんあります ( Cappuccino、SproutCore、GWT、Dojoなど)。

いずれにせよ、非常にリッチなインタラクションはすべて javascript で終わるので、プラットフォームを選択する場合は、javascript と非常によく統合されたものを選択してください。明らかに、javascript ツールキットには優位性があります。私が収集した GWT は、javascript ではないという点で魔法ですが、問題が発生することなくそのふりをすることができます。Quake II の JavaScript ポートは GWT プロジェクトなので、何かを言っているのです。

于 2010-07-12T18:24:33.373 に答える