I think it has more to do with the resource URL generation. The
ResourceReference registers itself with application (using the Scope
and name parameters). Then the application uses those information to
generate resource reference url and looks up the resource reference on
request.
While regular resources (without using resource reference) are bound
to the component so the component path is used to generate resource
URL.
I don't say current approach is the best one or most transparent, but
we need to have a way to generate unique URL for shared Resources (as
now we do with help of ResourceReference) and be able to lookup the
Resource instance on request.
-Matej
On 8/8/07, Kent Tong <[EMAIL PROTECTED]> wrote:
> Matej Knopp <matej.knopp <at> gmail.com> writes:
>
> > Yeah, ResourceReference is like global resource factory. That is for
> > resources that don't belong to any component/page (they can't touch
> > any component instance while they are served).
>
> However, I don't understand why we should not just use static class
> members like:
>
> class Foo {
> static Resource MY_JS = ...;
> }
>
> class Bar {
> void g() {
> Resource r = Foo.MY_JS;
> ...
> }
> }
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
