5

質問1） レール上のルビーにプライムフェイスと同様の機能を持つ宝石があるかどうか知りたいのですが。なぜ私が尋ねているのですか

Primefaces（http://www.primefaces.org/showcase-labs/ui/home.jsf）を使用する場合、開発者はjavascriptやjqueryのものについて心配する必要はありません。

私の知る限り、JSFは仕様であり、利用可能なさまざまな実装の仕様に基づいて、primefacesはそれらの実装のUIフレームワークであり、primefacesにはjqueryとjavascriptlibsに基づく非常に多くのコンポーネントがあります。多かれ少なかれprimefacesは単にjavascriptラッパーとして機能します。私はprimefacesを使用していますが、主にビジネスロジックに集中しており、UIについて心配する必要はありません。

私はRubyonRailsのアプローチに大きく影響を受けており、たくさんの宝石があります。

私の質問は何ですか、primefacesによって駆動されるUIマジックに似たレール上のルビーに利用できる宝石またはUIフレームワークはありますか

注：純粋なjqueryやdojoのものを探しているのではなく、RubyonRails用のUIコンポーネント駆動型のものを探しています。Primefacesを使用したプロジェクトやRailsを使用したプロジェクトに取り組んだ人は、私の質問を100％理解します。

質問2） ユーザーインターフェースに関連する宝石のリストを知りたいのですが。私が求めているのは、Ruby on Railsで非常にニッチなユーザーインターフェイスを作成するためです。必要なもの（フレームワークまたは宝石）は何ですか。

4

2 に答える 2

5

前の回答の多くの部分は単に真実ではありません。回答者は、Primefaces である JSF2.0 を使用していないようです。JSF v1 は恐ろしく複雑で、誰にとってもひどい経験でした。JSF2.0 は JSF v1 とはまったく異なります。そのため、JSF2.0 を使用していないと認める否定論者には注意してください。

JSF2.0 は、非常に生産的で楽しい Web フレームワークです。それはまったく「企業性」ではありません (しかし、その評判は JSF v1 から得られます)。軽量で邪魔になりません。これは Java (最終的にはコンパイルされ、解釈されません) であるため、非常に高速です。

その核となるのはテンプレート フレームワークです。コンポーネントに限定されません。デフォルトでは、自由形式の HTML です。リクエストのライフサイクルを通じて状態を維持できる、コンポーネントと呼ばれるスマート タグを使用するオプションがあります。これは、検証や ajax などを実行するのに便利です (どちらも JSF2.0 では非常に単純なタスクです)。

JSF2.0 は、リクエスト、ビュー、セッション、さらにはアプリケーションなど、さまざまなスコープにバインドできる Bean (定義した小さなステートフル オブジェクト) のライフサイクルも管理します。コントローラーは Rails の同様の概念ですが、JSF2.0 にはルートの概念がなく、代わりに EL を使用して関数オブジェクトを渡すため、代わりにアクションの概念があります。これにより、非常に自由な形式になります。好きなソフトウェア パターンを使用できます。私は MVC よりも MVVM が好きで、そのパターンを使用する傾向がありますが、Rails はかなり厳密な MVC です。

コンポーネント ライブラリは、ページに追加できる Java コードと HTML フラグメントのバンドルです。Primefaces は、一般的に使用される UI ウィジェットのコンポーネント ライブラリです。基本的に、いくつかの JSF/HTML コードを記述し、それがブラウザーで JQuery UI を駆動します。

Ruby で JSF2.0 を使用できますか? JRuby を使用できると思います。Ruby オブジェクトに JSF2.0 アノテーション (@ManagedBean など) を使用してアノテーションを付けることが可能であれば、少し実験するだけでこれを機能させることができると確信しています。

頑張ってください。これを行うことになった場合は、投稿してください。

于 2012-09-03T20:21:35.437 に答える
4

JSF (主に MyFaces) と Rails の以前の経験から、ここで「間違った」質問をしているような気がします。

ほとんどの場合、Rails を使い始めたばかりだと思います。JSF のこともコンポーネントのことも、(JSF プロジェクトで) JavaScript をどのように書いたかさえも忘れているかもしれません。RoR は別世界であり、入り込めば入るほどコンポーネントを無視するようになります。少なくとも私の場合はそうでした。また、Ruby on Rails を使用して「単純な」Web プログラミングを再発明し、「貴重な」JavaScript の経験を得ることができましたが、以前の Java の「知恵」の一部を手放さなければなりませんでした :)

私が知る限り、Rails にはそのような UI の「魔法駆動型フレームワーク」はなく、需要もないと思います。JavaScript 統合を含むビュー レイヤーは、(コンポーネント ベースの) JSF アプリケーションと Ruby on Rails では (概念的に) 異なります。

個人的には、JSF は、一度作成され、最小限に進化し、コンポーネントのカスタマイズをほとんど必要としない (または、カスタム コンポーネントを考え出すのに費やした時間を他のアプリで再利用するよりも、いくつか必要とする) 「企業形式」のアプリケーションに適した選択肢であるとしか考えていません。 .

JSF のビュー レイヤーは、使用しているコンポーネントを制限する傾向があります。「ウィジェット」の HTML のレイアウトを明確に考える代わりに、既存のコンポーネントをニーズに適合させることを考える傾向があります。実際のユースケースの要件を満たし、コンポーネントの拡張やハッキングの可能性を調べるのに多くの時間を費やすことになります。言うまでもなく、あなたが書いていない生成された HTML + JavaScript の断片を適応させるのは難しいかもしれません。たとえ慎重に書かれたとしても、まだそこにあるので、コンポーネントごとにさらに別の「小さな」API を学ばなければなりません。

Rails を見ると、設計が異なります。「単純な」ビューを作成し (最初は時間がかかります)、再利用するためにそれらを論理的にパーシャルに分割します (新しい要件が発生する可能性が高いため)。パーシャルを再利用すると、マークアップに付属する JavaScript を制御できることは言うまでもなく、新しいシナリオに簡単に適応させることができます。

多くの新しいアプリが REST API を備えたファット JavaScript クライアントとして作成されていることに加えて、ほとんどの場合、HTML と JavaScript を完全に制御する必要があるため、ここでの JSF が負担にならないとは思えません。UI について心配する必要があり、心配する必要があり、確かに別のサーバー + クライアント JavaScript ラッパーは必要ありません。コンポーネントについて考えるのが好きなら、Ext-JS などのクライアント側のコンポーネント ライブラリを検討することをお勧めします。

于 2012-07-02T18:01:52.057 に答える