I see the asset thing twofold:
1) displaying the asset as a link inside the page response
2) retrieving the asset as resource itself (following the link)
at 1) the page gives an exception if the resource cannot be found. this
makes sense for classpath and context resources, because it is bundled
with the webapplication (it is part of the deployment).
if a filesystem resource cannot be found I would not throw an exception
at 1) but still include it as reference inside page. I would then wait
for 2) and then respond with 404. this way I don't break the whole page
and am decoupling the webapp from the filesystem resources when
rendering the page.
the same would hold true for complete external assets (e.g. dedicated
picture server). if I am using asset from this dedicated picture server
I want to have a 404 when retrieving it from the server and not already
when rendering the page containing this asset as link.
problem with this approach is that 'toUrl() returning null' is used
inside an iterating-logic to check whether localized resources exist.
and I would never make toUrl() return null, because I am not checking
for existent resources.
Howard Lewis Ship schrieb:
The Resource may be null, but the Asset.toClientURI() doesn't have to
be null. Make the FileSystemAsset to the right thing when the Resource
is null.
I actually don't follow you about misisng Resources on the file
system. Why is this any different than files in the context? You
might create a Resource (often, from another Resource) speculatively,
and use exists() or toUrl() to determine if a file actually exists.
On Fri, Apr 3, 2009 at 4:58 PM, manuel aldana <[email protected]> wrote:
hi,
i am implementing a 'FilesystemResource extends AbstractResource' for a
tap-jira ticket.
the contract for toUrl() says:
return URL or null, if resource does not exist.
this contract is fine for application bundled assets (context+classpath),
but in my view not for outside-application maintained artifacts (like
filesystem files). non-existent files in filesystem should not break the
page but rather return a 404 when it is accessed from the browser. further
more deploying filesystem artifacts and webapp are often distinct steps and
should therefore be decoupled.
but breaking this toUrl() contract would also break automatic failover if
localized assets don't exist (the failover to non-localized asset is using
the null-return information). maybe we can change the asset-localization
failover and make it explicit inside module-configuration (enable/disable
asset localization).
we will come across the same problem when providing an URL alias asset
(which could point to a CDN).
what do you think?
--
manuel aldana
[email protected]
software-engineering blog: http://www.aldana-online.de
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
manuel aldana
[email protected]
software-engineering blog: http://www.aldana-online.de
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
