could anyone please comment regarding this link: http://www.amk.ca/python/writing/why-not-zope.html it's an article i read on why not to use zope. i just want to know if the author's rants are justified. TIA __________________________________ www.edsamail.com
Seems very misguided, and I think perhaps he is just very confused. For one thing putting ZClasses and Zope Products in the same category dosen't make sense to me. I tend to write a lot of Zope products as python modules and with that I get grep, I get CVS, I get test suites ... in fact there are tutorials around somewhere that show you how to run ZPublisher for debugging, it's an easy step to build the test suite around that. Next the talk about "Much of the application ends up as DTML" ??? that goes against most people's Zope philosophy, where DTML is a presentation layer ..... if you are writing your application in DTML and it works then well done!! but I wouldn't want to debug it. There is also this confusion with "dynamic scope", one of the most fantastic things about Zope is implicit acquisition. Sure it takes a bit to get a feeling for, but once you are there you start to organise your hierachies of attributes and methods into an environment that makes sense, and which is very powerful. If he is trying to build as they say "complicated objects", then through-the-web DTML is not really what they should be trying to do. Writing a python product would be the more obvious path. And if he/she finds editing in a Netscape text box so horrible for dtml and PythonMethods, then perhaps they could use their favourite editor and the nice FTP server that Zope comes with ... :-) Matt On Sun, 15 Apr 2001, Win GO wrote:
could anyone please comment regarding this link: http://www.amk.ca/python/writing/why-not-zope.html
it's an article i read on why not to use zope. i just want to know if the author's rants are justified.
TIA
__________________________________ www.edsamail.com
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev ) --
Win GO <theoden@edsamail.com.ph> said:
could anyone please comment regarding this link: http://www.amk.ca/python/writing/why-not-zope.html
it's an article i read on why not to use zope. i just want to know if the author's rants are justified.
I disagree that it is a rant - AMK gave Zope fair consideration, he carefully explains why it wasn't good for his purposes, and then even goes as far as pointing out the sort of websites that it would be good for. If you call that a rant, please point me to a piece you'd call a balanced critique. Having said that, and being in the same situation, I must say I agree 100% with every single point he makes. In fact, that's why I am currently looking for a way to put business code in a separate server process and let the Zope server talk XML-RPC to that. Zope at the moment is absolutely not suited for complex web application development, and it is absolutely great to build dynamic websites. Summary: Zope's a good tool, don't use it for the wrong job.
That's fine. Are we going to agree to disagree, or would you care to point out to me how you can do things like version management, have very complex code that you can easily maintain and evolve, manage security without having to scroll to a couple of hundred K of HTML tables, etcetera? chrisw@nipltd.com said:
Sorry, but all I'll say to that is that I couldn't disagree more ;-)
-- Cees de Groot http://www.cdegroot.com <cg@cdegroot.com> GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B
On 16/4/01 3:35 pm, "Cees de Groot" <cg@cdegroot.com> wrote:
, manage security without having to scroll to a couple of hundred K of HTML tables, etcetera?
Cees has a point here regarding the management of security. Does anyone know of any tools available to manage security without using the web interface. Does XML-RPC have a role (ho ho) to play here? Cheers Tone. -- Dr Tony McDonald, Assistant Director, FMCC, http://www.fmcc.org.uk/ The Medical School, Newcastle University Tel: +44 191 243 6140 A Zope list for UK HE/FE http://www.fmcc.org.uk/mailman/listinfo/zope
There is a belief inside DC that security is the domain of the administrator and therefore setting security info needs nothing other than the web interface. I'm sure some folks are going to say "that's nuts!", and personally I think you're right. A while ago a put up a proposal on dev.zope.org named ProductRoleManagement, which proposed to allow Product authors to manipulate roles. It was summarily shot down for the abovementioned reason. But I think what I was *really* trying to say ;-) was that security management needs an API for programmatic setting of roles and permissions (other than the current RoleManager stuff). I think this is a nobrainer, but the questions are: 1. What is the API? 2. What is the API's audience? Things like this are best worked out in the Fishbowl (http://dev.zope.org) via a proposal. ----- Original Message ----- From: "Tony McDonald" <tony.mcdonald@ncl.ac.uk> To: <zope@zope.org> Sent: Monday, April 16, 2001 12:17 PM Subject: Re: [Zope] zope rant
On 16/4/01 3:35 pm, "Cees de Groot" <cg@cdegroot.com> wrote:
, manage security without having to scroll to a couple of hundred K of HTML tables, etcetera?
Cees has a point here regarding the management of security. Does anyone know of any tools available to manage security without using the web interface. Does XML-RPC have a role (ho ho) to play here?
Cheers Tone. -- Dr Tony McDonald, Assistant Director, FMCC, http://www.fmcc.org.uk/ The Medical School, Newcastle University Tel: +44 191 243 6140 A Zope list for UK HE/FE http://www.fmcc.org.uk/mailman/listinfo/zope
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Tony McDonald <tony.mcdonald@ncl.ac.uk> said:
Cees has a point here regarding the management of security. Does anyone know of any tools available to manage security without using the web interface. Does XML-RPC have a role (ho ho) to play here?
I think that what Zope needs most is (and I've said that many times before - I even posted code so people can't accuse me of just shouting things ;-)) a "local" GUI. Take Python+ZEO+TkInter, and suddenly you have a whole set of options for security management. Directly talking through ZEO to the database is probably easier than stuffing XML-RPC in between... Apart from that, I think Zope's security model needs to be reviewed. As I'm currently churning out 100-hour workweeks, I haven't really spent much thought on how it could be improved, but somehow this whole proliferation of roles, coupled with extremely low "visibility" of who can do what, doesn't feel right. One of the reasons that I want to split off business code in a separate appserver is that I can "escape" the Zope security model. At the moment, I publish database records through a Python product that applies Zope security to them (e.g. the owner_id of a row gets the Owner role of the object that's published through Zope), and I must say that - apart from the work to get it to work - it doesn't give me a good feeling. Security must be simple, and the baroqueness of owners, local roles, permissions, and whatnot doesn't really support that goal.
Cees de Groot wrote:
That's fine. Are we going to agree to disagree,
Okay, you tempted me to say more ;-)
or would you care to point out to me how you can do things like version management,
Do you mean of content or code? Ask Paul about the 'all three layers managed content' model that DC is aiming for, he can probably explain it better than I...
have very complex code that you can easily maintain and evolve,
I use Python Products for this. Python Scripts have made life a lot better and the FS-range of stuff from the CMF will become more and more useful. Hopefully it'll end up in the core at some point...
manage security without having to scroll to a couple of hundred K of HTML tables, etcetera?
This one I agree with you on, there's a slow (and that's my fault ;-) thread on this on the CMF list. Maybe you'd care to chip in with some ideas? This is the real strength of Zope and open source in general: the power to change things that aren't as good as they could be :-) cheers, Chris
chrisw@nipltd.com said:
Okay, you tempted me to say more ;-)
And you said more, but almost all in the future tense. Gee, if it weren't for the great possibilities that Zope has, I'd probably had binned it a long time ago (plus, I am very sure, lots of others). I think we were discussing where Zope stands now, and that is (IMO) that it covers simple to moderate websites. On the other hand, when I'll get some time I want to check a multi-tier architecture (web client, Zope, business logic server, database) where the web-developers would get Zope, and the software developers would get Smalltalk. If a clean cut is possible, I think that it would be a near-ideal development environment. -- Cees de Groot http://www.cdegroot.com <cg@cdegroot.com> GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B
While the baroqueness of local roles, ownership, permissions, etc. hasn't changed much, the API for asserting permissions on methods within a Product has changed radically since Zope 2.3. It's much simpler now to "spell" security within a Product. For more info, see http://www.zope.org/Documentation/ZDG/Security.dtml (preview of Zope developer's guide). If __ac_permissions__ and __allow_access_to_unprotected_subobjects__ is the basis for the kvetch, it's no longer necessary to spell these things this way. - C
Apart from that, I think Zope's security model needs to be reviewed. As I'm currently churning out 100-hour workweeks, I haven't really spent much thought on how it could be improved, but somehow this whole proliferation of roles, coupled with extremely low "visibility" of who can do what, doesn't feel right. One of the reasons that I want to split off business code in a separate appserver is that I can "escape" the Zope security model. At the moment, I publish database records through a Python product that applies Zope security to them (e.g. the owner_id of a row gets the Owner role of the object that's published through Zope), and I must say that - apart from the work to get it to work - it doesn't give me a good feeling. Security must be simple, and the baroqueness of owners, local roles, permissions, and whatnot doesn't really support that goal.
I am not sure that I understand people's reservations with writing Python Products for complex situations?, with which you get so many nice development tools that we are so used to. Personally I couldn't fathom doing half the things I want to in Zope without using these, though the security issue is still one I find awkward. Is it DCs wish that one day people would not need to write Python Products? Matt On Tue, 17 Apr 2001, Cees de Groot wrote:
chrisw@nipltd.com said:
Okay, you tempted me to say more ;-)
And you said more, but almost all in the future tense. Gee, if it weren't for the great possibilities that Zope has, I'd probably had binned it a long time ago (plus, I am very sure, lots of others). I think we were discussing where Zope stands now, and that is (IMO) that it covers simple to moderate websites.
On the other hand, when I'll get some time I want to check a multi-tier architecture (web client, Zope, business logic server, database) where the web-developers would get Zope, and the software developers would get Smalltalk. If a clean cut is possible, I think that it would be a near-ideal development environment.
-- Cees de Groot http://www.cdegroot.com <cg@cdegroot.com> GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev ) --
--On Tuesday, April 17, 2001 08:30:28 +1200 matt <matt@virtualspectator.com> wrote:
I am not sure that I understand people's reservations with writing Python Products for complex situations?, with which you get so many nice development tools that we are so used to. Personally I couldn't fathom doing half the things I want to in Zope without using these, though the security issue is still one I find awkward. Is it DCs wish that one day people would not need to write Python Products?
Not as far as I know. If anything, we've heard the critique loud and clear and are investigating how to represent the 'rich' information in the ZODB as a 'flat' filesystem. What we're hoping for is that it would allow you to manage artifacts in the ZODB using tools you are used to, ala grep, CVS, etc. So write Python Products with confidence :) -- ethan mindlace fremen zopatista community liason
ethan mindlace fremen <mindlace@digicool.com> said:
Not as far as I know. If anything, we've heard the critique loud and clear and are investigating how to represent the 'rich' information in the ZODB as a 'flat' filesystem. What we're hoping for is that it would allow you to manage artifacts in the ZODB using tools you are used to, ala grep, CVS, etc.
I hope everyone at Digicool has worked with Smalltalk. No flat filesystem in there, and somehow no need for it, because the IDE does everything you normally need (and more than grep - grep cannot give you a list of all methods that call another method from their body, and this sort of stuff is accessible in Zope).
For what it's worth, Jim Fulton was on the ANSI Smalltalk committee. :^) --Paul News system wrote:
ethan mindlace fremen <mindlace@digicool.com> said:
Not as far as I know. If anything, we've heard the critique loud and clear and are investigating how to represent the 'rich' information in the ZODB as a 'flat' filesystem. What we're hoping for is that it would allow you to manage artifacts in the ZODB using tools you are used to, ala grep, CVS, etc.
I hope everyone at Digicool has worked with Smalltalk. No flat filesystem in there, and somehow no need for it, because the IDE does everything you normally need (and more than grep - grep cannot give you a list of all methods that call another method from their body, and this sort of stuff is accessible in Zope).
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
matt <matt@virtualspectator.com> said:
I am not sure that I understand people's reservations with writing Python Products for complex situations?, with which you get so many nice development tools that we are so used to. Personally I couldn't fathom doing half the things I want to in Zope without using these, though the security issue is still one I find awkward. Is it DCs wish that one day people would not need to write Python Products?
It might just be that I want too much. In itself, there's nothing much wrong with writing Python Products, except for the annoying bit that you need to refresh the product every time you change a line of code and want to test, or worse - restart Zope when you change a line of code outside the product's package. Which is a pity, because Zope "TTW" comes close to the Smalltalk "execution server" model which is so great in supporting fast coding, and you lose that when you go to Python products - to an extent, it feels like compiling... That's why I would prefer writing unrestricted code in Zope with a good IDE instead of TTW (this is, I think, quite possible if the unrestricted code is outside the Application tree, thus not accessible through-the-web). It would neatly bypass the issues some people have with Python being file-based ;-), and I think mixing Python/DTML/SQL methods is an terrible great way of developing rich classes. There are also some minor gripes, especially with security, but it seems that these are being solved as we speak.
Win GO wrote:
could anyone please comment regarding this link: http://www.amk.ca/python/writing/why-not-zope.html
it's an article i read on why not to use zope. i just want to know if the author's rants are justified.
TIA
This article raises legitimate points. Zope is a difficult and somewhat opaque system to learn. If it were not open source, it would be nearly worthless to me and a I would not use it. However, Zope is open-source and written in one of the most readable computer languages. But like many things that are difficult to learn such as walking, driving and computer programming in general, there are worthwhile, tangible rewards to spending time and energy learning Zope. If there were not, I would not be writing this email. Many of the points raised in this article point to ignorance of developing in Zope. Everytime I have run against problems that cannot be solved well with Zope's built in tools, I have fallen back to using the amazing extensibility of Zope to get the job done. This extensibility (owing much to Python), and no other feature, is the main reason I continue to learn and use Zope today. No Zope is not perfect, far from it. But the pace at which this community can attack specific problems when they put their mind to it is impressive. Zope does require more of a commitment than most other computer software I have used. In my mind, however it is worth it. -- | Casey Duncan | Kaivo, Inc. | cduncan@kaivo.com `------------------>
participants (10)
-
Casey Duncan -
cg＠cdegroot.com -
Chris McDonough -
Chris Withers -
ethan mindlace fremen -
matt -
news＠cdegroot.com -
Paul Everitt -
Tony McDonald -
Win GO