Package README (CVS ver. 1.1.1.1)

An object implimenting quick lists will have actions in the
quick_lists category.

For best separation there will be:

  selection macros

    These are macros that provide the interface for making the
    selections which form the criteria for the returned list.

    Specified in the 'action' attribute of the portal_action object.
    The 'action' attribute must be a TALES expression that evaluates
    to a valid TALES path expression for the macro.  It cannot be the
    raw path expression as it gets evaluated before being passed to
    the template rendering the macro.  For example,
    "string:here/template_id/macros/macro_name".

  listing methods

    Python methods that will parse REQUEST and return a list of
    project part containers.

    The method is specified in the selection macro and passed to the
    display macro through the request in the ql_method key.

    There is the option of specifying additional attributes in the
    portal_actions object and using those to allow one selection macro
    to selectively use more than one listing method, but this would
    still not be customizeable in the ZMI so its probably not worth
    it.

  display macros

    These are macros that call the listing method named in
    REQUEST['ql_method'] and render the resulst from the listing
    method.

    The TALES path expression for the macro should be passed to the
    page in question in REQUEST['ql_display'].

You can use use-macro statements inside define-macro statements to get
different combinations of select and display macros without rewriting
the template code.  It is also best most of the time to make a
ql_name_here.pt template that will contain all the related quick list
macros: the selection macro and the display macro.

Notes on decisioins made:

This is resolved by use-macro statements inside define-macro
statements as mentioned above.  This note remains for reference only.
-- Relying upon id's to identify macros seems like a bad idea and too
far a departure from the actions mechanism.  Closer to the actions
mechanism would be to use the 'action' attribute to refer to the
selection macro.  This means, however, that using the same macro while
passing it a different final action is lost.  May have to come up with
other ways to do that, can also use additional action attributes.  But
that's not customizeable in the ZMI.  Oh well, the final action is
usually tied to the the selection macro anyways.  And the loss of
functionality is less likely to have an impact than the potential id
namespace clashes in the future.