[
https://issues.apache.org/jira/browse/TAP5-423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12693762#action_12693762
]
Dan Adams commented on TAP5-423:
--------------------------------
I've implemented something very similar to this in our CMS projects: there is a
"fileasset" asset type which provides access to a filesystem-based store that
is also accessible via a URL. You can't tell where it is based on the URL, you
can only access files within that store so it's secure, and you can't tell
where the files are actually located / served from (eg could be on a CDN rather
or served through apache statically or something). By and large, this is has
been great however one problem I ran into was that requesting an Asset that
doesn't exist causes an exception but you may want to require a fileasset that
doesn't exist so that you can write to it. But that wasn't hard to work around.
This could be extended in the future without a lot of change to support
multiple roots or even multiple content stores (eg one root is on a CDN, one is
on a filesystem, and one is from a database) . It's a simple implementation
right now used by one project (so the API hasn't yet been put through the
paces) but I'd be willing to provide it if you'd like it.
> Implement a file-system Asset type
> ----------------------------------
>
> Key: TAP5-423
> URL: https://issues.apache.org/jira/browse/TAP5-423
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-core
> Affects Versions: 5.0.18
> Reporter: manuel aldana
>
> currenty it is built in to retrieve assets from classpath and from webcontext.
> a file system asset type which can retrieve stuff directly from the
> filesystem (e.g. from /srv/statics/xxxx) makes also sense.
> something like:
> *ResourceFileSystem extends AbstractResource* and *FileSystemAssetFactory
> extends AssetFactory*
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
