On Wednesday 07 August 2002 04:11 pm, Simon Michael wrote:
Hi Mark, thanks for your post.
Mark Bucciarelli <mark@easymailings.com> writes:
I didn't find it that hard to integrate zwiki into an otherwise totally zpt site. The hard part as far as moving to zpt is to pull all the layout code (dtml statements) from the python. For example, all the '<a href' stuff.
I'm not sure what you mean here. What did you do with zwiki, exactly ?
I put a zwiki example inside my site, with my site menu at the top. My entire site has the following functionality: if it's your first time visiting, you get a welcome and an opportunity to enter a nickname. If you use cookies, great--you see this page once. If you don't, you see this page once per session (yes, obnoxious, I know but I'm guessing most people allow cookies). (Actually, even if your browser allows cookies, you can opt not to take.) Anyway, if someone does not use cookie, or opts not to allow a cookie, I lose this session information once I get into the wiki. To fix this, I need to be able to append the _ZopeId to each link INSIDE the wiki. Since the links DTML is generated inside python scripts, I figured I would need to hack the python scripts to make this fix. I've got a work around, but it's not great. This issue is seperate from this thread--when bulding an url, the zwiki should look for a _ZopeId in the request. If it's there, and there's zwiki cookies, then append ?_ZopeId= to every link.
I think it would be better to have the python process a DTML document, and return some data structure (list or a dictionary) that the zpt template lays out.
Yes, I became a little clearer on this yesterday. Here's how I think zwiki could approach ZPTs (can I call them Page Templates, or are they Zope Presentation Templates ?):
Page Templates
1. allow the "forms" - editform, subscribeform & backlinks - to be defined as ZPTs. Would mean changing editform(), backlinks() & subscribeform().
Great! With the current zwiki, I could not style these consistent with the rest of my site, since they don't use the dtml header and footer. Major improvement, for me.
2. allow the main page layout to be defined as a ZPT ("standard_wiki_page", "page_layout", "mainview" ?). Would mean changing (or adding new) render_ methods. Currently they all render and pre/append the DTML methods to the rendered page content as their final step. Instead they would now render the ZPT, passing the rendered page data into it's namespace for inclusion (right ?).
Bear with me, I'm pretty new to Zope. Let me repeat back to you ... the way zwiki works is: you modified the render method of each zwiki page so that first it parses the page contents (building a href links, applying tags <H1>, <p>, <DTML>, etc.) and produces DTML. Then it prepends the header and appends the footer and returns one big DTML string. Zope then processes the DTML document and turns it into HTML. I think it would be a good idea to split the header, body, footer into three slots that the ZPT lays out. For the header, you could define a python structure that the tal or DTML lays out as they like. Something like {'last modified':'Zippy on today', 'history_tree': ({'name1': 'url'}, {'name2': 'sub_url'}, {'name3': 'sub_sub_url'}, ...} This approach would probably work with the footer as well. I can't figure out how to do a similar thing for the body, since it's so unstructured. Actually, I did think of a way: tal:define="body python:getWikiPage" tal:repeat="block body/blocks tal:condition="python:block.isParagraph()" tal:condition="python:block.isHeader1()" tal:condition="python:block.isHeader2()" tal:condition="python:block.isHeader3()" tal:condition="python:block.isHorizontalRule()" tal:repeat="token repeat/block/token tal:condition="python:token.isLink() blech--can you imagine designing a slower page? I'm not sure about your name space question (I'm kind of new to Zope). Could it work like this? When they click on a page, the render method calls the page layout ZPT, passing the page name in the URL. The ZPT fills three slots: header, body and footer, by calling three python scripts and passing the page name as an argument. Wiki is such a cool thing, I'm having a hard time thinking about how to seperate logic from presentation from content. For example, I don't see how it would be possible to write useful unit tests for the python part of the logic outside of zope. With the other product (NuxWidgets TimeTable) I've messed with, the seperation has been clear. I can just fire up python, import the code, and write my tests--no messing around with Zope.app(). Mark
At this stage,
- you should be able to fully control the wiki's appearance by editing these four ZPTs.
- ZWikiPage still inherits from DTML Document, and dtml-enabled wikis and pages such as zwikidotorg's default UserOptions, RecentChanges and SearchPage still execute embedded dtml.
- the ZPT provides an additional dynamic parsing stage for the page, where you can do site-wide, admin controlled stuff - sounds useful
3. implement UserOptions/RecentChanges/SearchPage in some other way than DTML, allowing you to purge DTML entirely from your wiki. For those who want that. :) (Personally, I want embedded restricted python).
4. make it so that each zwiki page is a ZPT. This should make it easier to edit a page with WYSIWYG tools. After an edit, zwiki would extract the essential body (eg strip the header & footer) for inclusion in the standard site ZPT.
-Simon
_______________________________________________ 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 )