BEAR.SundayのPageリソースとAppリソース

BEAR.SundayにはPageリソースとAppリソースがあります。

作者であるkoriymさんのなぜ PageリソースとAppリソースがあるのかという記事が大変参考になります。

リソースオブジェクトであることに違いはないので、Appリソースであっても出力が可能です。

例えば、PageリソースからAppリソースをEmbedして文字列化するケースです。

php

class Index extends ResourceObject
  {  
    #[Embed(rel: 'AwesomeResoure', src: 'app://self/awesome-resource')]
    public function onGet(): static
    {
        return $this;
    }
}

php

class AwesomeResoure extends ResourceObject
  {  
    public function onGet(): static
    {
        $this->body = 'Awesome Resource';
        
        return $this;
    }
}

テンプレートエンジンで文字列に

qiq

 {{= $this->AwesomeResoure }}   

qiq

<p>
    Awosome Resource HTML.
</p>

しかし、これは少し混乱を招くかもしれません。
リソースがUIを持つ場合は、Pageリソースを作成するほうが良さそうです。

現在ではセルフリンクの機能があるため、以下のように記述できます。

AppリソースをEmbedするだけのPageリソースです。

php

class AwesomeResoure extends ResourceObject
  {  
    #[Embed(rel: '_self', src: 'app://self/awesome-resource')]
    public function onGet(): static
    {
        return $this;
    }
}

単にリソースが2倍に増えているだけに感じるかもしれませんが、こうすることで2層のリソースの役割が明確になりそうです。

しかし本当にそうでしょうか？

前述の記事にある通り、標準では

Pageリソースは公開されていますが、Appリソースは公開されていません。

上記のような方法を取ってしまうと、

• UIをもち出力されうるリソースはすべてPageリソースにした方がいいのか？
• 公開される必要のないリソース（ページの一部分など）も公開されてしまうのでは？
• 最終的な出力形式を考えた上でリソースの配置やEmbedをする必要があるのでは？
• それこそ境界がなくなるのでは？

そのためUIを持つかどうかではなく、（ユーザーへの）公開リソース・そうでないリソースと理解するほうが良さそうです。

もしくは、（公開されるため）ユーザーが直接アクセスするリソースか、アプリケーションのみが直接アクセスするリソースかという感じでしょうか？

どなたかの理解の助けになれば幸いです。