TheJester

This is the Channel Management product, for managing and displaying RDF and RSS news summaries found on many popular portals (including zope.org).

It is a two part product, consisting of a Channel Management product that must be installed, and the tag used for displaying channels.

Install a Channel Management product at the head of your document tree, it will install several channels by default, (which you can delete at your leisure).

There is a default method installed for display channels called showChannel. It is deliberately ugly so that you will change it d8) You can provide a default template by using showChannel, or you can customise individual channels by adding in a showChannel DTML Method underneath that particular channel (you can add images etc under here as well if you wish).

If you want to delete a channel, you can simply delete it using the standard management interface underneath the Channel Manager.

The <dtml-channel> tag takes one parameter show which is an expression. You can pass in a single Channel Id, or a LIST of Channel Ids, so you only display those channels you are interested it (or subscribed to if that's how you're using it to provide content to users).

The Channel Manager also provides a listChannels() method so you can iterate over the list of channels if you want and display them individually.

The Channel Manager allows you to set the number of items displayed for each Channel, 0 means display all the items returned by the remote site. This can get noisy for some sites, so you can set this to 5 or 10 or whatever for a more compact display.

This product is based on the slashbox code, and requires xmllib and sax et. al. to be installed.

The PollTag is a two part product, that consists of a tag (for rendering) and an Poll Administrator that manages the Polls and the questions.

You must add an Poll Administrator product somewhere in your tree. You should add some questions at this point to test things out.

Get comfortable with the administration features of the poll.

Find your favourite DTML Method or Document and insert in it to see the currently active poll.

When voting you will be returned to the current page and the selection made will be hilighted.

At the moment I seem to have porked multiple-vote checking so people currently can vote their hearts out.

This is my first cut at building a Product Manager for Zope.

It is by no means complete, but, it is functional, it will definitely have bugs.

ONLY USE WITH A SCRATCH ZOPE INSTALL OR FROM AN INSTALL YOU'RE HAPPY TO RESTORE FROM BACKUP TAPES.

YOU HAVE BEEN WARNED

There are two modes of operation, only one of which is currently implemented.

Concrete Mode: This is where the package meta-data is inserted into an archive with the package. The package can then be directly imported by the Product Manager.

Virtual Mode: This is where a list of download sites for the data is supplied, and the Product Manager fetches the archive and unpacks it itself. This is the only mode currently supported.

• Generating the metadata for the available products. It's possible to do this one product at a time, but, there's nowhere currently that generates the meta-data necessary. There's a demo xml in the root directory you can import.
• There's no external dependency handling, I need to add that in, but, I'm not sure of the best way to go about that. I can simply list the external dependecies to the user, and make sure they know they have to install those things.
• It needs a post-install script function to hook into distutils in case things need to be built.
• It asks for database dependencies, but, doesn't check for installed DAs to prompt you to install one if you don't have a relevant one installed. It also asks for platform, cpu dependencies, but, doesn't check those either.
• Zope should also be a dependency, and it should eliminate those products that don't work with this version of Zope. Python should also be a dependency as well I suppose.
• It only really handles installing Products, it needs to be extended to deal with .zexp files, and Extensions. I'll probably need to gather some more meta-data to fix this up. Hotfixes need to be handled too.

It does do somethings though;

• It handles specified dependencies, and all version of a product are stored, so you can specify an older dependency if something doesn't work with the latest and greatest version.
• It handles listing multiple download sites for fetching the archives.
• It handles .tgz, .tar, and .zip, I'm not sure if it'll work for windows or macs, I hope it does.
• You can install or upgrade a product without restarting (although the mechanism by which it does this, is somewhat err dodgey, so be warned). In my tests it's worked fine for me, without any adverse effects.
• You can import one product, or the whole tree (or a subset) including the fixed meta-data types.
• You can export your whole tree, or a sub-set.
• Importing/Exporting is done using xml_pickle, so objects are fairly simple to build by hand (if you really have to), or to create from a script.
• You can ZODB or (Postgres) RDBMS backed. ZODB is quick, but, isn't as flexible in its implementation. SQL is slow, but, is more flexible in its implementation, which will allow better searching (when that gets done).
• You can browse and install products by catgory.
• You can see what products are installed, and what the Control Panel sees as installed.

TODO:

