[Zope3-dev] Vocabulariy issues

[Jim Fulton]

Garrett Smith wrote:
> Jim Fulton wrote:
> 
...

> 
> Let me see if I have this right:
> 
> - The motivation to create a 'source' framework is to have something
> that provides values rather than terms. This simplifies the 'source'
> part of the framework.

More importantly, it removes UI details (tokens and titles) from the
specification layer.


> - To provide titles and ids ('tokens' in vocab-speak) for values, we
> have ITerms, which is a view to ISource. So we'd use it like this:
> 
>   zipcodes = zapi.getUtlity(IIterableSource, 'zipcodes')
>   terms = zapi.getView(source, '', request, providing=ITerms)
                          ^^^^^^ zipcodes :)
>   for value in zipcodes:
>     term = terms.getTerm(value)
>     value, term.id, term.title
>     # e.g. u'60187', '60187', u'60187 (Wheaton, IL)' 
> 
> (Zipcodes would probably not be iterable, but it's just an example.)
> 
> With this approach, one could provide alternate ways (named views) of
> displaying zipcode titles without redefining the source.

Yes

> - The existing vocab framework doesn't really support querying
> interfaces, though it sort of pretends to. For this we create
> ISourceQueryView.
> 
> Questions:
> 
> - Apart from backward compatibility, is there a reason to keep the
> existing vocabulary framework around?

Nope. But, from X3.0 on, backward compatability is important.

 > Is this something that will/should
> be deprecated at some point?

Yes

> - I'm having a hard time placing ISourceQueryView in context with
> IWidget.

I can understand this.  It took me a *long* time (and Gary's help)
to get my head around IVocabularyQueryView.

 > It seems that ISourceQueryView is UI for a specific
> IInputWidget that is displayed as a separate dialog. This is similar to,
> e.g., a date/time widget that provides a separate dialog for navigating
> a calendar UI. Any input widget that provides a UI that has its own
> request/response support would fall into this category.

Sure

> I'd like to see the widget framework enhanced for this sort of thing.
> The typical scenario would look something like this:
> 
> 1 - User displays an edit form containing input widgets. One of the
> widgets contains a button for browsing or searching for values.
> 
> 2 - User clicks the 'browse' button on the widget to display the
> browse/search dialog.
> 
> 3 - The current values in the edit form are saved (session data, or
> embedded in the browse/search dialog).
> 
> 4 - The user interacts with the browse/search dialog until she clicks an
> OK button.
> 
> 5 - The user is redirected back to the original edit form, where the
> newly selected values (if any) are displayed along with the saved values
> from step 3.
 >
> This scenario would be different if the dialog is displayed in a
> separate window or an iframe (probably the more common use case for
> modern UIs). E.g., step 3 would not be necessary and their would be some
> browser scripting involved.

One additional part is that, in addition to selecting new values,
you often want to be able to see the existing widget values.
(If pop-up forms were used, this would still be possible.

> I know Gary has done a lot of work in this area with his widgets --
> might this not be the time to enhance widgets/forms for this?

It might be if people have time.  I *have* to resolve this in the
short term so I can finish working out PAS for Zope 3 and I need to do
that as soon as possible.  IOW, I'd love to see something more general,
but I doubt that Gary or I would have time to work on it soon.  I do
need to get the large-source/vocabulary issue resolved soon though.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org