RE: [Zope] FYI: Python product tutorial updated
Brian, thanks for the reply ... I am currently more hopeful and feeling a little better about the amount of time and effort that I have put into Zope; knowing that the Zope book is coming also helps a lot. As someone else on the list replied, the obscurity problem will be partially solved with the book and others that will hopefully follow. I am in particular looking forward to some case studies that show how to use *and* why you should use some of the more complex Zope functionality. After being immersed in Zope for so long (about a year), I decided it was time to take a survey of the other tools out there - after doing a quick survey, I came away still unimpressed with most of them. I still think Zope requires more conceptual understanding (Zen?) that the other tools, but I'm still convinced that these concepts, many of which I am still yet to fully understand, offer far deeper and more elegant solutions to web development problems than the majority of the other tools. It's going to be tricky to achieve "optional complexity" - but that is exactly the nature of Zope. There are several levels or layers of Zen - after reaching each layer new potential ways to solve problems become possible. For instance, I know enough DTML and SQL to implement most of the functionality that I need and I have been writing my own ZClasses also. But I don't yet fully grasp the full possibilities of the Catalog, and Python/External Methods and I have had no luck getting any of the alternative User/Membership systems to work for me. These latter concepts/tools constitute my next level of complexity. Anyway, that's just my 2 cents Darcy > -Original Message- > From: Brian Lloyd [mailto:[EMAIL PROTECTED]] > Sent: Monday, October 02, 2000 11:23 AM > To: Darcy Clark; [EMAIL PROTECTED] > 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 ? > > 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[EMAIL PROTECTED] > Software Engineer 540.371.6909 > Digital Creations http://www.digicool.com > > > ___ Zope maillist - [EMAIL PROTECTED] 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 )
Re: [Zope] FYI: Python product tutorial updated
> 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 "" rather than "...", 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 ___ Zope maillist - [EMAIL PROTECTED] 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 )
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 ? 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[EMAIL PROTECTED] Software Engineer 540.371.6909 Digital Creations http://www.digicool.com ___ Zope maillist - [EMAIL PROTECTED] 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 )
RE: [Zope] FYI: Python product tutorial updated
> 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. ___ Zope maillist - [EMAIL PROTECTED] 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 )
Re: [Zope] FYI: Python product tutorial updated
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" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > 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 - [EMAIL PROTECTED] > 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 ) > > ___ Zope maillist - [EMAIL PROTECTED] 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 )
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 <[EMAIL PROTECTED]> 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 - [EMAIL PROTECTED] 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 )
