Jan Rychter <[EMAIL PROTECTED]> writes:
> I do not believe we should strive for URLs to reflect the current widget
> hierarchy or state. I think the mapping should be restricted to URIs ->
> application entry points. You can't reflect the entire application state
> in an URI anyway, and nobody really expects that. You just want people
> to be able to pass on URLs to your sites so that they point to existing
> and known entry points (locations) in your application.
Furthermore, attempts to turn all drilldowns into URL navigation should
be discouraged. I have a lot to say about that, but will save it for
another time.
> 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?
> 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).
> 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.
(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.
> 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.
Consider http://www.hfsbo.com/services-and-pricing . As the
non-technical administrator of this site, you would typically decide to
make changes to the information shown on this page while looking at it.
The workflow encouraged by separate admin interfaces such as those
insisted on by Django and the like is:
1. Go over to the admin side, logging in if necessary.
2. Find what it is you want to change *again*, using a completely
different interface for the same data.
3. Change it.
4. Reload the original and make sure it's what you want.
If your admin isn't technical enough to use multiple tabs/windows
liberally, themselves a kludge to deal with poor web interfaces like
this one, add even more interpage navigation to the above. I would not
be surprised if many admins log out, navigate back to the front page by URL,
and find the right page from the root again.
The main element of the page I linked is actually a listedit with
post-view-rendered gridedits, linked into a tree by a primitive version
of the `generate-subwidgets' system I recently committed to my
modern-dispatching branch, where the login flow calls a version of
`walk-widgets' (similarly recently committed) with the `auth-changed!'
GF. The listedit and gridedits respond with mark-dirty, and the various
allow-{add,delete,drilldown} methods on them eventually test whether the
authenticated user is an admin.
So here is what the change flow looks like:
1. Log in using the link at top if needed.
2. Make changes, seeing them incrementally as you save dataforms, in
exactly the same interface as the public side.
I really like this pattern, and it is in use in a few other places on
that site.
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.
--
I write stuff at http://failex.blogspot.com/ now. But the post
formatter and themes are terrible for sharing code, the primary
content, so it might go away sooner or later.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
