[Zope] objects invisible

[Dylan Reinhardt]

At 02:06 AM 3/1/2003, Danny Nielsen wrote:
>Now the problem:
>Im a zope newbie and have startet making a product solely through Python

Nothing like jumping right in.... :-)

>(leaving the management interface behind!).

Really?

>Inside my product object I want to make a folder containing images.

I'm pretty sure you don't.  We'll see, though.

>  My problem is that when I create folders and images through Python it 
> aint visible in the management interface. How to I make them visible?

Make them Zope objects, not parts of your product instance.  The data in 
your product is only displayed if it is somehow referenced or created by 
your product's interface.

>Secund, can someone explain to me what implicit objects are available so 
>Im able to communicate with Zope

Not sure what those would be, to be honest.

>the docs API aint well documented

Perhaps not, but I don't think that's the essential problem here.

Every once in a while, newbies ask how to do something that seems simple 
and some crusty old timer feels the need to tell them they're going about 
it all wrong.  Well, here goes: it sounds like you're going about this all 
wrong.  Don't worry, though... it's all part of the learning process.

First off, products are not a replacement for the Zope Management Interface 
(ZMI).  All you do when you create a product is give yourself the ability 
to add a new type of object through the ZMI.  But just doing that is a very 
powerful thing.

A product should be created when you have a need for something that 
exhibits a certain set of distinct behaviors that aren't easily created 
with existing objects.  It's possible, for example, that you've come up 
with a need for folders and images that are just too special to be 
implemented with boring old built-in folder objects and image 
objects.  Possible, but unlikely.

More likely, you've made the assumption that there's a need (or advantage) 
to build monolithic do-everything objects, one per application or 
site.  You *could* work that way, but you'll be missing a whole lot of the 
point of Zope and re-implementing stuff that other very smart people have 
already gone to the trouble of creating, testing, debugging and supporting.

What I would recommend is *not* starting by building your own 
products.  That would be a bit like picking up a programming language 
without bothering with the standard libraries.  Out of the box, Zope 
provides a wide range of flexible and powerful objects that can do a heck 
of a lot of stuff.  It's worth knowing about because it's powerful stuff to 
use and provides examples of some of the best thinking in Zope.

Understanding what these built-ins are and how they work will pay off big 
time when you get to building your own stuff.  No longer will you need to 
worry about how to create and serve your own folders and images, you'll 
know how to access and manipulate the built-in ones, which are likely to be 
well suited for your needs.  That will leave you free to focus your 
development time on building the things that Zope doesn't already give you.

This is not to say there's no possible reason to want to build your own 
folders and images... it gets done all the time.  I've done it too.  But 
it's not probably where you want to start and when you get there, you'll 
learn that you're probably talking about three products, not one.  And by 
then you'll know how to use the 99% of the built-in folder that works great 
and tweak the 1% you want to work differently.

I'd check out the Zope Book (both versions):
http://www.zope.org/Documentation/Books/ZopeBook/

Dieter's book:
http://www.dieter.handshake.de/pyprojects/zope/index.html#bct_sec_1

And the Zope Dev Guide, when you're feeling up to it:
http://www.zope.org/Documentation/Books/ZDG/current/index_html

After that, the best way to learn about how to make products is to download 
a bunch of them and rip into the source code.  By the time you're able to 
figure how CMF works, you'll be a jedi master.

That may not have been what you were looking for, but I hope it helps.

Dylan