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 )
