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 )
[Zope] FYI: Python product tutorial updated
Hi Brian, Regarding: 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... One of the features the stands when a newbies starts poking around at Zope.org is the wealth of contributed modules. Most of these were created as an aid to development, sort of a "make the process of creating a complex thing into a simpler process" approach. However, it's kind of like all the goodies available for Linux, or Perl, or Python itself, and any number of other Open Source projects that have generated lot's of add-ons. The problem is that finding time to try them all to see which turn out to be useful is another kind of complexity in itself. It seems like the Zope community should be able to benefit by leveraging all the great stuff that's there. On the other hand, the sheer volume turns out to be a barrier. I keep coming back to the notion of building a subset of the most useful, solid, and well documented modules into a "core" Zope distribution, so that they are available as "add" options without lot's unzipping, restarting, etc. Beyond that, a painless way to upgrade versions of all things Zope would definitely encourage folks to keep up with security fixes, and other improvements. Think about Debian's and FreeBSD's update tools. In order to get to the "consulting ware" vision of a more productiive Zope, "out of the box", this is the kind of thinking that needs to be adopted. We know there are wonderful and astounding things that are possible if you aren't afraid to get your hands dirty reading source code, but most folks expect anything they need to do to be sitting there waiting behind a menu option! This sounds to me like a higher level of object creation, Martijn Faassen's Formulator comes to mind, that can be selected and integrated into an existing site that has graphic standards already defined, which is itself another high level object that could help. 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. Thanks, Jerry S. ___ 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 "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
___
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
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 )
[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 )
