You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@roller.apache.org by Allen Gilliland <al...@sun.com> on 2006/10/03 21:54:56 UTC
adding a WeblogResource interface/impl
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();
public long getLastModified();
public long getLength();
public boolean isDirectory();
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
Re: adding a WeblogResource interface/impl
Posted by Matt Raible <mr...@gmail.com>.
I don't object to doing this, but Spring does have a Resource
interface you might be able to use.
http://www.springframework.org/docs/api/org/springframework/core/io/Resource.html
Matt
On 10/3/06, Allen Gilliland <al...@sun.com> 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();
> public long getLastModified();
> public long getLength();
> public boolean isDirectory();
> 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
>
>
Re: adding a WeblogResource interface/impl
Posted by Allen Gilliland <al...@sun.com>.
Elias Torres wrote:
>
> Allen Gilliland wrote:
>>
>> Elias Torres wrote:
>>> Allen Gilliland wrote:
>>>> Elias Torres wrote:
>>>>> No objections.
>>>>>
>>> [snip]
>>>>> 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.
>>> I do :). I would like to show an image browser in the editor UI for
>>> choosing images to insert into blog entries.
>> Sorry, did you put that comment in the wrong place? Are you saying "I
>> do" because you have an objection? Or are you saying "I do" because you
>> have a use for a getChildren() method?
>
> I put it in the wrong place. No objections. It was more I do have a use
> case for getChildren() in the very near future.
gotcha. I'll go ahead and add that in then.
-- Allen
>
> -Elias
>
>> -- Allen
>>
>>
>>> -Elias
>>>
>>>>>> -- Allen
>>>>>>
>>>>>>
Re: adding a WeblogResource interface/impl
Posted by Elias Torres <el...@torrez.us>.
Allen Gilliland wrote:
>
>
> Elias Torres wrote:
>>
>> Allen Gilliland wrote:
>>>
>>> Elias Torres wrote:
>>>> No objections.
>>>>
>> [snip]
>>>> 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.
>>
>> I do :). I would like to show an image browser in the editor UI for
>> choosing images to insert into blog entries.
>
> Sorry, did you put that comment in the wrong place? Are you saying "I
> do" because you have an objection? Or are you saying "I do" because you
> have a use for a getChildren() method?
I put it in the wrong place. No objections. It was more I do have a use
case for getChildren() in the very near future.
-Elias
>
> -- Allen
>
>
>>
>> -Elias
>>
>>>>> -- Allen
>>>>>
>>>>>
>
Re: adding a WeblogResource interface/impl
Posted by Allen Gilliland <al...@sun.com>.
Elias Torres wrote:
>
> Allen Gilliland wrote:
>>
>> Elias Torres wrote:
>>> No objections.
>>>
> [snip]
>>> 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.
>
> I do :). I would like to show an image browser in the editor UI for
> choosing images to insert into blog entries.
Sorry, did you put that comment in the wrong place? Are you saying "I
do" because you have an objection? Or are you saying "I do" because you
have a use for a getChildren() method?
-- Allen
>
> -Elias
>
>>>> -- Allen
>>>>
>>>>
Re: adding a WeblogResource interface/impl
Posted by Elias Torres <el...@torrez.us>.
Allen Gilliland wrote:
>
>
> Elias Torres wrote:
>> No objections.
>>
[snip]
>>
>> 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.
I do :). I would like to show an image browser in the editor UI for
choosing images to insert into blog entries.
-Elias
>>>
>>> -- Allen
>>>
>>>
>
Re: adding a WeblogResource interface/impl
Posted by Allen Gilliland <al...@sun.com>.
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
>>
>>
Re: adding a WeblogResource interface/impl
Posted by Elias Torres <el...@torrez.us>.
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?
> 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()
> 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
>
>