I generally follow this approach for long lists and reports, but the tree
tag is a bit more tricky because you only have a simple data object
without the context that a real object provides. A real object makes it a
lot simpler if you recursively draw a hierarchy - doing it with simple
data objects requires some thinking but thanks for pointing me in the
right direction.
Roché
Just return the result directly. If the data is all from SQL, that's all
you need to do. The catch is that you may have to structure your ZClass
differently to allow it to be returned from an SQL method.
The simplest thing, though, is to define your application API's so that
methods which must return multiple objects in this fashion are returning
sequences of simple data objects which do not provide the full
semantics
of the real objects. In essence, define the API as returning reporting
data rather than objects. This is similar to the ZCatalog
approach which
returns dumb record objects, but can optionally retrieve the real
object if
needed. It is generally the best approach for report-like
situations (such
as use of the tree tag).
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
