[Zope-CMF] folder_factories length

[Chris Withers]

> 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>

At this level, you just end up talking about objects, and there's not a lot
on you do on _every_ object, so you need to differentiate...

> 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?

Well, the first time you open a file with a given extension, you do ;-)
And the mapping that's built up by you doing this is exactly the type of
mapping a PUT_factory performs. The 'generic upload form' could do exactly
the same thing...

> 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.

Sorry, I don't follow this at all :-S

> 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.

Yup, the above makes sense, but isn't the following contractory?

> If the user had
> originally tried to upload a WordDoc but got a File, they'd be
> confused.

> > 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.

Hmmm, I think their should be an 'upload' form which "does the right thing"
with the files you upload there. You would still need a Type for each of the
file-types you wanted to store, otherwise you're contradicting what you said
in the first paragraph of one of your mails:

> Yes, in terms of implementation they are and should be different
> classes / Types.

> > How are we going to deal with the length of this list growing to
unusable
> > proportions?
>
> Well, isn't the above a solution?  ;-p

Can you explain how it is? I see how it helps with file-like objects, but
what about things like news items, portal polls, etc and what about when
you're not creating the object from a file?

cheers,

Chris