[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:
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