Turbine

This document is to explain a different type of philosophy for working with Context based MVC tools like WebMacro (WM) and Velocity (V) than I think that the Turbine community is used to. The requirement for this philosophy has come up recently during Scarab development and I would like to share and document it with you all. Many thanks to Brian B for being patient with me and trying to explain exactly what he wants to see. So, let me start off by giving a little bit of history and then moving on from there...

　このドキュメントは Turbine コミュニティがどのようなものであったかというよりは、WebMacro とVelocityのような、コンテキストベースの MVC ツールの間にある、違うタイプの思想を明らかにするものです。この思想に対する要求は最近では Scarab の開発で浮かび上がったもので、私はあなた方すべてと、共有し開発を行いたいと思いました。私と共に忍耐強くあった、そして正確かつ確実に自分の望むことを伝えることに努力した Braian B に大きな感謝をします。そして、少々の歴史について、なにがここから動いて行くのかについて始めさせてください。。。。

The current encouragement that Turbine gives to developers is to do a mapping between one Screen (Java) and one Template (WM or V). The way it works is that you build up a Context object that is essentially a Hashtable that contains all of the data that is required to render a particular template. Within the template, you refer to that data in order to format it for display. I will refer to this as the "Push MVC Model." This IMHO is a perfectly acceptable, easy to understand and implement approach.

Turbine が開発者に与える現在のところの奨励は、１枚のスクリーン ( Java ) と１つのテンプレート ( WebMacro もしくは Velocity ) の間にマッピングを行なうことです。稼動する方法とは、特定のテンプレートをレンダリングすることを要求されるデータの全てを含んでいる元は Hashtable のコンテキストオブジェクトを構築することです。テンプレート内で、あなたは表示のためにそれをフォーマットするためにそのデータを参照します。私はこれを「Push 型の MVC モデル」であることとして言及します。このつつましい言い分は完全に許容できるもの、容易に理解出来るものであり、なおかつ実装のアプローチです。

We have solved the problem of being able to display the data on a template without requiring the engineer to make modifications to the Java code. In other words, you can modify the look and feel of the overall website without the requirement of having a Java engineer present to make the changes. This is a very good step forward.

私たちはエンジニアに Java コードへ修正をすることを要求をすることなしに、テンプレートでデータを表示することができるように問題を解決しました。言い変えれば、あなたが変更を加えるために Java エンジニアが貢献することの必要条件なしに、全体的な Webサイトの外観と感触を修正することができます。これは前方へ進むための非常に良いステップです。

However, it has a shortcoming in that it makes it more difficult to allow the template designer (ie: a non programmer) the ability to move information on a template from one template to another template because it would require the logic in the Java code to be modified as well. For example, say you have a set of "wizard" type screens and you want to change the order of execution of those screens or even the order of the fields on those screens. In order to do so, you can't simply change the Next/Back links you need to also change the Java code.

しかしながら、テンプレートデザイナー( プログラマでない人を参照 )に与えることをもっと難しいようにすることは短所があります。なぜなら、1つのテンプレートからもう1つのテンプレートまでテンプレートの情報を動かす能力がなぜなら、同様に修正される Java code のロジックを必要とするからです。例をあげると、あなたが「ウィザード」形式の screen を持っていて、それらの screen の実行の順番を変えたかったり、もしくはそれら screen のフィールドの順番を変えたいような場合です。そうするためには、次へ／戻る-形式のリンクを簡単には変えることが出来ませんし、 Java コードも変える必要があります。

Another example of this is if you have a form on a page and you want to be able to split that form across several steps across several pages. In the current model, you would have to potentially write/modify several Java classes. In reality, this should be something that is easily modifiable by just a single template engineer who doesn't necessarily even know Java.

もう1つの例は、いくつかのページを介し、いくつかのステップを介するページ上のフォームがあり、分離するようにしたいとします。現在の例では、（現在のモデルでは、）あなたは潜在的に書いたり修正したりする Java クラスがあるでしょう。現実的には Java の知識がない一人のテンプレートエンジニアでも、簡単に修正できるべきです。

There are several considerations that one must take into consideration regarding the design of a system to provide this level of abstraction. For example, when someone submits the form and there is an error. Proper UI would suggest that you should re-display the page with the previous form data filled in as well as an error message that details the problems. You also need to consider the ability to display the same form that may be pre-populated with information from the database instead of as an error from the user.

