re: [Zope] FYI: Python product tutorial updated
This tutorial looks great...it explained a lot of things to me that I wasn't able to put together before. But...on looking at it, a nagging thought keep recurring...this is a really quite long and complicated process for a Poll product. As much as I like Zope and thing it is a great platform on which to develop web applications, I often wonder about the complexity and obscurity of some of the procedures that need to executed while making what are, on the face of it, often quite simple web objects or applications. Consequently I have honestly had quite a hard time convincing PHP-savvy colleagues that the path to Zope Zen is something worth starting on. Does anyone else experience these nagging doubtful thoughts occasionally ? Darcy -------------------------------------- From: Shane Hathaway <shane@d...> Date: Fri Sep 22, 2000 11:56am Subject: [Zope] FYI: Python product tutorial updated The Python product development tutorial has been updated to reflect current practices. It is accompanied by a working product that contains all the sample code (which should also replace the "Boring" product.) It will likely be included in the Product Developer's Guide. See http://www.zope.org/Members/hathawsh/TutorialUpdate . Shane
But...on looking at it, a nagging thought keep recurring...this is a really quite long and complicated process for a Poll product. As much as I like Zope and thing it is a great platform on which to develop web applications, I often wonder about the complexity and obscurity of some of the procedures that need to executed while making what are, on the face of it, often quite simple web objects or applications. Consequently I have honestly had quite a hard time convincing PHP-savvy colleagues that the path to Zope Zen is something worth starting on.
You need to make a delineation between making products and using zope. One can use the power of zope without building a zope product. A couple of ZSQL Methods, some PythonMethods, and a little DTML go along way in building a cool dynamic website. So my methodology has been to show them the simple power of zope and then later expose them to building products.
To address some adjectives: Complex - it's complex because there's a lot going on. Consider the nature of the security machinery. What other platform lets you grant permissions on such a granular basis? How would you lend people the ability to script things through the web securely in, for example, PHP? I know that in many situations it's overkill, such as in creating a Poll product. There are a lot of hoops to jump through that you may not care about while creating such a simple product. But in more complex applications, those hoops are requirements. One of the goals of ZClasses is to reduce the amount of work required to create a Product. They don't succeed on all levels, but the scope of this Poll product is somewhere that I think ZClasses would shine. Obscure - it's obscure only because it's not documented properly. Once it's documented properly, it will no longer be obscure. ----- Original Message ----- From: "Darcy Clark" <darcyc@engin.umich.edu> To: <zope@zope.org> Sent: Monday, September 25, 2000 11:49 AM Subject: re: [Zope] FYI: Python product tutorial updated
This tutorial looks great...it explained a lot of things to me that I wasn't able to put together before.
But...on looking at it, a nagging thought keep recurring...this is a really quite long and complicated process for a Poll product. As much as I like Zope and thing it is a great platform on which to develop web applications, I often wonder about the complexity and obscurity of some of the procedures that need to executed while making what are, on the face of it, often quite simple web objects or applications. Consequently I have honestly had quite a hard time convincing PHP-savvy colleagues that the path to Zope Zen is something worth starting on. Does anyone else experience these nagging doubtful thoughts occasionally ?
Darcy --------------------------------------
From: Shane Hathaway <shane@d...> Date: Fri Sep 22, 2000 11:56am Subject: [Zope] FYI: Python product tutorial updated
The Python product development tutorial has been updated to reflect current practices. It is accompanied by a working product that contains all the sample code (which should also replace the "Boring" product.)
It will likely be included in the Product Developer's Guide.
See http://www.zope.org/Members/hathawsh/TutorialUpdate .
Shane
_______________________________________________ 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 )
This tutorial looks great...it explained a lot of things to me that I wasn't able to put together before.
But...on looking at it, a nagging thought keep recurring...this is a really quite long and complicated process for a Poll product. As much as I like Zope and thing it is a great platform on which to develop web applications, I often wonder about the complexity and obscurity of some of the procedures that need to executed while making what are, on the face of it, often quite simple web objects or applications. Consequently I have honestly had quite a hard time convincing PHP-savvy colleagues that the path to Zope Zen is something worth starting on. Does anyone else experience these nagging doubtful thoughts occasionally ?
I think yours is a valid criticism. Zope provides the infrastructure to do a lot of powerful and complex things, with the downside that (currently) as a developer a lot of the details are "in your face". One major goal I have for Zope going forward is to strive for "optional complexity" - not only for day-to-day use of Zope but also for component developers. I'd be very interested to hear any ideas you folks have on ways to help "make simple things simple" for development and to allow people to deal with complexity only as they begin to need it... Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com
I'd be very interested to hear any ideas you folks have on ways to help "make simple things simple" for development and to allow people to deal with complexity only as they begin to need it...
I entirely agree with Jerry's points about the standard zope distribution. There are various architecture / grammar / security issues that need to be adressed in Zope. However, I believe a much higher priority should be given to a rationalised set of documentation, plus a core set of products and templates, to be included with the standard Zope distribution. It should be easier to upgrade or add modules; I read a suggestion somewhere that a product standard should be produced, to which all products must conform (package layout, etc). Here's my thoughts in more detail, FWIW: Who are the target users of zope? My personal take is: 1) application developers (in the unzoped world, java, php, perl hackers) 2) interface developers (html coders, designers) 3) content managers I've been using zope for about a month now, (and *thinking* about using it for more than a year!) and my thoughts on simplicity for these users are: 1) application developers Application developers should *expect* a steep initial learning curve. Even python took me a little while to get my head round, but it was worth it. PHP is only easy because it follows a paradigm that people have learned elsewhere. There's no point trying to shield application developers from the complexity of zope. But we need to hold their hand until they can do it by themselves. The _ONLY_ hurdle to my zope enlightenment is (surprise) the documentation. In particular, what consistently holds me back is the lack of api documentation. I'd like to see something like javadoc-style API descriptions. I know, it's open source, I could do it myself. I know, I'm covering old ground. But I can't state enough how immensely frustrating it is to spend 5 hours trying to work out how to do something that you *know* you could do in 5 minutes in PHP. I don't know much about the ZDP and I'm sure they're putting in a lot of effort, but my feeling is that it is _very_much_ in the best interests of DC to promote a decent set of references. Even something as simple as repackaging the ZQR and including it in the standard distribution would be a start. When I get some time I'd love to help with this. 2) dtml is too much like a programming language and I'm finding it a big effort to abstract the logic away from DTML sufficiently. Interface developers want "<dtml-var latest_news>" rather than "<dtml-in objectIds('news')>...", etc, in their HTML. The mechanisms for doing this are already present in zope but the onus is too much on the application designer to come up with ways of doing this. I always end up doing application logic in DTML documents because it's easier (and _quicker_) than spending a while coming up with an abstract design and then coding it all in python and loading it as External methods and then having to debug it all. Efforts like ZPatterns and the PTK are the way forward here: toolkits and design patterns that make common tasks easier. A project to come up with patterns and toolkits for common template-building tasks would be valuable. It should also be easier for application developers to create custom DTML tags. There should be a simple way to package tags and install tags, and then a library could be started on zope.org. For example, a question recently posed on the mailing list was how to include the contents of another web page in your own document. The obvious answer is an External method - however, wouldn't it be neater to encapsulate this functionality in a tag? (i'm sure this debate has been worked through before...)
... A Graphic Standards "Template" that can be applied in the form of a "wrapper", and can be adjusted trough a forms based interface with options for colors, type style, background images, etc.
3) I understand skinnable CMS interfaces are on their way. At the moment I have to re-code the whole management interface from the bottom up for each client, which is a real drag. I'm really looking forward to this feature. Seb
participants (5)
-
Brian Lloyd -
Chris McDonough -
Darcy Clark -
seb -
Steve Drees