[Jeff - no need to cc me, quixote-users mail goes to my main inbox]

On 13 November 2001, Jeff Rush said:
> Some parts of Zope are quite nice and make life easier but others
> are frustrating.  After working with Quixote for a day, I'm finding
> I have a lot of questions about basic support infrastructure that
> I took for granted in Zope.
>
> * Quixote doesn't seem to put in BASE_URL directives in generated
>   html output, making it a bit clumsy to construct relative URLs.

Take a look at the methods in quixote.http_request.HTTPRequest.  In
particular, get_path() and get_url() might be useful.

> * I'm looking for the equivalent of url_quote and html_quote to
>   wrap strings in python-generated output.

They're in the quixote.html module.  See the docstrings.  The
value_quote() function is also very useful.

> * I'm looking for how to require a basic auth login on selected
>   pages -- need to do something re request.response.set_status(...)
>   and check for http header auth fields.  I need Zope's userID
>   framework on top of which to build security features.

DIY.  Quixote gives you the tools for implementing an
authentication/authorization infrastructure, but (so far) declines to
implement any actual policy.

> * what are form tokens in session objects?

They're used to avoid the "cross-site request forging" (CSRF) security
hole common to most web applications.  I don't *think* they make any
sense unless you use the classes in quixote.form, which you have already
figured out are, umm, undocumented.

I'm not sure I understand this mechanism well enough to explain it
off-the-cuff.  Neil?

> * need the equivalent of  for debugging.

Some alternatives:

1) configure DEBUG_LOG, print request.dump() in your code (PTL or
   Python), and tail your debug log

2) call request.dump_html() in PTL at the appropriate point in your
   web page:

   __exports__ = [..., "my_page", ...]

   template my_page (request):
       my_header("My Page")
       "
This Is My Page
\n"
       request.dump_html()
       "
I hope you enjoyed it.
\n"
       my_footer()

3) return the result of request.dump() from a Python-generated
   text/plain web page:

   __exports__ = [..., "my_page", ...]

   def my_page (request):
       request.response.set_header("Content-type", "text/plain")
       return request.dump()

Hope that gives you some ideas.

> * not sure of correct way to handle URLs with '.' in them,
>   as in programmatically generated .gif responses.  Looks like
>   it requires _q_name() ?

Hmmm, that's not something that has come up.  We keep our static content
(URLS with dots in them) out in the filesystem (/misc under Apache's
docroot), and have configured Apache to redirect everything outside of
/misc (and a few other things) to Quixote... thus /misc/logo.gif is
handled entirely by Apache.  If our Quixote app happens to generate a
URL "/misc/logo.gif", then the client requests that, and Apache returns
the file from the filesystem.

If you must have dotted URLs in your Quixote-controlled URL-space, I
think _q_getname() is the only answer.

> * I miss a whole set of URL path manipulation functions, although
>   I think I can get by with os.path.XXX in most cases.  Mostly
>   I just need a 'parent' or 'container' request attribute.

See how far you can get with request.get_path() and request.get_url().
See the docstrings for help.  Let us know if you need anything more.

(ISTR that generating an arbitrary URLs under the URL_PREFIX of the
current Quixote app isn't handled very well, if at all.  Hmmm.)

> * any better way of inserting ?x=1&y=2 style values than:
>
>   """testing %(x)s and %(y)s""" \
>     % { 'x': request.form['x'], 'y': request.form['y'] }

Umm, why not this:

    """testing %(x)s and %(y)s""" % request.form

?  That's what you're doing, in a painful and contorted way.

>   This is where the namespace searching of Zope re attrs, form
>   and environ variables was nice.

Zope's namespaces are an unholy mess.  I wouldn't touch that stuff with
a bargepole.

> SQL, and Fnorb/CORBA, both require you to rigidly predeclare your
> types/interfaces, and while I understand the benefits of such,
> it makes an impedance mismatch with python's more free form way.
> Switching to ZODB will improve rapid developing.


Of course, Python's free-form way is not without its dangers and large,
long-term projects.  When you start thinking about type-checking your
database, look into Grouch:
  http://www.mems-exhange.org/software/grouch/


> Yeah, that affects the architecture, but in my case, ZEO is binding
> to a unix socket and the apache/quixote process is on the same host.
> I just need ZEO to allow nonweb tools to access the ZODB at the same
> time pages are being served - email-API queries and cron maint tasks.

That's our situation exactly.  Except we have ZEO binding to 127.0.0.1
-- roughly the same security as a Unix socket, but slower.  Hmmm.  Why
are we doing it that way again?  ;-)

> At the moment I'm wondering the best way to hook it in.  I've subclassed
> SessionPublisher into a ZODBSessionPublisher, to
> begin/commit_transactions
> in ZODB, but now I'm wondering if I would have been better to subclass
> SessionManager instead. My approach works, but any advice?  Quixote
> could use a sample app showing that, catching certain http responses
> and rolling back ZODB.

That "sample app" is our bread and butter, the MEMS Exchange "virtual
fab", ~40,000 lines of Python and PTL (and another 8,000 lines of
tests).  I'll attach our persist_session module; we do indeed subclass
SessionManager.  Oh, I'll also attach our driver script, vfab.fcgi --
this is where we handle database sync'ing and conflicts.

        Greg
--
Greg Ward - software developer                gward@mems-exchange.org
MEMS Exchange                            http://www.mems-exchange.org