Elias Torres wrote:
Allen Gilliland wrote:
Elias Torres wrote:
*snip*
The main thing I'm trying to do is avoid having a tree-like navigation
for a user to find a photo to insert into their entry. I'm toying with
the idea of "recursing" down via the FileManager to get all resources
and list them as in a photo-well approach (all photos in one view). I
know that this might be insane for large amount of files, but the
alternative is also rather painful to navigate back and forth between
folders until they find what they are looking.
Well, there are potential other ways of doing that if that's all you
need. Like we could provide a getAllFiles(weblog) which would provide
all files for the weblog, rather than just the ones from a single
directory and then force you to recurse through them.
Right. I was going to add that to the UploadPageModel but this could
potentially become a slow task. Instead I can just get the entries
within one bucket and let the user browse through those, then switch to
another bucket.
couldn't you do technically the same thing with directories? Just show
one directory at a time and maybe confine things to a base directory and
not go into 2nd level or lower directories?
Recently, I was playing with Amazon's S3 (simple storage service) and
their file system abstraction is done via buckets and entries. A user
can create n buckets and m files inside those buckets. If the user
decides to name their files "2006/10/me.jpg" then some API client could
recreate a folder structure for that given bucket. Maybe what I'm
suggesting is that we use this instead of the
isDirectory()/getChildren() approach and still have the current
filesystem listing in the Upload Files JSPs we have. Allen, is this a
bad idea/too much work/too late?
I don't understand the distinction, "buckets and entries" just sounds
like different words for "folders and files". How would this be
different than what we have now, aside from nomenclature. I suspect you
would still be allowing a bucket to contain any number of other buckets?
That's right. The difference is that there's no buckets within buckets
(i.e. no nested directories). S3 for example in its API call says what's
the max no of entries you would like to retrieve from a bucket. It's not
a HUGE difference, but I think it simplifies the design a bit.
Simplifies the design for who? In this particular situation I actually
think that a full hierarchy is useful and that users are quite
knowledgeable about how to manage files in directories.
A few advantages:
- If we do this we won't have to deal with a tree-structure navigation
to find resources.
- Atom Publishing Protocol would (maybe) be easier to implement using a
folder (bucket) + file approach instead of having to manage the hierarchy.
- Easier paging functionality since we just page through entries in
buckets as opposed to paging over getAllFiles().
- Easier to implement pluggable resource providers such as db-based
storage, S3-based stuff, Flickr images, etc.
- ... and of course, we can always shove hierarchical data by using '/'
in the names.
My hesitation here is that most of these sound like things that make it
easier on you, as a developer, but not necessarily easier on users.
I think that users are fully capable and comfortable managing files in a
directory structure. All filesystems work that way now and it seems to
be working out okay.
I can see that this may be easier on the atom protocol, but at the end
of the day I don't think we should design our features towards
protocols. If it's more useful for users to have a full hierarchy then
we should do that and figure out how to make the protocol work for what
our users want.
I don't understand the paging scenario. In what scenario are people
paging through files? I would assume that with a true hierarchy that
whenever there are enough files in a single "bucket" that people would
decide it's more fitting to create subdirs rather than do paging.
I'm not really sure this would make it any easier to make pluggable
resource providers. I think what we have now is simple enough and
abstract enough that it should work with most if not all potential
providers.
If we put '/' in the names to get hierarchical data then why not
actually have a functional hierarchy?
At the end of the day I'm not sure that I agree with the "buckets and
entries" system. I can see how it helps to think of files in this
manner in certain situations, like for the tool you are designing, but I
don't think that we should cut short a feature that our users seem to
want so that we can make it easier to design this tool. I think that
storing the files in a full hierarchy on the backend makes a lot of
sense and doesn't limit the potential for creating a tool like you suggest.
I am certainly willing to add some new ways to get at the data managed
by FileManager so that it's easier to do what you want. So like I said,
we could provide a getAllFiles(weblog, path) which would list all files
in a directory including subdirectories. That way your tool could be
designed to only know about the folders at the root of a weblogs uploads
area (kind of like buckets) and you could get all files under there.
Would that help?
-- Allen
It is a bit late, but I am not opposed to new suggestions. You are
going to have to elaborate on your idea though, because I don't fully
understand what you want to change from your current description.
I hope I was able to add some clarity to my suggestion.
-- Allen
-Elias
PS. I would like the user to pick out an image from an iframe listing of
pictures like this:
http://torrez.us/photolog/index.php?x=browse
