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]> http://www.stuartbishop.net/
Description: OpenPGP digital signature
_______________________________________________ Zope3-dev mailing list Zope3email@example.com Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com