No problem. It was just a suggestion and I can add the methods I need to make it work with the existing design. I was just wondering whether people thought it'd be a better design.
-Elias Allen Gilliland wrote: > > > 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 >
