ExcelBaseParticipantProviderを試す(2)

buri

makotan
『>typeでnameを省略
convertのnameを書いてるとかそういうことはありません？
test03.xlsがnameを省略したサンプルなんですけど・・・』

convertのnameは削除してありました。


で、今日いろいろ試してみて、nameのあり/なしによる振る舞いの違いがだいたいつかめました。
convertのnameの有無がキーになっているようですね。

  • convertにnameの設定があれば、type部分でnameを拾う。
  • convertにnameの設定がなければ、type部分でnameを無視する(=null)。


まあそれはともかくとして原因がわかりました。

nameありの場合、BuriExcelPrtiPrvidrRootDtoには"1/ユーザA", "2/ユーザB"などの文字列をキーとして、BuriExcelPrtiPrvidrItemDtoを取得するわけです。このインスタンスの中にはロール名(Participant名)が入っていて、それが現在必要としているロール名(Participant名)と一致するかどうかでhasAuthority()の結果が決まります。

nameなしの場合、BuriExcelPrtiPrvidrRootDtoのキーとしては"1/", "2/"のようにユーザID(文字列)の部分が空文字扱いになっています。
しかし、探索条件として使う方のキー文字列が

public class BuriExcelPrtiPrvidrItemDto {
〜(省略)〜
    public String getItemKey() {
        return id + "/" + name;
    }
〜(省略)〜

を利用して生成されるために、nameがnullの場合は、itemKeyが"1/null"のようになってしまいます。
キーが一致しないのでBuriExcelPrtiPrvidrItemDtoが取得できずに、hasAuthority()が必ずfalseになってしまったわけです。

とりあえず、以下のように修正して動作することを確認しました。

修正版:

public class BuriExcelPrtiPrvidrItemDto {
〜(省略)〜
    public String getItemKey() {
        return ((id == null) ? "" : id) + "/" + ((name == null) ? "" : name);
    }
〜(省略)〜

考え方と対処方法に問題がなければ、ユニットテストを追加して上記の修正を反映する予定です。
＃実はhasAuthority()メソッドに関するテストだけがありませんでした。。
＃他の3つのメソッドはテストされてるんですけどね。


念のため確認ですが、上記と反対の対処である
『nameなしの場合、BuriExcelPrtiPrvidrRootDtoのキーを"1/null", "2/null"とする』
というのはナシでいいですよね？


さて、次は「getAuthorizedUserIds()」の動作に進みます。