この質問で提案された問題と非常によく似た何かをしたいアプリに取り組んでいます：ビューベースのNSTableViewに行スパンを追加する方法は？
2番目の答えは賢い解決策として私を興味をそそりますが、2つのテーブルビューを互いに同期させる方法を理解できません。特に、アイテムテーブルビューの行が対応するグループの横に表示されることを確認する明確な方法がわかりません。私にとって最も明白な解決策は次のとおりです。
アイテムテーブルのデータソースをグループテーブルビューのデータソースに基づいています。したがって、グループデータソースの各オブジェクトには、それに属するアイテムのリストがあり、アイテムテーブルビューに行が必要になるたびに、グループを反復処理し、必要なアイテムが見つかるまで各グループのアイテムをカウントします。 。これはひどく非効率に聞こえます。
行が一致するように並べ替えられるように、アイテムにNSSortDescriptorsを巧妙に適用します。これは、決定論的に機能させることができれば幸運であるように、私には一種の魔法のように思えます。
処理中の現在のグループへのポインタを保持し、グループのアイテムがなくなるまでグループ内の次のアイテムを返し、次のグループに移動します。これは、順番に行を要求するテーブルビューに依存します。どこかに並行性や順序の乱れがあった場合も、このように思えます。
これらのソリューションにはすべて、かなり明らかな欠陥があります。ここで「トリック」を見逃しているような気がします。あるいは、目の前に立っている巨大な紫色の象だけかもしれません。:)
編集：rdelmarのコメントに応えて、いくつかの説明を追加します。私の特定のケースでは、グループ内のアイテムの数は可変です—一部のグループは2つ、他のグループは10個にすることができます。私が見つけたい解決策は、グループ内に固定数のアイテムがあることに依存するべきではありません。
選択動作に関しては、グループ内の各アイテムが選択可能である必要はおそらくありませんが、編集可能である必要があります。グループはおそらく全体として編集されます。つまり、ユーザーは「グループAを編集したい」と言うと、グループ内の任意のフィールドまたはそれに属するアイテムを編集できるようになります。テーブルビューの代わりにラベルを使用することはおそらく可能ですが、テーブルビューが無料で提供する多くの作業を複製する必要があるようです（グリッドにビューを配置するなど）。
これについて私が思いついた最初の解決策は、実際には、グループテーブルビューの各行内のアイテムのテーブルビューを埋め込むことでした。したがって、トップレベルのテーブルビューはグループのみで構成され、各グループには、アイテムを表示するための独自の埋め込みテーブルがあります。私は最終的に、より短いビューツリーを含むソリューションを見つけることを期待して、そのソリューションをあきらめました。