Elias Torres wrote:
No objections.
Allen Gilliland wrote:
After doing a bit of work on the FileManager as part of my Theme
Encapsulation proposal I have come to a point where I am thinking I
would like to add in a new WeblogResource class/interface to serve as a
layer of abstraction between an uploaded resource as used by Roller and
the physical way that resource is managed by the FileManager.
Right now the FileManager simply returns java.io.File objects which
represent the resource as it lives on the filesystem, and I think that's
not particularly ideal. There are a couple of reasons to change that
such that the FileManager returns a more abstract notion of a
WeblogResource.
1. security and proper abstraction through layers. Ideally the
presentation layer should not need to know or have access to the details
of how a resource is being stored on the filesystem. Returning
java.io.File objects gives more information than is needed.
2. there are some things that we may want to associate with a resource
that we can't do with a java.io.File object. for example, i want to
have a method which returns the relative path to a resource inside the
weblog's uploads area. it would also make sense if a WeblogResource had
a reference to the Weblog it's part of and also possibly has a method to
access the URL to the resource.
So this is what I've defined ...
public interface WeblogResource {
public WebsiteData getWeblog();
public String getName();
public String getPath();
Is this the relative "URL" path from the weblog handle?
Yes-ish, it's not from the weblog handle, it's from the weblog's uploads
area. In many ways that's really the same thing though. So the path
"images/foo.jpg" would mean ...
$roller_upload_dir/<weblogHandle>/images/foo.jpg
$roller_base_url/<weblogHandle>/resource/images/foo.jpg
the only difference is the path prepended to that relative path, which
in one case is a filesystem path used only by the FileManagerImpl, and
the other is the url path. But you can always get a resource and its
url given a weblog handle and the relative path to the resource within
that weblog.
public long getLastModified();
public long getLength();
public boolean isDirectory();
If we are defining a resource that is a directory, do we need a way to
traverse the directory? i.e. getChildren()
possibly, but we don't have a need for it yet, which is why i left it
out. right now we don't have any operations which actually traverse the
whole tree, so nothing would be using that method.
-- Allen
public boolean isFile();
public String getURL(boolean absolute);
public InputStream getInputStream();
}
anyone have any objections to doing this? The only class which produces
these objects will be the FileManager by calling it's getFile() or
getFiles() methods.
-- Allen
