[TransWarp] More PWT Ideas (usage, not terminology!)

[Phillip J. Eby]

* Caching DOMlet - takes parameters for various values to key the cache on, 
or to verify that recomputing the contents aren't necessary.  The DOMlet 
simply saves the results it got from calling its inner DOMlets, and spits 
them out as static text while the cache is valid.  Since peak.web apps 
(even CGI ones) have a reactor available, the cache could use 
reactor.callLater() to schedule its own TTL cleanups, which would take 
place between serving web hits.  Note that this can be a cache of *part* of 
a page, or even multiple caches on the same page - ideal for portal-type 
applications.

* Push-driven "scoreboard" DOMlet - some applications may have high-read, 
low-write data, but with a strong need for being up-to-date.  (E.g. sports 
scores, weather, stock prices.)  Such an application doesn't want a 
TTL-driven cache, nor does it want to query the underlying data source on 
every hit.  Solution: make a DOMlet that registers as a listener with an 
event source internal to the application.  Because DOMlets are 
binding.Components, they can have 'binding.whenAssembled' methods that 
subscribe them to the event source, as soon as the containing XML/HTML 
template is compiled.  Whenever they receive notification from the event 
source, they can invalidate their internal cache, so the next time someone 
requests the data, it's up-to-date.

* Master page layout DOMlets - Most of the "method" templates in an 
application want to live in some kind of standard layout, ala Zope's old 
"standard_html_header/standard_html_footer".  I think the way to do this is 
to have a "page" DOMlet that encompasses a master page layout, with 
"insert" DOMlets for places where content from a "method" page would be 
inserted.  This is basically the same as ZPT macro definition: the "page" 
is the "define macro" and the "inserts" are the "use slot"s.  Meanwhile, on 
the "method" page, you reference the master page itself as a domlet, and 
use 'define' to mark the items to be pushed into the master page, ala ZPT 
"define slot".  (I may have some of my terms backwards here; ZPT fans 
please correct me if so.)  Note also that we could dynamically select the 
master page based on runtime criteria, if desired.

* Breadcrumbs DOMlet: this could look "up" the traversal path to find a 
"navigable location" utility, that could return the next containing 
"navigable location" and so on.  Navigable locations would know their title 
and URL, and maybe an icon, although other things could be done with 
properties.  The breadcrumb DOMlet would accept define's for where to put 
the text, what to use as a separator, etc.  Actually, in a lot of ways it 
would just be a list DOMlet with special logic to get the list, and what 
the data model of the list elements was.

* Tabbed menu DOMlet: another variant on a "list", this would probably need 
lots of little define's for things like "selected tab body", "unselected 
tab body", "leftmost tab edge", "rightmost tab edge", etc.  It would 
probably work by adapting its target to some kind of ITabbedMenuProvider 
and then requesting a list of tab objects, with data for title, URL, and 
selectedness.  Heck, come to think of it, there isn't much difference 
between this one and the breadcrumbs idea, they're both about a sequence of 
titled links and selectedness.  It's just that for breadcrumbs, the last 
item in the list is always the one that's considered "selected".  So if we 
write one of these well, we just subclass and change what interface the 
subclass looks for.  :)

* Paged report DOMlet: yet another "list" enhancement.  Add "header" and 
"footer" defines, so that you can add stuff that goes at the start/end of 
the list, and maybe allow defines like "header:account", meaning "something 
to insert when the about-to-be rendered row has a new value for 
'account'".  DTML had lots of handy features for dealing with these sorts 
of patterns, including things like autocreating URLs to change 
options.  It'd be quite awesome if there was a way to include options like 
clickable sort-by column headers!

* "Feedback" DOMlets/methods: many methods in a web application perform an 
action.  These actions are written in Python, not in templating 
language.  So, what do you do when the method's finished?  You could 
redirect somehwere meaningful, but oftentimes what you want to do is 
redisplay the "same screen", but with some feedback messages inserted at 
the top.  (This can include redisplaying a form with error messages.)  It 
would be cool to have a way to implement this idiom, using a "feedback 
DOMlet" that marks the place for these to go, and then be able to have a 
method simply return a "feedback object" containing the info.  In the 
location class, we'd simply wrap the method in something like 'myMethod = 
web.Action(mymethod, "the.template.to.use")', so that the method body isn't 
bloated with minutiae.  The method wrapper would handle invoking the 
template and passing through the feedback object.  And, if we're using a 
"master page" DOMlet, then it could even be the place where the "feedback 
DOMlet" lives.


These are probably only the barest beginning of what's possible with a 
little imagination and the DOMlet framework.  I mention them here so that I 
don't lose/forget the ideas, but also in the hopes of inspiring others to 
take a closer look at the machinery and to dream big dreams of their own, 
or maybe even get started on some of the ideas I've mentioned.  :)

I also mention them to try and think through a little bit what kind of 
design patterns might need to be created to use DOMlets effectively, and to 
see if the internal architecture is right to support these ideas well.  So 
far, it's holding up pretty decently, although I'm considering trying to 
simplify the 'renderTo()' method signature.  What I'm not sure is holding 
up as well is the "location wrappers" system that lives above all this, but 
I don't have any concrete concerns as yet, just vague concerns.

Probably, those concerns are derived from the fact that we don't currently 
have any application-specific location adapters, so everything is generic 
and the URL paths are based on underlying object attributes.  For example, 
without application-specific location adapters, there's currently no way to 
derive a *canonical* URL for an object.

It also seems to me that there may be many other application-specific 
protocols we have yet to define, besides the current 'locationProtocol' and 
'behaviorProtocol'.  For example, a "breadcrumb protocol" or "tabbed menu 
protocol".  How many of these things exist?  Clearly, the current framework 
will support any individual thing you want to do, but how does it scale 
across the universe of things that are being done by different 
people/apps?  This is the sort of like my discovery of how hard it is to go 
from "object type" to "data manager" for that type.

Anyway, that's about all I have for tonight.  I'll continue to give these 
and other things some thought and consideration.  In the meantime, feel 
free to tell me *your* "DOMlet dreams", as it will help me clarify some of 
these issues in my own mind.