On Apr 21, 2004, at 12:25 AM, Jason E. Sibre wrote:
> I will say, "You don't need that import in step 2."
>
> I'm attaching the version of qxdemo that I was left with after
> confirming it
> worked, in case you wanna run diffs or something.


I apologize for wasting people's time and energy. The problem was a
stray space in a filename: __init__ .py instead of __init__.py . All is
working as expected now.

However, I don't know how long it would have taken to find the error
without Jason's gracious  troubleshooting efforts. It was only by
one-by-one substituting of each file he supplied with each file I had
that I managed to discover it. Thank-you Jason, and Graham too, for
your input and suggestions!

Here's what I've learned so far about quixote programming during this
little excursion of making qxdemo work as a .cgi application:

* Center the publishing on the 'ui' directory. That's where the .ptl
files go; other files go elsewhere in the package depending on their
function.

* qxdemo has a slight spelling bug in it: _q_export should be
_q_exports in qxdemo/ui/__init__.py

* You can't (at present) use __init__.ptl files. Perhaps my desire to
put the _q_index method in __init__.py is rather non-standard? (I tried
the patch that Graham referenced, but I couldn't get it to work in
Quixote 1.0b1.)

* URLs that point to directories need a trailing slash; URLs that point
to methods in files don't. (I guess that's pretty basic, but I've never
really had to be concerned with it before. I suppose it's because URL
termination was always *.html or *.jpg or some other extension in my
previous web programming efforts. Quixote appears to do away with file
extensions in the URLs.)

* What I'm still learning is how and where to distribute the exporting
of names. For now, I'm planning to keep everything as 'local' as
possible. But I do realize that if I have to reach down or up or across
the file structure to get to a function or method, I can. It helps to
know that I don't have to also import names just to get them published.
As I understand it, importing of names is just for the use of the
methods and classes in the files. Keeping these two concepts separate
and clear (importing for internal code use; exporting for URL
visibility) will be important until they are second nature.

> I think Quixote is appealing because of it's elegant simplicity.
> Consequently, it's sometimes surprising how subtle little details can
> bite
> you in a big way.  I'm not sure if this is because Qx is still a little
> rough around the edges, or if it's because the core developers did
> such a
> good job of making things appear simple, when they really aren't...
> Either
> way, as simple as it looks, there's a LOT of room for complexity in
> Quixote!

I'm slowly getting a grip on this style of web development, and having
simple, working code to start with is invaluable. If anyone is
interested, my coding background consists of Lasso and Filemaker. But
I'm migrating to Python and have searched for quite a while to find a
suitable web development environment. Quixote (and the REST approach)
seems to fit my cognition the way Python itself does. (At least from
reading the documentation; we'll see how it plays out in practice...)

Thanks again,

John Miller