[Zope] Product Creation Comments

[Martijn Faassen]

[note: for some reason my previous attempts to mail this to the list
resulted in a bounce; I'm not sure if this my fault, a fluke, or
something more serious. I'm trying again..]

Paul Everitt wrote:
> Martijn wrote:
[some of my troubles with Zope product creation]
> 
> You should use the Zope debugger for writing Zope Products:
> 
>   http://www.zope.org/Documentation/Reference/Debugger

I knew about the Zope debugger, but I hadn't seen this particular bit of
information yet, I think (the command like arguments and such :).

> It's the Python debugger with enhancements to jump right to your object
> being published, with a carefully crafted environment resembling an HTTP
> request.
> 
> With this you are back in the (for you familiar) world of Python, Emacs,
> and pdb.
> 
> Is this a useful thing for you?

Yes, it would be, but see my (and your) later comment in this post.

What I also did:

After repeated stumbling in the dark I hacked up the Emacs python mode
so that doing C-c C-c in JPython mode (which I didn't use anyway, get
there by C-c C-t) start's up Zope's python. This didn't work entirely
correctly; I still had problems importing things:

I can do:

import AccessControl 

However, something like this:

class Poll(
    AccessControl.Role.RoleManager
    ...
    ):

gives:

AttributeError: Role

This may be just because I'm trying to do things that you shouldn't.

[snip]
> > The big gap trouble starts here. Suddenly, we don't import
> > DocumentTemplate anymore, instead we do a 'from globals
> > import HTMLFile'
> > for general DTML support. We also import a number of other things.
> > Suddenly I can't test anything anymore - not with a python
> > test function
> > or with the zope debugger, it seems. I get an error message that
> > complains about the variable 'trueself' that was omitted from the
> > request.
> 
> Ahh, I see.  If you *could* stick with the Zope debugger, would this be
> an answer for you?

That would make things a whole lot easier. If I could at least test
things repeatedly I'd know at least the basic *syntax* is okay. Also
it'd be useful to test out DTML (like one can do early on in the product
creation process).

[snip my problems of not being able to test my product after a certain
point]
> This is *precisely* the kind of feedback we need.

Ooh, I'm glad. :)

> > feedback on any of these. Then finally, I can install the
> > poll and test
> > it.
> 
> We realize that we aren't making it friendly at all for people to write
> products.  In fact, we are probably making it so hard that I should send
> out medals to those that do it :^)

No medal for me yet then. :) I know you people realize it, I just wanted
you all to realize it a bit more.
 
[too many steps in product creation - is this Pythonic?]
> It's a shame we haven't articulated it very well because it really is a
> pretty Pythonic way of doing things.  However, it currently is about
> like writing Python apps without the library reference.

Hm. That'd be somewhat complicated. More reference material would help,
yes. Or if it's there some pointers in the right direction. I now know
vaguely what OFS.SimpleItem is, but I still haven't a clue on how to
create Folderish products. Also no good way to evaluate if Folderish
products would suit my purposes.
 
> > * A way to test each step somewhat better. Feedback from Zope telling
> > you if you're still on the right course.
> 
> Hmm, explain.

Well, a functional Zope debugger (after the point I indicated) so that I
could see my script crash would be good feedback. That's Zope telling me
I'm *not* on the right course.
 
> > * A more automated process of poll creation. I'm starting to

Oops, 'product creation' not 'poll creation'.

> > think about
> > what this should look like. I can probably eventually help with
> > design/implementation, if I keep butting my head at product creation
> > enough.
> 
> I believe Amos suggested something like this previously.  Basically,
> something that would ask you a few questions then write out a bunch of
> prototype code.

It might also be possible to extract some information from the main
(still Python) product class. And ask some extra question and then
indeed write some code.
  
[snip]

> > I want to see more products for Zope. I want to *make* products for
> > Zope. If it were easier somehow, there would be more products
> > for Zope, which would be good for everybody.
> 
> Ahh, now you are sweet-talking us. :^)

Sure, I realize I have to motivate you guys to improve this (not that
you're not motivated already, but a little bit of extra motivation isn't
ever bad :). I'm not paying you guys anything, after all (see commercial
elsewhere in this thread). I *am* part of the fabled 'massive peer
review' open source development community though. :)

> > Enough of my lament. I hope it helps somebody else; otherwise
> > ignore all as frustration relief. And again, I do like Zope.
> 
> It's hard for us to know where to start.  We got a <FLAME> yesterday
> from the exact opposite: more examples with no Python, all DTML.

Of course this would be useful to too. I don't tend to be too worried
about DTML myself, but it's true I've stumbled through it a bit too at
times (where are things in namespaces, ZopeTime in the docs is still
PrincipiaTime (at least in 1.9), making forms work right). In the case
of DTML I usually can figure it out eventually though.

> We also get complaints about debugging the process of getting it started
> (apparently Apache configuration is our business as well).

It was tricky to get that going on NT (I think Apache 1.3.3. for NT
didn't come - or I missed it - with a rewrite module, 1.3.4 certainly
does though). Of course one shouldn't use NT for this (IMO), but tell my
boss. Or better yet, tell internal politics. :)

> It's hard to know where to start, as it is all important.
> 
> Do you feel that a format like Amos' tutorial is the best one?  Or a
> bunch of sample products?  Or a reference guide?

I like Amos' tutorial; it gets me started. It's usually easy to
understand each step he points out. A reference guide would be useful,
too. I don't care too much at this point about sample products; they
might be more useful if there's a reference guide, so you can look up
unfamiliar stuff you find in them in the guide.

Most importantly for me is a way to continue debug though. I don't even
mean stepwise debugging (I've hardly felt the need for that in Python
yet!), just a crash and a linenumber. What would also take away some of
the frustration is, as mentioned before, some automation (for instance
in generating the DTML creation and edit forms).

Thank you for your reply, and regards,

Martijn