Hey, I have another quixote question.  The fact that we have .ptl files in
addition to plain python code implies a separation of HTML generating code
from "main logic" code.  I suppose the lesson learned from DTML, though, is
that the HTML-generating bits are sometimes so complicated and intertwined
with the actual objects that it's not always desirable to try to keep them
separate.

Still, I don't like the idea of cluttering up my quixote objects with HTML
generating code, so what I've been doing is giving each object a "view"
wrapper object.  Form parameters intended for "view-level" (HTML generating)
classes begin with 'v_'.  That, of course, implies that the view objects
should be the ones served by quixote, but unfortunately I did it the other way
around (because I started with plain objects and then added views later),
which makes it hard to avoid creating cycles (since objects have their views
and the views need a reference to their objects) and seems clumsy and wrong.

Say you have a User who has Prefs.  The Prefs have a web UI to modify them.

In the "objects have views" model, Prefs._q_index handles the non-view form
stuff (modifying the prefs, etc.), and then delegates off to the view with
'return self.view.request(req)' which handles the view form stuff (current
index for a scrolling window, etc.).

In "views have objects" you have a User_view which wraps a user, and has
a 'self.prefs' which is a Prefs_view wrapping the Prefs.  So you're setting up
two parallel hierarchies of objects (has-a goes both vertically and
horizontally if that makes any sense):

User_view           has-a ->    User
    Prefs_view                      Prefs
    Foo_view                        Foo

This seems complicated and confusing, though the basic idea (view objects wrap
"heavy lifting" objects with an html ui) seems innocuous enough.  Now Foo_view
objects wind up delegating form processing to their "work" objects, which
implies that the view objects should do *all* the form processing and
verification and talk to their work objects when there is work to be done.

On the other hand, "objects have views" can be much nicer because in the
simple cases it degenerates down to "objects do everything but call a
function to return the HTML".  What I'd really like to do is make sure I have
nothing but simple cases.

Another approach would be to have User_view inherit from User, to avoid having
to do all that delegation, but having to then worry about name clashes is no
good.  Besides, views aren't really subtypes of their objects (they may not
even have any objects).

Or it could be I've taken a wrong turn somewhere, and am now mired in
hopeless complexity.  Is there any conventional quixotic wisdom on the
subject?



Zope's new DTML replacement looks kind of cute, I like the mockup-which-turns-
into-the-real-page aspect.  Hopefully they're keeping the control structures
down to a minimum (just variable substitution and sequence iteration maybe?)
so we don't wind up with another DTML sublanguage.  Someday when I have more
time maybe I'll see how it fits in with quixote's acquisitionless just-plain-
objects thing.