Stephen Compall <[EMAIL PROTECTED]> writes:
[...]
>> Dispatcher is responsible for mapping from URIs to selector/pane pairs.
>>
>> Aside from its dispatching table, the dispatcher is stateless. It does
>> not know what is currently selected. It does not maintain caches, it
>> does not generate pages. It only dispatches.
>
> If you are not responding to a URL request, how do you walk down to the
> currently displayed content?
I am not sure I understand the question -- we have a full widget tree,
where everything that could possibly be displayed is in the
tree. Selectors maintain the current state, e.g. what is selected. This
means that you can walk the tree and render it, or find currently
displayed content. You do not need to dispatch to do that.
>> 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. Also, usually
>> dispatchers will want to dispatch on a fixed number of URI tokens, but
>> that is not enforced.
>>
>> Dispatchers should have multiple strategies -- simple string matching,
>> regexp matching and wildcard matches come to mind. 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.
>
> I believe the current dispatcher design, except for the timing of URI
> stripping (fixed in modern-dispatching), is right. Different kinds of
> URI stripping can be implemented with function-returning functions,
> without complicating the class hierarchy, or putting even more logic on
> the already-overloaded selectors.
>
> It is not like the cache is optional for dispatchers, given that not all
> requests have URIs attached, and we would surely like to be able to
> dirty them (which we cannot do in dev, IIUC).
Perhaps I misunderstand the cache -- but isn't the cache supposed to
cache *widgets*? When I designed, I believed that role belongs to the
selector.
>> 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 disagree with this point. Putting widget creation on the dispatcher
> means you only need one object to implement navigation among ephemeral
> subwidgets ("on demand"). Dispatcher plus chooser function equals
> magic. "Dynamic selector" feels far too much like the "Factory"
> pattern, and factories are not needed in Common Lisp as we have
> first-class functions.
Interesting. I think you have a valid point. But let's discuss. I
believe that the major flaw of the current dispatcher design is that it
mixes up dispatching with selecting and rendering. I think I would be ok
with the dispatcher extracting arguments from URLs and creating widgets,
but it would need to pass them on to selectors. Otherwise we will still
have two entities responsible for selecting and rendering their content,
which I think is a design flaw.
I'm not a fan of factories myself. But please note that
"dynamic-selector" is more than just a factory. Its role is mainly to
*select* among cached widgets and possibly create one on demand, if
needed. In fact, as this is CL and not Java and we don't do factories,
the selector itself maintains state (what is selected and what is
cached), it is always a function that creates new widgets.
My point was mostly to keep the dispatcher as an URI processor, but
remove all rendering from it.
> (I have less to say about your other selector proposals. I don't really
> like how they are in dev or modern-dispatching.)
>
>> dynamic URLs (wiki): dispatcher does not create any content, it only
>> dispatches a wildcard token (or multiple tokens) to a
>> dynamic-selector. It is the dynamic-selector's job to actually create
>> content, maintain a cache, and select it.
>
> As I have mentioned above, I believe this only complicates things beyond
> what you can already do with dispatcher and the default
> widgets-ephemeral mode.
In a way, yes, it does, but only for the dynamic URIs case. Looking at
it another way, it is the dynamic-uri case that seemingly complicates
things, as we are trying to force the dispatcher to also render
widgets and maintain a cache of widgets. And our dispatchers are not
containers, remember?
Hmm. Now that I think of it -- perhaps a better solution is to implement
the generic dispatcher without any wildcards or dynamic URIs, and then
implement a wiki-dispatcher that would be both a dispatcher and a
selector, just as navigation-menu is? That would keep the functionality
you want in one place.
Please let me know if you still disagree after my clarifications -- I
have the impression that we might meet in the middle.
>> 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.
>
> While this has less to do with your proposal, I believe this sort of
> thing should be discouraged, considering the user's standpoint.
[...]
> Obviously, not all information can be managed in this way. However, it
> does cover a great deal of it. The danger of talking about "admin
> interface" is that to the Weblocks user it says "you're supposed to do
> it like in Django", which is a very poor substitute for the power to
> create intuitive interfaces that Weblocks offers.
Good stuff. I agree with this, but I still think there are cases where
you need to replace the user interface altogether. And I have one of
them right in front of me right now :-)
I think both approaches should be implementable using Weblocks.
--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
-~----------~----~----~----~------~----~------~--~---
