I copy/pasted your comment to jira ticket and added my comment to it.
Howard Lewis Ship schrieb:
Have you thought through the implications of exposing the file system?
Seems like you would need some configuration to support a root
directory (which you wouldn't want to be "/").
I think, after that, it would tend to follow the lead of the
ContextAssetFactory and the related AssetDispatcher code.
Perhaps there needs to be some refactoring there, to make it easier to
subdivide the /asset virtual folder.
Originally /asset was for classpath assets only. Now I've added
/asset/ctx to context assets.
You will want to assign a virtual pass and a version number, thus:
/asset/fs/1.0/foo/bar.gif should map to <root>/foo/bar.gif.
As with context assets, we should be assigning far-future expires
headers, and supporting gzip.
Do we need to support multiple roots? i.e.
/asset/fs/root1/1.0/foo/bar.gif ... root1 would be mapped to a folder
on the file system, but configuration could map root2 to somewhere
else on the file system entirely.
On Mon, Feb 9, 2009 at 4:20 PM, manuel aldana <[email protected]> wrote:
Hi Howard,
would like to patch this issue, if you're not working on it:
https://issues.apache.org/jira/browse/TAP5-423
What do you think about the implementation approach to differ between asset
types through asset-prefix (e.g. asset-classpath, asset-filesystem). I
couldn't think of a better way...
After providing filesystem asset, asset types could even be extended
(database assets, static-resource servers). Especially getting static
content from special static-content servers is a very common use case for
bigger sites.
--
manuel aldana
[email protected]
software-engineering blog: http://www.aldana-online.de
--
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]
