-Tapestry and HiveMind

今のBasePageクラス（TapestryのPageの元）はこんなコードですが、

public class BasePage extends AbstractPage
{
    // （略）

    public IMarkupWriter getResponseWriter(OutputStream out)
    {
        return new HTMLWriter(out, getOutputEncoding());
    }
}

たぶん下記のように変更されて、コンテナにはIMarkupWriterとしてHTMLWrite・WMLWriter(共に既存）やPDFWriterなんかを登録する。

public class BasePage extends AbstractPage
{
    // （略）
　　private IMarkupWriter writer;
    public IMarkupWriter getWriter(){return writer;}
    public setWriter(IMarkupWriter pWriter){writer = pWriter;}
}

from うえやんの日記2004/03/22
なるほど、と思いMLを「HiveMind」でgrepするといくらか議論がありました。流し読みですが、まずスペックXMLのレベルで行くと、<service>と<extention>エレメントを廃止して、この機能にHiveMindを入れるみたい。<service>をいじるとなるとページオブジェクトやコンポーネントなどのJavaで書かれるパーツは全部丸ごとHiveMindに行くかな？うえやんさんの予想の延長で、いま私が困ってるIPageLoaderやIBeanProviderなどせっかくインターフェイスで受けているのにハードコードで生成していたり、エンジンのファクトリメソッドで作ってるものなど全てがHiveMindに行ってくれたら、そのコンテナとTapestryとの密着具合によっては丸ごとごっそりS2Containerでもいけるかもしれないし、Seasar2プラグイン群をHiveMindに載せるほうが合理的かもしれない。このへん、まったく3.1のロードマップでしかなく、今は3.0の正式リリースも終わってないのと、3.1というバージョン何時？（来年？）ということもありますが、たぶん時流も考えて、コミッター達は（IoCコンテナである）HiveMindをいれたいんでしょう、きっと。MLの風速が速いのであまり見ていなかったのですが、ちょっとこの辺はウォッチしておいてTapestryとHiveMindを密結合しないように要望するかな。Seasar2をTapestryと使いたいのはまだ少数でも、JBoss-AOPとかSpringFrameworkとかすでに有力なのがいろいろあるから、HiveMindだけではもっていかないと思うのですけどね〜。HiveMindがJakarta Commonsになったから、密結合でいっちゃうのかな？
また、うえやんさんの予想をさらに過激にすると、

public class BasePage extends AbstractPage {
  public abstract IMarkupWriter getWriter();
}

ですね。Type3的なアプローチは、ページオブジェクトの構成要素が多いので無いかな？