RE: [Zope] Product Creation Comments
Martijn wrote:
Then we add the user interface with DTML. After some initial learning with DTML, this step is easy too. It's just a question of importing DocumentTemplate and adding a single attribute to the class (index_html). Minor stumbling block is that the non Zope python doesn't have the Zope modules on its module search path. Adding them resolves this; I'm not sure however if I fixed it completely (insert completely vague failures and complaints here :).
You should use the Zope debugger for writing Zope Products: http://www.zope.org/Documentation/Reference/Debugger 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?
You can test the generated HTML easily in a python test function, then. Minor step.
Then we have a publishable object. We can test it with a test_poll.py file that creates the object to be published. We can call the Zope debugger to see if it all comes out okay. No problem.
Now we try to make the leap from publishable object to Zope product. The tutorial says there is a long way between these two; and there is!
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?
So after this I can't test things anymore. I still need to make a creation form and a product installation method. In the tutorial it mentions the process of turning publishable product into product is a bit tedious and that in the future there will perhaps be a more streamlined process. I hope this future arrives soon, as after this,
Obviously we're open to specific suggestions about improving it.
still without apparant ability to test, I need to add a producting editing form, a product editing method, define Zope permissions, management tabs, a meta type, and a product icon. The system gives no
This is *precisely* the kind of feedback we need.
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 :^)
This is too big a bound for me, somehow. I am able to do all the steps, but I keep getting bogged down, starting over, knowing I can't test anything yet. It breaks the quick Python development cycle; it's even slower than my C++ development cycle. There are too many steps that don't seem to fit into my short term memory. Part of the program design I do during prototyping. I can't seem to do this with products.
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.
A way to resolve this would be:
* A lot more practice by me. I'm doing this. :)
* A way to test each step somewhat better. Feedback from Zope telling you if you're still on the right course.
Hmm, explain.
* A more automated process of poll creation. I'm starting to 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.
* I'm missing something. "Martijn, when I create a product I do so and then so and it's really easy and quick."
* products are beyond Martijn's feeble mind and he just should give up. :)
Never!
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. :^)
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. We also get complaints about debugging the process of getting it started (apparently Apache configuration is our business as well). 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? --Paul Paul Everitt Digital Creations paul@digicool.com 540.371.6909
On Fri, Feb 12, 1999 at 11:24:53AM -0500, Paul Everitt wrote: ,----- | 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. We | also get complaints about debugging the process of getting it started | (apparently Apache configuration is our business as well). | | 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? `----- You'll probably get 500 different opinions on this (if you get a response from all 315 readers of the Zope list). My opinion is that once you have a good set of baseline docs that 1) describe the theory and process and 2) offer reference material for necessary methods/variables, you should concentrate on examples. I've always found it much easier to get going with something if I've got access to examples that do similar things to what I'm trying to accomplish. Over time, my understanding will improve and I'll be able to do more complex things more gracefully, but at least I was able to make things work from the get-go. At this point, I'm inclined to say that the baseline documentation is there and is pretty good. I'd love to see a lot more examples. I think the idea of including a bunch of examples in the default DB is a great one. Having the DTML source on the Zope site has helped. If it is trivial to do, you could make the <!--#var --> tags show up as links to the source for that object. That would make it easier for people to get to the sidebar code, for example. (This is not something I'd spend a lot of time on though, because I'm sure other people can cut and paste into the URL as easily as I can :) I also think that once some of the Zone code starts coming out, people will start getting all sorts of new ideas and will be able to learn a lot from that code. Kevin -- Kevin Dangoor kid@ans.net / 734-214-7349
On Fri, 12 Feb 1999, Paul Everitt wrote:
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 :^)
Actually, after I'd done a couple and understood the interconnectedness of all things, I found it really quick and easy. The Zope framework _easilly_ makes up for the added work over ZPublisher. The only thing that bugs me is the tedium of setting up the creation and editing forms. It seems to me that Zope aught to be able to generate them on the fly, perhaps with a few hints in the class. Am I out to lunch on this? Mike. -- --- | Mike Pelletier Work: 519-746-1607 /opeware! | Software Developer Home: 519-725-7710 --- | mike@zopeware.com Fax: 519-746-7566 http://www.zopeware.com | Zopeware is not endorsed by Digital Creations
[my previous attempt to post this bounced] Mike Pelletier wrote:
On Fri, 12 Feb 1999, Paul Everitt wrote:
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 :^)
Actually, after I'd done a couple and understood the interconnectedness of all things, I found it really quick and easy. The Zope framework _easilly_ makes up for the added work over ZPublisher.
You have the advantage you know ZPublisher, I think. I just dove in straight away. And you're right, inclusion of the product in the Zope framework is very useful and nice.
The only thing that bugs me is the tedium of setting up the creation and editing forms. It seems to me that Zope aught to be able to generate them on the fly, perhaps with a few hints in the class. Am I out to lunch on this?
I'd like some automatic generation of these too. However, I think there's a limit on how much one can automate this. A product class might have all kinds of subclasses which need to be set up in the creation/edit form, for instance. But some basic automation to get at least something going would be nice. Regards, Martijn
[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
participants (4)
-
Kevin Dangoor -
Martijn Faassen -
Mike Pelletier -
Paul Everitt