この抽象レベルを提供するためのシステムの設計に関して開発者が考慮に入れなければならないいくつかの考慮があります。例えば、誰かが送信を行う際に、そこはエラーであるとします。適切な UI は問題を詳述するエラーメッセージと同様に、埋められる以前の形式データで再びページを表示するべきだと示唆するでしょう。あなたは同様に、ユーザからのエラーからとしての代わりに、データベースからの情報を再度埋め込む同様のフォームを表示できる能力を考慮する必要があります。

So, beginning with Scarab, we are going to try another model which I will describe as the "Pull MVC Model". What this entails is the ability to create an object that is able to "pull" the required information out at execution time within the template. Thus, it becomes the job of the template designer to understand the API of objects available to him/her to take advantage of.

その結果、 Scarab から始めて、私たちは「Pull MVC Model」と説明することである、もう1つのモデルを試みます。このことがが内包しているのはテンプレート内で実行される時間内に、必要とされる情報を「引き出す（ pull ）」オブジェクトを生成する能力です。このように、テンプレートデザイナーが利用可能なオブジェクトの API を理解することはテンプレートデザイナーの仕事になり、利用することに値します。

Instead of the developer telling the designer what Context names to use for each and every screen, there is instead a set of a few objects available for the template designer to pick and choose from. These objects will provide methods to access the underlying information either from the database or from the previously submitted form information.

開発者の代わりに、それぞれ全ての screen にどの Context 名称を使うかデザイナーに伝えることの代わりに、テンプレートデザイナーのために取り上げて選定する使用可能ないくつかのオブジェクトのセットがあります。それらのオブジェクトは、データベースや先に送信されているフォームの情報の両方にアクセスするメソッドを供給します。

Gone are the days where one would have a Java class that would be responsible for building the context up for the template. Instead, there would be a single base class that places the few objects into the context for every request and there is a documented API that the template designer can refer to in order to access the information that he/she needs to get at. Of course this information is only retrieved when requested and can also be managed in a cache for reuse.

過ぎ去っていったのは、テンプレートにコンテキストを構築する必要のある Java クラスがあった日々です。その代わりに、全てのリクエストにコンテキストの中へいくつかのオブジェクトを置く単一の基礎クラスがあるでしょう。そしてテンプレートデザイナーが取り掛かる必要がある情報にアクセスする順番に彼らが参照できる、ドキュメント化された API があります。もちろんこの情報はリクエストされた時にのみ到達可能であり、同様に再利用のためにキャッシュしておくことが出来ます

By moving to a "Pull" model, it becomes possible to more easily achieve complete independence from the Java engineers in order to not only change the look and feel (UI) of the site but also the information architecture (IA) layout and flow of the site.

「Pull」モデルへすることにより、さらに簡単にサイトのルック＆フィール ( UI ) だけでなく、情報アーキテクチャ( IA )レイアウトとサイトのフローの変更を Java エンジニアからの完全な独立を成し遂げるすることが可能になります

While this puts more requirements on the Java engineer to make sure that the template designer has a well defined API, it will save the Java engineer many hours further down the road when the client requests IA changes because now the responsibility is on the template designer to make the changes. Therefore the increased initial developer time is justified in order to realize the long term goals of the project.

これが Java エンジニアにテンプレートデザイナーには上手く定義された API があることが確かであることをさらに要求をすると、クライアントのリクエスト IA が変更するときに Java エンジニアは現実に多くの時間を時間を節約できます。なぜなら現在、変更をする責任はテンプレートデザイナーにあるからです。それゆえに、プロジェクトの長い期間のゴールを認識するために、増加した初期的な開発者の時間は正当化されることになります。

I hope that this makes sense to everyone. I'm sure that some of you are probably saying "well, duh!." However, this is really not the model that has been encouraged so far within Turbine nor within other products such as XMLC (which actually operates *only* on the Push model), so I believe that it is somewhat uncharted territory for some people. The only products that I can think of right now that encourage this is JSP taglibs and Tea, however, I still feel as though they have missed the boat on this in one way or another.

私はこれがみなさんに意味があることとなることを望みます。あなた方の何人かがおそらく「いいね、当たり前だろ！」と言うことは分かっています。しかしながら、これは本当に Turbine 内で今までのところ奨励するられたモデルでなく、 XMLC ( 実際に Push モデル *だけで* で機能します ) のような他のプロダクト内でもありませんので、私はそれは何人かの人々にとってなにか、未踏の領域であると強く感じます。これは JSP taglibs と Tea であると奨励する、今現在私が考えているところの唯一のプロダクトですが、あたかもどうしたことかそれらがボートに乗り損ねたかのように私はまだ感じます。

Comments are appreciated. Please post them to the Turbine mailing list.

コメントは理解されます。Turbine mailing list に送ってください。