Hi everybody, Here is a start. I just randomly browsed the mailing list and created a completely uncategorized set of questions and answers for the FAQ. I even snuck in a question of myself, see if you can answer it. :) If you see a problem with some of these questions or answers, send a followup with suggested corrections to the list and I'll include them in the FAQ. If you have more question/answer pairs, go ahead and followup too. I prefer these things to appear in the list (in a thread, and marked by [ZDP]) for now, as this might stop people from writing the same FAQs twice. I hope in a while we'll get somekind of collaborative FAQ environment going that makes all this easier. I'd prefer additions to the FAQ in StructuredText for now. See what follows for an example of the format I have in mind. If you think another format works better feel free to convert. (yes, that's the theme of open source; if you want something done differently, feel free to do the work to change it :). Here's what I have so far, enjoy! * How do I return an image from an External Method? Example (for a png image):: def foo(self, RESPONSE): # set the header RESPONSE['content-type'] = 'image/png' # return the actual image data return mkimage() Another way to set the header information is:: RESPONSE.setHeader('content-type','image/png') * How can an External Method refer to the objects in the Zope app? Use an External Method that gets passed 'self'. 'self' is your hook into Zope world. From 'self' you should be able to get anywhere you'd like to go. 'self' is the folder in which the external method is called. External Methods are methods of Folders. Since External Methods are acquired, self is not always the same Folder in which the method is defined--it may be a child Folder. * Is there any way for External Methods to access files on the filesystem of the server? An External Method can access anything on the server computer that the Zope process has access to. Therefore, an External Method can do just about anything a Python program can do. This is both a power and a liability. * Can I restrict what an External Method can do? Is there somekind of sandbox environment for External Methods? Right now there is no sandbox execution environment for External Methods. An External Method has access to everything that the Zope process has access to. This is one of the reasons why External Methods are required to be defined in the Extensions directory--it's easier to keep an eye on them there. * How do I call an external method from DTML? Use: <!--#var "external_method_name(arguments)"--> to call any External Method in the folder (or acquired by the folder). The more explicit alternative is: <!--#var expr="external_method_name(arguments)"--> The rule is that anything between double quotes in the first argument of the #var tag is interpreted as an expression attribute; a first argument without quotes is interpreted as a name attribute. * Why does StructuredText have trouble rendering the '#var' tags in the FAQ? Why do you use the HTML & escape codes in the FAQ when they don't work well either? I suspect there is some interaction between StructuredText and DTML that causes '#var' tags to be interpreted even when in a StructuredText code block (indicated by '::' or single quotes). I don't know any workaround right now, so I leave in ugly escape codes to encourage suggestions. :) * In a DTML expression, how do I access variable names with a '-' in them? (such as 'sequence-item') Any variable name (including those with '-') can be accessed in the '_' namespace. This contains a dictionary of all variables in the default namespace. To access 'sequence-item' you therefore use:: _['sequence-item'] * How do you safely do a backup of the Zope database? ('data.bbb' in the 'var' directory) In Zope 1.10 and later, you can simply back up the data.bbb. Because of the way the file written (all write operations are appends), it is highly unlikely for a backup file created directly to have a problem. If the database is being written while the file is being copied, then the Zope may discard the last transaction when reading the copy, if the last record is incomplete. Alternatively, you could export the entire site and backup the export file. This won't be a full backup however, as it won't contain old revisions of objects. Yet another alternative is to (mis)use the Pack operation (in the Zope Control Panel, database management). Pack will create a Data.bbb.old backup copy of your file before packing (for safety), which you could then back up. To exploit this side effect you could do a pack that says something ridiculous (like pack anything older than thousand days).
My two cents on the tree tag: * How do I tell the tree tag to show only Folders? By using the objectValues function in the branches_expr attribute of the tree tag. The objectValues function of a folder returns all objects contained by that folder. You can however, specify a list of object metatypes that it should return. objectValues(['DTML Document']) will only return all DTML Document objects in a Folder. Other metatypes you could select on are: Folder, DTML Method, File, Image, Mail Host, User Folder and Session. This is not a complete list, as Products can and will define their own metatypes. If you want to show more types, just add them to the list, like objValues(['Image', 'File']). Example of a Folder tree (with links to them):: <!--#tree branches_expr="objectValues(['Folder'])"--> <A HREF="<!--#var URL1-->/<!--#var id-->"> <!--#var title_or_id--> </A> <!--#/tree--> * How can I collapse or expand a tree using a URL? The tree tag will show a tree fully expanded when the 'expand_all' variable is present in its namespace. So when a URL, showing a tree, is called with ?expand_all=1, the tree tag will expand all it's branches. Collapsing can be achieved with collapse_all. The following example shows a tree with collapse and expand 'buttons':: <A HREF="<!--#var URL0-->?expand_all=1"> Expand all</A>| <A HREF="<!--#var URL0-->?collapse_all=1"> Collapse all</A> <!--#tree--><!--#var id--><!--#/tree--> * How can I limit a tree to showing only *one* branch at a time? Use the 'single' attribute for your tree, like in:: <!--#tree single--><!--#var id--><!--#/tree--> More cents will follow. Martijn -- M.J. Pieters, Web Developer | Antraciet http://www.antraciet.nl | Tel: +31-35-6254545 Fax: +31-35-6254555 | mailto:mj@antraciet.nl http://www.antraciet.nl/~mj | PGP: http://wwwkeys.nl.pgp.net:11371/pks/lookup?op=get&search=0xA8A32149 ------------------------------------------
Here is a start.
Great start! Could I suggest that there be FAQs for different catagories? My list would include: DTML external methods Win32 (maybe there are specific issues, if so I don't want to read about them :) SQL methods patches/hacks to Zope I am sure that I can find lots of work for you! Phil A ------------------------------------------ Philip Aylesworth zopelist@regalint.com Regal International
On Wed, Mar 03, 1999 at 11:44:20AM -0500, Philip Aylesworth wrote: ,----- | >Here is a start. | | Great start! | | Could I suggest that there be FAQs for different catagories? This is a good idea. I can see this FAQ growing very, very quickly. So, I would suggest that we start thinking about a hierarchy already... a couple suggestions below: | | My list would include: | Installation * building * win32 * freeBSD * etc. * server configuration * zap * apache * ZServer | DTML | external methods | Win32 (maybe there are specific issues, if so I don't want to read about | them :) I'm not sure if there will be many platform specific issues after installation... | SQL methods | patches/hacks to Zope | | I am sure that I can find lots of work for you! | | Phil A | | ------------------------------------------ | Philip Aylesworth zopelist@regalint.com | Regal International | | | | _______________________________________________ | Zope maillist - Zope@zope.org | http://www.zope.org/mailman/listinfo/zope `----- -- Kevin Dangoor kid@ans.net / 734-214-7349
Maybe by splitting up the FAQs we could split up the work, too! Have a different person/group resposible for each FAQ. Of course there would be nothing stopping some energetic type being involved with all of them :) Also, I think that HOWTOs of the Linux type would be a great idea. They have a person/group responsible for each HOWTO to keep it up to date and add/edit things as needed. I am just commenting from the sidelines. Right now I barely have time to scan through the zope-list! Phil A ------------------------------------------ Philip Aylesworth zopelist@regalint.com Regal International
On Wed, Mar 03, 1999 at 01:00:03PM -0500, Philip Aylesworth wrote:
Maybe by splitting up the FAQs we could split up the work, too! Have a different person/group resposible for each FAQ.
Well, I think it'd be nice if there was someone "responsible" for each major section, this would keep everyone from getting swamped.
Of course there would be nothing stopping some energetic type being involved with all of them :)
:-) I for one have no problem causing trouble in everyone's life!
Also, I think that HOWTOs of the Linux type would be a great idea. They have a person/group responsible for each HOWTO to keep it up to date and add/edit things as needed.
You can find a "howto" LaTeX stylesheet in the Python CVS checkout, and I'm sure Guido/Fred wouldn't mind us using this. It works real well, and can target HTML, ASCII (I think), Postscript, PDF, etc... this lets you do the "bigger" stuff in a nice pretty way. What would also be nice is a list of "bigger" issues that people would liek to see explained more... something that's more than a single question. Chris -- | Christopher Petrilli ``Television is bubble-gum for | petrilli@amber.org the mind.''-Frank Lloyd Wright
"Christopher G. Petrilli" wrote:
On Wed, Mar 03, 1999 at 01:00:03PM -0500, Philip Aylesworth wrote:
Maybe by splitting up the FAQs we could split up the work, too! Have a different person/group resposible for each FAQ.
Well, I think it'd be nice if there was someone "responsible" for each major section, this would keep everyone from getting swamped.
Yes, this would be a good idea. My first priority however is to get as much of a FAQ as possible out there. Organization we'll do at the same time. Otherwise we run the risk getting bogged down in organizing who does what. That said, volunteers who want to manage specific sections of the FAQ are very welcome to step forward. Procedure is as follows: you get to name your topic; the first person who names a particular topic and produces a FAQ for it (assembling it from the FAQ we have now, and hopefully adding more of his or her own to it) will be manager for that section, unless that person doesn't want to, of course. :) I suggest to mail this list instead of me personally, so that other people can respond friday and during the weekend, when I won't be around to check the mail. We're working on getting a zdp@zope.org mailing list too, but I can't say yet when that'll be ready. [snip] ]
Also, I think that HOWTOs of the Linux type would be a great idea. They have a person/group responsible for each HOWTO to keep it up to date and add/edit things as needed.
Aren't there some HOWTOs out there already on the Zope site? (there are FAQs too but that doesn't stop us of course). HOWTOs and FAQs of course have some overlap; we'll just see how it evolves.
You can find a "howto" LaTeX stylesheet in the Python CVS checkout, and I'm sure Guido/Fred wouldn't mind us using this. It works real well, and can target HTML, ASCII (I think), Postscript, PDF, etc... this lets you do the "bigger" stuff in a nice pretty way.
Earlier I suggested using SGML Docbook for this purpose; I've appointed John Eikenberry (without any feedback from him :) as our official SGML docbook expert. One advantage of Docbook SGML is that it's the new Linux standard for writing documentation.
What would also be nice is a list of "bigger" issues that people would liek to see explained more... something that's more than a single question.
I think essentially a HOWTO is a particular frequently asked question with a very long answer. :) Regards, Martijn
Kevin Dangoor wrote:
On Wed, Mar 03, 1999 at 11:44:20AM -0500, Philip Aylesworth wrote:
Here is a start.
Great start!
Could I suggest that there be FAQs for different catagories?
This is a good idea. I can see this FAQ growing very, very quickly. So, I would suggest that we start thinking about a hierarchy already... [snip proposed hierarchies]
Yup, splitting up the FAQ into different categories appears to be pretty needed, so this is a good idea. My idea is to 'involunteer' you category maker guys to take the assembled FAQ that I'll produce hopefully today (in a few hours), and put each question in the category you feel it belongs to. This way I have to do less work and thinking. :) Realizes-he-is-talking-to-two-people-so-you-can-always-say-I-thought-the-other-guy-would-do-itly yours, (wow, a long one :) Martijn
Hello! I am new to Zope, and i want to clarify some problems. On Wed, 3 Mar 1999, Martijn Faassen wrote:
* How do I call an external method from DTML?
As far as I understand there are DTML objects (templates), Products and External methods. There is no such thing as "Internal" methods (objects, that live in Zope's object database). Are these 3 the only 3 kinds of executable (callable) things? Oleg. ---- Oleg Broytmann National Research Surgery Centre http://sun.med.ru/~phd/ Programmers don't die, they just GOSUB without RETURN.
Oleg Broytmann wrote:
Hello!
I am new to Zope, and i want to clarify some problems.
On Wed, 3 Mar 1999, Martijn Faassen wrote:
* How do I call an external method from DTML?
As far as I understand there are DTML objects (templates), Products and External methods. There is no such thing as "Internal" methods (objects, that live in Zope's object database). Are these 3 the only 3 kinds of executable (callable) things?
Hm, DTML methods can be called as well, naturally, that's why they're called methods. They're called through URL. The DTML method then is executed. This means executing any DTML in it and returning the resulting HTML to the caller. One way of 'calling' a DTML method is by using it in a form action, like this: <form action="your_dtml_method" method="POST"> (or method="GET", of course) This does go through the browser, but it feels like you're calling 'your_dtml_method' when the user presses the submit button. This is another way of 'calling' a DTML method: <!--#var your_dtml_method--> I'm sure there are more ways, and I'm a bit vague about this, so I'll leave it up to other people to turn this into a nice FAQ. :) Regards, Martijn
participants (6)
-
Christopher G. Petrilli -
Kevin Dangoor -
Martijn Faassen -
Martijn Pieters -
Oleg Broytmann -
Philip Aylesworth