• General clean-up -- the code is somewhat weird so that the same set of dtml files can be used by both ZODB and SQL interfaces.
• ZODB mode re-written in a cleaner more flexible fashion o SQL mode re-written in a faster fashion o Product Search option. o Partial DB syncing (give me everything new or changed since yyyy-mm-dd) o Uninstalling. we can store the manifest when a product is installed. o Post Install scripts to allow setup or building of extensions o Partial Exports. o Bulk Install. o Concrete Package Creation, where the metadata is stored with the package, so you can simply upload the file into Zope and have it installed. o Hotfix, Extension, .zexp handing o Upgrading Zope source installs. o Proper dependency handling (minimum version, maximum version, recommended (version) o HTML Interface fixes esp. dependencies.

WiFLZ Widget System for Zope WiFLZ is a dtml widget framework for Zope. If you are a programmer, you will probably hate it. It's not called ZWiFL because I was sick of things starting with Z d8)

Summary =======

• Widgets consist of; - header, body, and footer dtml, - optional arguments for the dtml template, - sql query, - optional arguments for the sql template, and - description field for built-in help facility.
• Widgets can be tested from the management interface. o Widgets can be ZODB backed, DB backed, or both. o Widgets can be optionally rendered to a DB effectively caching widget states, which is useful for slow changing, or time consuming things such as reports. o Cached Widgets have a configurable TTL. o DB Backed widgets can be grouped into different libraries, and can be called from specific libraries allowing test widgets to be setup without compromising production widgets. o DB Backed widgets can be edited from any Zope installation with access to the DB.

Purpose =======

This is part of a broader system for site design still under development.

Zope currently lacks a mid level reuse facility, reuse is limited to very fine grained (individual methods, and documents), or very coarse grained (products) elements.

Content managers also like to be able to build components that can be used in different parts of the site, and they like to be able to hold those components.

This system does not remove the ability to have fine grained reuse, as all of the dtml stored is resolved, so any methods you have developed can be used in a widget (e.g. incorporating ZBabel translations into widgets).

Installation ============

Unpack it in your top-level Zope directory. This should create a directory named lib/python/Products/ZWiFL/ containing the product files as well as this README file.

There is a file for the minimum tables you require to run ZWiFL in DB mode, called ZWiFL.sql. These are MySQL specific, but, should be easily adaptable to any other database. Create the tables in the schema file (MySQL users can just type mysql Database < ZWiFL.sql).

If you only intend to use ZODB, and no render caching you do not need to install these databases.

Usage =====

As mentioned this product has three seperate components;

Wifl Component Wifl Component Library dtml-widget tag.

Wifl Component --------------

This is the workhorse of the product. The Wifl Component has a rather large creation form, don't let this scare you, it consists of the following items:-

id: This is the same id that all Zope Items must have title: This is the title for this component

DTML Arguments: These are used to define variables that will be used inside your DTML. These arguments are normally only used for the Test interface to allow you to test your widget, but, also provide an good indicator to people using your widget what variables should be set.

DTML Header: This dtml will be rendered before your DTML Body. If you use an SQL call that returns many rows, this will be called once at the start of your widget, and will be called regardless of the number of rows returned by your SQL call.

DTML Body: This dtml will be rendered once for each row that is returned by your SQL call.

DTML Footer: This dtml will be rendered after your DTML Body. It will be called once, after the header, and body, are processed.

SQL Arguments: These are arguments, the same as ZSQL Method arguments. You need to define any arguments you wish to use in your SQL Template here.

SQL Template: This is the standard ZSQL template. Anything you would normally be able to use in an ZSQL Method can be placed here.

SQL Connection: This is the SQL Connection for your SQL Template.

Component SQL Connection: Selecting a DB here will force your widget to be DB backed only. If you want to have a ZODB or dual mode widget, leave this blank. If you choose to make your widget DB backed at this point, you will need to install a Wifl Component Library to access it.

We will review the management interfaces a little later.

Wifl Component Library ----------------------

This is a Folder object that allows access to DB Backed widgets. You can use it to access widgets written elsewhere. It's purpose is to provide SQL services to the tag, as well as to allow editing and configuration of DB Based widgets.

tag -----------------

To access your DB backed widgets you will need to make use of the tag. Usage is quite simple:-

ctag: the id of the component to render. lib (optional): the library to pull the tag from. If you have multiple libraries installed, the dtml-widget tag will try to pull the tag from the first library it finds, unless you specifically name a component library.

help: if this parameter is set, it will return the description field of the widget. Hopefully your widget designer will describe the widget arguments :-)

Calling ZODB backed Widgets ---------------------------

Calling ZODB backed widgets is the same as calling any other method;

To access the help for that widget;

Management Interface for Wifl Components =========================================

There are only three tabs that are specific to the Wifl Component, they operate the same way for ZODB and DB backed widgets;

• Edit o Advanced o Test

Edit Interface --------------

The edit interface is the same as the create interface, and all fields hold the same meaning.

However, if you have a ZODB backed widget and you choose to pick a Component SQL Connection, then this widget will be dual mode from now on. That is it will appear both in the DB and the ZODB.

If someone chooses to edit the DB backed one through a Wifl Component Library, then the changes will be stored in the DB only. The next time you change your component, their changes will be over-written.

You can change the Component SQL Connection to store it in a different database, so you can develop using a test DB, and when finished write it to the production DB if required.

Advanced Interface ------------------ This is a simple interface it has only three elements;

Cache Rendered Widget: tick this box to cause the widget to store its results into the database the next time it is viewed.

Time to live: This is the amount of time you want this widget to be used out of the database in seconds. After this time has expired a new version of the rendered widget will be stored into the database.

