私はExtJS 4.1.2で書かれた既存のアプリケーションを取得しています。これは非常に大きなコードベースです。 4.1.2アプリケーションはCMDなしで作成されました。ソースはindex.htmlに直接追加されています。4.1.2から6.xへのExtJSアプリケーションのアップグレード
のExtJSの背景の多くをせずに、私は、次の2つの質問があります。
1）それは最初5.X、次に6.xへの5.xから行くためにアップグレードする意味を成していますか？または、4.1.2から6.xに直接行くのは安全ですか？
2）新しいプロジェクトを作成して手動でコピーするか、理論上はソースを更新して新しいextjs libを指すようにして、壊れているか互換性のないすべてのクライアントコードを修正しますか？
私はExtJSの歴史を多く辿っていないので、2つの主要なリビジョンをアップグレードすることがこのフレームワークでも実現可能かどうかはわかりません。
CMDが既存のアプリで使用されていない場合は、どのような方法が最適ですか？
私はExt.jsをプロダクションで使用していますが、現在同様のアップグレードを行っています。私たちは4.1.1です。ここに私たちがしたことがあります。
1）最初に5.xにアップグレードしてから5.xから6.xに移行するのは意味がありますか？または、4.1.2から6.xに直接行くのは安全ですか？
5.xから6.xにアップグレードすることを選択しました。この背後にある理由は、6.xが（当時）安定しているとは考えられなかったため、対処するバグが少なくなるからです。最大の飛躍は4.1.2から5.xに移行する予定です。 5から6に移動するのは簡単です。 5.xには、APIの新機能や変更が含まれています。 6.xはSencha TouchとDesktopを統合した技術的な負債のほとんどが背後にあります。これは、モバイルとデスクトップ用に1つのアプリを持つことができるためです。ベータ版よりもはるかに安定しているので、おそらく6に直接移動することができます。
2）は、新しいプロジェクトを作成し、手動でコピーされるべきか、私は、理論的には、ソースを更新することができ、新たなExtJSのlibにを指すように、バックもはや壊れていないか、だすべてのクライアントコードを固定切り売り互換性がある？
私たちは第2のものと一緒に行きました。 extjs lib全体を置き換え、すべてのクライアントコードをテストして修正しました。それはかなりスムーズに行った。私たちは煎茶の建築家を利用する利点がありました。 Senchaの建築家はjavascriptコードをjsonのメタデータファイルとして保存しています。アップグレードする場合は、自動チェックを行うことができます。私たちはまた、建築プロジェクトの外に、あなたが持っているものに似ている多くのコードを持っていましたが、いくつかの問題がありました。それは50-50分割であった。
アップグレードの実行可能性を評価する1つの方法は、コードがExt.Jsとどのくらい密接に絡み合っているかです。私たちは、開発者にコアExtクラスを拡張し、ストアとビューのための多くのコアメソッドをオーバーライドするミニフレームワークを作成させました。また、Ext.Js内部に触れた複雑なプラグインフレームワークもありました。これらのメソッドをオーバーライドすると、アップグレード中にコードが非常に壊れやすくなりました。おそらく私たちの努力の60％は、その枠組みを修正することになりました。 Ext.Jsと密接に絡み合っていて、移行に多くの努力を払った他のページもありました。コードがはるかに単純だった、例えば、いくつかのリスナーを持つウィジェットを作成しただけで、多くの変更は必要ありませんでした。
私が理解しているように、Sencha CMDは、フレームワークのための公式のパッケージャ、ミニジャおよび依存マネージャです。Sencha CMDを使用してアップグレードすると、メインライブラリが置き換えられ、実際のjavascriptを修正するためにはあまり効果がありません。 Senchaのアーキテクトは、時間を節約するという点で多くの成果を挙げています。