This approach looks sound but I do have questions:
> Dispatcher knows about URIs, selector objects and pane names
> (symbols). When an URI is matched, it calls the select-content method
> with the selector object and pane-name parameters.
>
> There can be multiple dispatchers in a widget tree and not all
> arrangements of dispatchers and selectors will make sense.
How are nested dispatchers handled in this scheme?
> Also, usually dispatchers will want to dispatch on a fixed number of
> URI tokens, but that is not enforced.
Consider /documents/65 and /documents/65/printable.
For the first URL I'd currently return
(make-instance 'document-widget :id 65)
and for the second either
(make-instance 'document-widget :id 65 :printable t)
or
(make-instance 'printable-document-widget :id 65)
How would this work with your scheme?
I don't mean to say that it doesn't work, but I'm having trouble
imagining it...
> Dispatchers should have multiple strategies -- simple string matching,
> regexp matching and wildcard matches come to mind.
How about a dispatcher that takes the current time or system load
into account? Is that possible?
It's not that I'm trying to make much sense with this, but I'm
interested in the limitations of your model; this will help me
understand it.
> When thinking of
> dispatch strategies, keep in mind that we do not want to extract
> parameters here, we only dispatch to a particular selector with a
> particular pane-name that it registered with us. For wildcard matches,
> we pass on the uri-token that was matched as the pane-name. It is the
> selector's job to understand this.
So we can also pass on a list of tokens? Does a wildcard match
slashes, too? If yes then it might make sense to have another
wildcard that doesn't match slashes...
> Dynamic Selector is a Selector that implements a dynamic content
> creation strategy. It creates widgets on demand, and usually gets
> registered with a dispatcher using a wildcard URI match. The "widget
> cache" belongs in the dynamic selector, not in the dispatcher.
I suppose this one would make the /document/65/printable thing
possible?
> Navigation Menu is both a Dispatcher and a Selector. Dispatcher, because
> it reacts to URIs and changes other widgets' state based on
> URIs. Selector, because it has to update its own state to highlight the
> currently selected menu item.
Makes perfect sense, very good.
> -----------------------------------------------------------------------
> Navigation is a Navigation Menu that also contains Navigation
> Content. It *is* a Navigation Menu because it needs to be placed in the
> widget hierarchy (because of dispatching), but it contains its content,
> because of the loose relation between dispatchers and selectors. If you
> just use Navigation objects, you can forget about the whole
> Dispatcher/Selector separation of concerns business.
Alright, so how do MAKE-NAVIGATION and MAKE-SPLIT-NAVIGATION fit
into this?
How will I be able to render the menu separate from the content
or not at all?
> user-interface/admin-interface: the main dispatcher object knows about
> the user navigation (registered by the user navigation selector) and the
> "/admin" URI registered by the admin interface selector. The admin
> interface selector is placed (normally invisible) above the
> user-interface navigation content in the widget tree. This means that
> the admin interface selector can "choose" whether to render the user
> interface or the admin interface, based on updates from the dispatcher,
> or (in the future) based on updates from an action.
I'm not sure I get this. Why does the main dispatcher need to know
about the user navigation when the latter is fully managed via the
admin nav?
Thanks a lot so far!
Leslie
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"weblocks" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/weblocks?hl=en
-~----------~----~----~----~------~----~------~--~---
