> > 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.
>
> Not quite.  The lesson *I* learned from DTML is that HTML generation can
> be sufficiently complex that you need real control structures, and that
> holds double for form processing.  Our first crack at PTL looked a lot
> like Cheetah: HTML with Python in it, but "more obviously" Python than
> DTML.  That turned out to suck as much as all other embed-a-real-
> language-in-a-markup-language approaches, so Neil came up with what you
> now see as PTL.  The great strength of PTL is that you have all the
> facilities of a *real* language -- sensible quoting, control flow -- at
> your disposal, instead of being bound to the brain-damage of a markup
> language.
>
> Separation of UI from main logic is essential in any case.  Having real
> control flow (and objects, and access to the filesystem, etc. etc.) at
> the UI level is also essential, but for very different reasons.

And it's important to have a clear idea of what "UI level" is and what "the
other level" is.  If you've got that from the beginning, things tend to
decompose nicely, but if you've got a sticky mess it can hard to see how to
untangle it.

> > 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.
>
> Not sure what you mean by "Quixote objects" -- do you mean the
> namespaces that Quixote traverses when resolving a URL?  On the web, the

Yeah, that's what I meant.

> Does that make any sense?  Does it provide any reassurance that you're
> on the right track (it sounds to me like you are).  I find having two
> separate classes helps to clarify the separation between UI and domain
> logic.  Also, there is by no means a 1-to-1 mapping between domain
> classes and UI classes; for example, SPLAT! has a BugDatabase but no
> BugDatabaseUI.  (The list of all bugs is generated by a couple of PTL
> templates -- nothing OO needed there.)

Yeah, sounds like my thinking is (now) on the right track, but all my code is
backwards :)  I started out nice and simple, but then I started wanting
complicated UI objects with their own state (scrolling lists with 'next' and
'previous' links, for instance) and now it looks like I should have been wiser
from the beginning.

Thanks for the reassurance, though! :)

Maybe when I'm done with this and have some free (hah) time, I'll write up a
doc and example code so other people won't fall into the trap I fell in.
There should also possibly be a standard library of UI code... wait, I guess
that's what 'form' is.  Sometimes I feel like I'm reinventing Zope, but at
least it's a Zope I understand :)

> Generally, the only time we have a FooUI class is when _q_getname() is
> used, ie. for "dynamic" URLs.  For static URLs, everything is just a
> function (template) in a module somewhere.

And for my app, almost all the URLs are dynamic.  I wrote a
Collection_publisher mixin that defines a _q_getname for self.__getitem__,
which delegates to some collection.  Then I wrote Lazy_object and
Lazy_collection that thunk on demand.  I suppose it would be more OO to
override __getitem__, but it's nice to be able to pass around a lazy object,
though I have to be careful to not do strict things to it.


Every time I see 'template' in python I start getting nervous and frightened
and start glancing around for the angle brackets.