[Zope-CMF] folder_factories length

[seb bacon]

* Chris Withers <chrisw@nipltd.com> [010605 00:45]:
> > I'm munging HTML out of Word and Excel documents.  The only way I can
> > support this file type specific behaviour is by creating a Word Type
> > and and Excel Type (both based on File).
> 
> ...which is exactly as it should be. These are both new types of content
> with very differing implementations.

Yes, in terms of implementation they are and should be different
classes / Types.  I'm concerned about a usability issue, though.  In
Word, an image and an embedded excel chart are different objects with
different implementations, but to the user, they *should* be presented
as just Things You Can Do Stuff With.  M$ have tried to implement this
interface, but badly, with confusing results.

> > this won't be a problem; but they might be confused by the fact that
> > they have to treat what is to them a 'file' as one of several Types
> > listed.  Similarly, webDAV isn't always an option.
> 
> I dunno, people are pretty used to seeing different icons next to files on
> their desktops, and this is nothing wore than that ;-)

Hmm, I think your analogy is incorrect.  Icons are useful visual
clues as to the content of already created objects. We're discussing
creating the object in the first place.  In fact, 'Uploading' a file
is not really analogous to creating a new object, but more to copying an
object from one location to another.  What if each time you wanted to
copy a file in Explorer, you had to tell Windoze what program to open
it with?  This is an implementation detail which is hidden from the
user, and I think the 'File'/'WordDoc'/'ExcelDoc' types problem is
similar to this.

Another analogy is the 'Save file as...' issue.  Users just don't get
it at all, they just want to save the file and be done with it.  To
me, the current way of handling files is similar - something like
'Upload file as...'  That's completely unecessary complexity that
could easily be hidden, IMHO.

Finally, there is an issue of Type default fallbacks.  This is a minor
issue, and more of an example to illustrate what I mean about hiding
complexity.  

A WordDoc should try to create a CMF-friendly version, but it might fail
(e.g. Word XP non-compatibility?  A binary file with the wrong
extension?)  In this case, it'd be nice for the CMF to create a File
type and stuff it into the user's folder anyway.  If the user had
originally tried to upload a WordDoc but got a File, they'd be
confused. 

> 
> > So, yes, the functionality does already exit in the PUT_factory.
> > However,  I'd like the same as a PUT_factory, but for TTW uploads -
> > a POST_factory, I suppose.
> 
> Well, how about creating an 'Upload' form and stick it at the bottom of
> folder_contents?
> This could take anything and feed it to the PUT_factory :-)

Well exactly :-)  I think there should be an 'upload' form, and that
this would completely obviate the need for any 'File'-like objects.
 
> You did have a good point though:
> > my users will have to select the file
> > type they're adding from an increasingly lengthy folder factory list.
> 
> How are we going to deal with the length of this list growing to unusable
> proportions?

Well, isn't the above a solution?  ;-p

cheers,

seb