Allen Gilliland wrote: > > > Elias Torres wrote: >> I'm trying to implement an internal feature at the moment on new entry >> UI that lets you upload pictures and insert them onto Xhina w/o having >> to leave the screen. As I figure out how to list the weblog resources I >> stumble upon this line of thinking and I'm interested in hearing your >> thoughts on it. > > would this thing be able to work in any editor? or only Xinha? seems > like it would be much nicer if it was able to work in other editors as > well. >
Absolutely. It would paste <img src="..."/> on a text-only editor, etc. > >> >> I found a bug in the FORM action for the create sub-dir and wanted to >> fix it in the RC3, but I was not aware we were not doing subfolders at >> all before (is this correct?) If so, maybe we should think more about >> the design of the WeblogResource interface a bit more. > > correct. up until now file uploads have been just flat storage, so no > subdirectories. good. > > >> >> 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. > >> >> 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. 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. > > 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 >