Component SQL Connection: This has the same meaning as it does on the other pages. You must pick a connection, and this will force your widget to be dual mode if you have made a ZODB based widget. This is not a bug, this is the way I wanted it to work. This allows me to see what widgets the cache matches to. If you never use the SQL database to pick widgets then this will not affect your performance.

Test ---- This will present input boxes for each variable you defined in both DTML Arguments and SQL Arguments. Pressing the test button will show you the output of your widget (and cache it). The cache should probably be invalidated after edits, but, it isn't, so you will see a cached version, which if you have a long-running widget, will show you that the caching is working (if its cached).

I am here-by going to bless Stephan Richter as the as the new maintainer of ZBabel, he's doing far more work on it, than I ever could, and has driven the development for the past 12 months.

Stephan's Site for ZBabel is here

This is the ZBabel Translation System for ZOPE, the Z Object Publishing 
Environment (http://www.zope.org/)

This is a phrase by phrase translation system, it allows you to translate
key parts of your site, and the content if you desire. With this you don't
need to maintain seperate source for each supported language, or mix different
languages in your source. You can do your entire site in one language and
then translate it without re-editing the source code.
This system also automatically creates the catalogs as you go, you do not 
need to manually insert text strings into databases for translation.


0.2 and above now feature caching of phrase lookups using the
ZOPE ZSQL Caching mechanism.
0.3 now actually lets you use variables for source and destination
languages (I'm a duh head ...).
1.0 has some huge amount of rework done by Stephan Richter see Changes for details of all 
the work he's done.


You can now use
<dtml-babel src=var&rt; or
<dtml-babel src="expr"&rt; or
<dtml-babel src=string&rt;
This product now extracts to simply ZBabel, not
lib/python/Products/ZBabel.

This is a two part product, it consists of an Image Factory product, which caches the generated images, and a tag that is used for generating said buttons.

The README file contains the example code from the ZButton Demo page, but, you'll have to fetch the template I used (the URL is in the README).

This product REQUIRES PIL, it's tested with 1.1.1. you also need jpeg support (paletted image support in PIL really sucks) Consequently the following things that I'd really like to have are missing;

• Transparent backgrounds o True/Free Type support.

If someone motivates me enough (pays me to), I might be convinced to create a write filter for PIL to write out transparent PNG files. If one appears in PIL that doesn't have absolutely crap palette reduction, its pretty simple to fix Buttons to use it, and transparent backgrounds will be available.

PyFT doesn't support the latest FreeType libraray that comes with XFree-4, and I wasn't going to destroy my workstation after spending eons getting the way I like it, just for buttons d8)

If a later version of PyFT comes out, I'll look at using True Type fonts.

This is a large product, because it contains all of the 75dpi X fonts on my system, these fonts are unencumbered, and have been pre-converted to work with PIL.

Once you've installed an Image Factory somewhere in your tree.

will give you a nifty usage page.

All arguments to are expressions... that means literals need to be enclosed by "' '" to make sure they don't clash with Zope Ids you might have. While this is annoying if you hard code buttons, it's quite nice if you generate them, which I expect the normal case to be.

This is the ZWeather Product. It consists of a management product, and a tag for displaying the weather in a pleasant format.

There is also an External Method (weather.py) which you can use to drag down raw weather reports if you desire, but, it's only really there for looking how things work.

The weather items are self-updating, based on the update frequency set for the Weather Management product.

Updating can be extremely slow, so if you want to run a large number of weather items, this is what you should do;

• Mirror the (relevant) METAR data to a local FTP area o Set host and data path in the Weather Management product to point to your mirror.

This will alleviate bad stalls when people are viewing pages with weather information on them that has to be updated.

The default view is somewhat ugly (on purpose), to encourage you to change the showWeather method that is present under the Weather Management product. It does serve as a pretty good example of what's available, and how to get at it.

The weather tag is easy to use:-

for metric or

or for imperial units.

When adding a new Weather item

if you set the GMT/UTC offset, you can get a different set of icons at "night time" (1800 - 0600) than "day time" these are arbitrary limits because I really can't be bothered tracking sunrise and sunset just to change the icons dead on :-) Setting it to zero will result in the icons changing around UTC time which is probably not what you want.

You can add a showWeather DTML Method to any individual Weather item if you want that one to display differently from the group.

METAR Codes can be found at: http://www.nws.noaa.gov/oso/oso1/oso12/metar.htm

as well as in the nsd_cccc file in the ZWeather Directory

which contains a lot of other data to boot (it isn't used by ZWeather though), I put it in there just for something to look at.

You can look up stations by US State, or by Country in the rest of the world by going to; http://www.nws.noaa.gov/oso/siteloc.shtml

I don't remember where I found the weather icons, I've got a boat load of icons sitting around from various places.

Hacked version of ZODBCDA to work with unixODBC

Compiled Page Templates is a Zope product that you can use in place of Zope Page Templates (including PageTemplateFile), to get a performance boost. They operate just like regular Page Templates.

This is a Zope frontend for the Project Management software trac from edgewall.