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 > > -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
