RE: [Zope] Zope to plain html
Karl wrote:
Hmm, but isn't the big problem with all of this that zope doesn't use your standard .html, .gif, etc. extensions for it's URL's.
Sure, Zope can use these. Just name your objects index.html, logo.gif, etc.
This is something kind of bothers me a bit. Suppose I have a site and I want to move it to Zope to make it easier to manage. But I have a lot of people who visit my site and may have bookmarked various pages. I don't want my URL's to break because that means lost eyeballs, and depending on what I'm doing, lost business. Now I understand I can make zope respond to things like /index.html or /News/hello.gif, but doesn't this require some tricks. I mean, names like file.html isn't "the zope way", is it? So to use things like "wget" or curl or something like that, I need to do some pretty careful planning before I get started.
Hmm, that's a good point. I personally like thinking about a "logo" without embedding in its ID that it is a JPG. What happens if I decide to switch to a GIF or PNG? Why should I have to embed in the object ID the information about how to view it? The "web object model" transmits type information as metadata, not in the name of the object! Reason number 57 why objects are better than files, I suppose. But you're right -- people that want to export to a filesystem had better go lowest common denominator and be prepared for the silliness of filesystems.
Am I right, or is my zope newbie status simply out of control here <g>.
Nope, your right, except that there isn't anything in Zope that prevents putting "file extensions" in object IDs. Notice the distributions you downloaded when you installed Zope? Those ended in .tgz, .exe, etc. And they are Zope objects stored in the Zope database... --Paul
This is something kind of bothers me a bit. Suppose I have a site and I want to move it to Zope to make it easier to manage. But I have a lot of people who visit my site and may have bookmarked various pages. I don't want my URL's to break because that means lost eyeballs, and depending on what I'm doing, lost business. Now I understand I can make zope respond to things like /index.html or /News/hello.gif, but doesn't this require some tricks. I mean, names like file.html isn't "the zope way", is it? So to use things like "wget" or curl or something like that, I need to do some pretty careful planning before I get started.
Hmm, that's a good point. I personally like thinking about a "logo" without embedding in its ID that it is a JPG. What happens if I decide to switch to a GIF or PNG? Why should I have to embed in the object ID the information about how to view it? The "web object model" transmits type information as metadata, not in the name of the object!
Ahh, now that's a good way of putting it. Yes, sending stuff as metadata is helpful, as long as you've got the tools to interpret that. I'd never really thought if it that way, but now that you describe it as such, I understand the zope philosophy a little better. Maybe a good point for the ZDP FAQ.
Reason number 57 why objects are better than files, I suppose. But you're right -- people that want to export to a filesystem had better go lowest common denominator and be prepared for the silliness of filesystems.
I can think of a few cases where this would be useful. We've already mentioned the main one, where you want to use Zope to manage all your content but for some reason you can't or won't publish it all in Zope and need a static dump (maybe your boss only let you choose Zope if you made sure there's a parachute of sorts). A likely scenario is publishing files you expect people to download to their hard drive. Like a gallery of wallpaper images, software updates, or PDF files. I guess the moral of the story is to sit down and think things through because their may be some places where file extensions are useful if not critical. _______________________________________________________________ karl fast fast@lights.com
participants (2)
-
Karl Fast -
Paul Everitt