RE: [Zope] FYI: Portal Toolkit Slides and Demo available
Andrew wrote:
Waiting on tenterhooks... Yesterday I read Philip Greenspun's book on Web publishing (http://www.photo.net/wtr/thebook/), and much of what he suggests seems like a natural fit to the Portal Toolkit. I'd recommend everyone check it out; the complete book is on-line, though it's well worth buying just for entertainment value.
Perused through it earlier this week -- looks interesting.
I've never pushed strongly for using Zope on our Web site (www.mems-exchange.org) for a few reasons:
1) Another programmer had already done some work with Java servlets, so we have some servlets to do various things. However, I've found that Java is really awful and cumbersome for Web programming. (But without automatic reloading of ExternalMethods, Zope isn't much *less* cumbersome for tasks that can't be handled in DTML.)
Hmm, I'm surprised that you'd advocate automatic reloading, as it would (at a minimum) stat a file on each request. Do you think it should be an optional knob to specify whether to check for changes? If so, what should be the default?
2) A fair amount of source code reading is still required, and Zope is so full of cutting-edge Python technique that it's not easy even for a long-time Python like me; for a new Python user, it would be deadly.
Not being too much of a programmer, and having tremendous respect for your programming, I'll of course have to cede this point. Would better documentation help? For instance, we intend, once Zope2 has landed, to begin the process of doing a UML model for all of Zope. We are already doing it for all new work. This includes many of the diagrams, including use cases. How helpful would that be? Second, we intend the UML model to formalize and document a "Zope API". Would having a clear statement of such a beast, for all things Zope including database adapters etc., significantly change your above statement? Farther out, we'd like to look at moving to Jim's "interfaces" proposal that was mostly agreed to at SPAM Houston. If we did (and then lived by it :^), how much would that help? If, in the end, Zope's fundamental ideas (acquisition, the Zope class model, etc.) are just too esoteric, then the above won't help.
3) I still haven't really figured out what the idioms are for implementing complicated forms. DTML is sufficient for simple forms with 2 or 3 fields, but if you have a 22-field form with complicated interactions between fields, DTML won't cut it. At DC, do you write ExternalMethods for such purposes, or full-blown products? How do you debug them without going insane from manually reloading ExternalMethods all the time?
Nearly everyone here spends a lot of time in the Python debugger instead of sitting in Zope, I think. I agree that debugging DTML is maddingly hard. In fact, I think about this probably fifty times a day. I sure hope, after Zope2 comes out, we step back and think HARD about things like usability. I presume by the leading part of the question that you would feel more comfortable doing your processing in Python than all-DTML. If Zope had a "Python Method" object, perhaps only usable by VERY privileged users, perhaps only in the Control Panel (say, in a Product), would that help?
However, the Portal Toolkit may well prove to be the wedge for getting
Just the kind of effect we were hoping for :^)
Zope on the site. I've already done a few simple Java servlets for registering users and presenting customized pages for a user, the intention being to turn www.mems-exchange.org into a specialized portal aimed at MEMS researchers and users of our virtual fab. People would have a single page which listed all of their ongoing jobs, recent status changes ("Your etch step #4 has completed; click here for metrology data"), MEMS news of interest to them, and similar info. If the Portal Toolkit could be used for this, it would save a *tremendous* amount of effort and wheel-reinventing. if you need someone to try out an alpha, let me know...
Heh heh, if I had a dime for the number of alpha volunteers for the portal toolkit :^) In the end, the presence of Z Classes, Z Class-based portal toolkit components, and a really nice search system out to make the portal toolkit something that more people will look at. We still have our work cut out for us, but we are awfully excited about it. Just an update on status. We're a bit behind -- our UML modelling tool apparently has a number of bugs that causes us to consistently get ureadable models. The vendor is mostly responsive but it still has caused things to grind to a halt here for the last week. Sigh. Thus, it's iffy whether zope.org will get its June reinvention, which is the predecessor step to checking everything into CVS. We are planning to revise our schedule at the end of next week. --Paul Paul Everitt Digital Creations paul@digicool.com 540.371.6909 ----------------------------------------- The Open Source Zope application server http://www.zope.org/ -----------------------------------------
On Thu, Jun 10, 1999 at 03:29:02PM -0400, Paul Everitt wrote:
Hmm, I'm surprised that you'd advocate automatic reloading, as it would (at a minimum) stat a file on each request. Do you think it should be an optional knob to specify whether to check for changes? If so, what should be the default?
I'd like a really easy way to reload external methods. It probably shouldn't be automatic, but it should be simple and obvious.
I presume by the leading part of the question that you would feel more comfortable doing your processing in Python than all-DTML. If Zope had a "Python Method" object, perhaps only usable by VERY privileged users, perhaps only in the Control Panel (say, in a Product), would that help?
This would be absolutely wonderful if done right. Ideally, it should be possible to export Python methods with the rest of a site. Supporting this might require some new security work, though.
Heh heh, if I had a dime for the number of alpha volunteers for the portal toolkit :^)
Ooooh! Pick me! Pick me! ;-) Cheers, Eric
Eric Kidd wrote:
On Thu, Jun 10, 1999 at 03:29:02PM -0400, Paul Everitt wrote:
Hmm, I'm surprised that you'd advocate automatic reloading, as it would (at a minimum) stat a file on each request. Do you think it should be an optional knob to specify whether to check for changes? If so, what should be the default?
I'd like a really easy way to reload external methods. It probably shouldn't be automatic, but it should be simple and obvious.
I really miss external methods reloading when I'm debugging. Why not automatically reload them when the environment variable ZOPE_DEBUG_MODE is set? -- Paulo Eduardo Neves mailto:neves@inf.puc-rio.br PUC-Rio de Janeiro
Paulo Eduardo Neves wrote:
Eric Kidd wrote:
On Thu, Jun 10, 1999 at 03:29:02PM -0400, Paul Everitt wrote:
Hmm, I'm surprised that you'd advocate automatic reloading, as it would (at a minimum) stat a file on each request. Do you think it should be an optional knob to specify whether to check for changes? If so, what should be the default?
I'd like a really easy way to reload external methods. It probably shouldn't be automatic, but it should be simple and obvious.
I really miss external methods reloading when I'm debugging. Why not automatically reload them when the environment variable ZOPE_DEBUG_MODE is set?
My suggestion, which I made in Collector Item #67 a few weeks back, is to have a toggle switch in the Control Panel. Cheers, Martin
Paul Everitt writes:
Hmm, I'm surprised that you'd advocate automatic reloading, as it would (at a minimum) stat a file on each request. Do you think it should be an optional knob to specify whether to check for changes? If so, what should be the default?
I think it would have to be adjustable, defaulting to off (no stat(), no reload).
Would better documentation help? For instance, we intend, once Zope2
To some degree, though the need is much higher-level than UML documentation. For example, one problem was simply uncertainty over whether the ExternalMethod was in fact the best approach. Also, so far I've only feebly attempted to use the debugger with Zope, but should probably make a focused effort to get that working, perhaps in concert with Emacs' debug-mode.
I presume by the leading part of the question that you would feel more comfortable doing your processing in Python than all-DTML. If Zope had a "Python Method" object, perhaps only usable by VERY privileged users, perhaps only in the Control Panel (say, in a Product), would that help?
Probably not; the problem isn't so much understanding a completed method, as in debugging a non-working method. A Python Method object would simply provide another way to type in code that would then be exceedingly painful to debug. -- A.M. Kuchling http://starship.python.net/crew/amk/ Chemistry is physics without thought; mathematics is physics without purpose. -- Anonymous
On Thu, 10 Jun 1999, Andrew M. Kuchling wrote:
Paul Everitt writes:
Hmm, I'm surprised that you'd advocate automatic reloading, as it would (at a minimum) stat a file on each request. Do you think it should be an optional knob to specify whether to check for changes? If so, what should be the default?
I think it would have to be adjustable, defaulting to off (no stat(), no reload).
Would better documentation help? For instance, we intend, once Zope2
To some degree, though the need is much higher-level than UML documentation. For example, one problem was simply uncertainty over whether the ExternalMethod was in fact the best approach. Also, so far I've only feebly attempted to use the debugger with Zope, but should probably make a focused effort to get that working, perhaps in concert with Emacs' debug-mode.
I presume by the leading part of the question that you would feel more comfortable doing your processing in Python than all-DTML. If Zope had a "Python Method" object, perhaps only usable by VERY privileged users, perhaps only in the Control Panel (say, in a Product), would that help?
Probably not; the problem isn't so much understanding a completed method, as in debugging a non-working method. A Python Method object would simply provide another way to type in code that would then be exceedingly painful to debug.
It is a point here, that debugging is often a focused, time-intensive affair on a non-production platform. Granted that there may be inherent challenges in the code that I cannot predict, it seems to me that a knob in the Method object permitting you to turn on an 'auto-reload' that uses stat() EVERY time the Method is accessed would be an invaluable tool during the writing/debugging phase. Obviously this would have to be disabled subsequently, before the Method is used in a production environment, but for someone trying to debug their code, a stat() is a hell of a lot less overhead than having to surf to the Method, reload and surf back to the test spot!
-- A.M. Kuchling http://starship.python.net/crew/amk/ Chemistry is physics without thought; mathematics is physics without purpose. -- Anonymous
_______________________________________________ Zope maillist - Zope@zope.org http://www.zope.org/mailman/listinfo/zope
(For developer-specific issues, use the companion list, zope-dev@zope.org - http://www.zope.org/mailman/listinfo/zope-dev ) -- Howard Clinton Shaw III - Grum St. Thomas High School #include "disclaimer.h"
participants (6)
-
Andrew M. Kuchling -
Eric Kidd -
Howard Clinton Shaw III -
Martin Dougiamas -
Paul Everitt -
Paulo Eduardo Neves