Fred Drake wrote:

>>I think the ISourceItem is important, as it allows people to extend what is
>>being returned by their sources. In particular, we would have
>>IIterableSource sources that return IRichSourceItem which also provides a
>>snippet() method or view. This would provide an XHTML fragment which would
>>be used to render a list of radio buttons or check boxes with markup in the
>>descriptive text.
> Aside from how context-sensitive sources are bound and the specific
> arrangement of interface relationship (which needed help), you've very
> much described vocabularies.  I think moving away from having the term
> objects provided by the source was specifically something Jim wanted,
> which is why he uses adaptation to get the ITerms object for sources. 
> While I find this somewhat tedious, it actually makes a good bit of
> sense, given that the terms are really only used to support the UI,
> while the sources themselves are essential to the applications we
> build with them.
> The current ITerms approach for sources makes terms essentially views
> on the values from the source, so that's a good way to provide things
> like XHTML snippets that can be used in the UI.

So lets say I have a Source that provides values from an RDBMS table, which
contains a unique key and a display name (very common in our application).

If the Source generates the ITerms, iterating over 100 items in the table
can be done in one RDBMS query. However, if you need to adapt the key to a
Term how does the Term know what the display name is? I'm either not getting
how this all fits together, or generating a <select><option
value="key>Display Name</option>...</select> control for 100 items will take
101 queries in the new model.

Stuart Bishop <[EMAIL PROTECTED]>

Attachment: signature.asc
Description: OpenPGP digital signature

Zope3-dev mailing list

Reply via email to