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 =======
help
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.
reuse
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.
build
hold
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 :-)
description
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 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.
dual
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).
Log in
Forgot your password?
