"Leslie P. Polzer" <[EMAIL PROTECTED]> writes: > 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?
Same as now, no difference. >> 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 did not intend to limit what you can do with uri-tokens processing. My draft did not describe it in detail, as I wanted to flesh out the major design points first. I do not see a problem with doing what you described above -- but I think Stephen has a point that it really is better to let dispatchers extract information from URLs and call functions that create widgets. >> 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? Why not? The main point of my redesign is to separate dispatching from selecting/rendering. This is what we got mixed up in both our current implementations. Dispatcher also renders and selectors know about uri-tokens, this is all wrong. > 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... I think this needs to be redesigned according to Stephens suggestion -- keep all uri parsing and parameter extraction in the dispatcher. >> 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? Yes, if that is to be created on demand. If you intend to keep both /document/65 and /document/65/printable in your widget tree (say to navigate with a static javascript tab widget), then you might not need the dynamic part. But perhaps dynamic-selector is a bad idea. I have to think about it. [...] >> ----------------------------------------------------------------------- >> 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? make-navigation would build a single navigation object, so you would get everything in one block. The single navigation object is actually a specialized navigation-menu that also contains its navigated content as a convenience. make-split-navigation would return a navigation-menu widget and navigation-content widget. See the diagram for what they actually are. >> 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? Remember that I split dispatching from selecting/rendering. The main dispatcher object will dispatch based on the first uri-token and will either change the state of the first selector (switching between admin/user interfaces) or the user interface will kick in (it will typically have another dispatcher inside). So, the main dispatcher does not "know" about the user navigation, it only needs to know about the "/admin" entry point. I am not sure if that is such a good example anymore :-) --J. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
