Great feedback. As a newbie to development, not just Zope, your comments are appreciated. (and refreshing) I do have some follow-up curiosity Q's.
- Do some things just the way you would with any old server. I still use /images/ for a place to put all my images and still reference them in html. I still name pages ".html", keep everything lowercase and use names for folders that make sense. I have wondered if this makes the best sense with the world being .html oriented. Is this really a usability issue? everything with zope looks like it is coming from a folder, which eliminates the need from users to remember .asp,.htm,.htm,.cfm But doesnt this look confusing if you apply a method to an object(zClass) and get zope/folder/adocument.html/amethod.html?? or can you avoid this? Do you have other reasons for this?
I havent implemented "keep everything lowercase", which HAS caused usability problems when users try to go to a case sensitive page directly. Can mod_rewrite fix this by trying to find all lower or upper case iterations of an URL? An experienced developer that helps me couldnt figure this out.
- Spend extra time learning Zope security. If you don't it will bite you in the end (your end). okay. like I said, I am new to this. briefly, what are the security issues with zope, and what is the easiest way for someone to break your Zope maliciously? Any examples you could share?
Thanks, -Trevor
-----Original Message----- From: zope-admin@zope.org [mailto:zope-admin@zope.org]On Behalf Of BZ Sent: Wednesday, September 19, 2001 11:07 PM To: Joel Burton; zope@zope.org Subject: Re: [Zope] *Designing* Zope sites
Ok... so I will step up to the bat.... with what I have learned (and throw it into a how-to on Zope.org)
After building, maintaining and rebuilding over 10 sites with Zope of all different varieties here is some of what I have learned (in a pea pod shell)
- Get to know and love standard_html_header and standard_html_footer they will make your life much easier if you can decide what stuff to put in them and what stuff to leave out. Navigation is good, site table templates are good. Anything that is page specific is not so good.
- Do some things just the way you would with any old server. I still use /images/ for a place to put all my images and still reference them in html. I still name pages ".html", keep everything lowercase and use names for folders that make sense.
- I find that hosting more sites out of one Zope installation, leaving some dependencies on products is a much better way to go and much easier to maintain in the end.
- Use versions. They are easy, fun and powerful. You can play with a live site to your hearts content without ever breaking it.
- Use Zope products with a little caution. There are a ton of products that do a lot of things but not all of them are still supported nor have been tested with the newer releases of Zope. Look at date of the last distribution to see when they updated it. Also, if it is says beta, know that it probably is for a reason. Email the developer and ask.
- Spend extra time learning Zope security. If you don't it will bite you in the end (your end).
-
At 11:17 AM -0500 3/7/01, Joel Burton wrote:
I've been learning about the workings of Zope: ZClasses, ZSQL methods, Python products, etc., and there are *lots* of resources about the APIs, and lots of products to add content to our sites.
There is also lots of help on how to *set up* a Zope site: how to tie w/Apache, etc.
What I haven't found yet, though, is much advice on how to *design* the Zope site:
. effective ways to use User Folders
. whether to make containing folders for like objects (eg book reviews), and collect these for lists with objectValues, or whether to add them under user folders/different contexts, and use ZCatalog searches to find them.
. how to handle printable pages throughout a site
. strategies for using ZSQL methods throughout a site
and so on
The Zope book tosses some nuggets of advice here and there, but doesn't build up a site, so we don't really get to see the workings of a talented Zope architect. Other documentation focuses on how to Do Things, like use SQL methods, or how to build products.
I've had a little bit of time to look at the CMF, and that has some structure about reviewing, etc. (and seems to advocate the 'place things in user folders, use ZCatalog to find' method); however, I'm not designing something that seems so portal-ish, and this seems like a hegemonic solution to a design question.
So:
Am I missing any resources on fitting it all together?
Are there 'example sites' that someone could describe?
Would anyone with a well-designed site be willing to export it all up and post it somewhere, so we could explore it?
Or are there other ways of starting this learning path?
-- Joel Burton <jburton@scw.org> Director of Information Systems, Support Center of Washington
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )