Something better than ZClasses (was: Re: [Zope-dev] Re: Zcatalog bloat problem (berkeleydb is a solution?))

[Stephan Richter]

>Python Products.

Ok.

> > 3. Okay, here we should have a loop of enter images with upload
> > functionality. The only problem is where do we save them in the mean time?
>
>Upload?  Upload to where?
>
>mk-zprod (as it works today) creates a directory on your filesystem, and
>in that directory (which you just copy to your Products directory) it
>creates an img/ directory and puts them there.

Well, but where are the images coming from. The Wizard is a Web Frontend, 
so we would need to upload the images or copy them from somewhere else from 
the file system.
BTW, the /img directory is non-standard. Better would be www/ since other 
products use it as well.
In fact, we only need to think about adding them with the right permissions 
to the directory. A piece of code in the __init__.py will do the rest:

# load all the icons automatically
from Globals import package_home, ImageFile
misc_ = {}
path = os.path.join(package_home(globals()), 'www/')

for file in os.listdir(path):
     if file[-3:] == 'gif':
         misc_[file[:-4]] = ImageFile('www/%s' %file, globals())


>Or are you asking where the wizard should store them?  (Which I thought it
>didn't have to.)

Well, you can take two approaches here:
1. As soon as the user uploads the icon, we are adding it to the directory. 
This is a problem, if you want to undo some or all of the wizard actions, 
but is much easier to implement.
2. When the icon is uploaded, save it somewhere temporarily. At the end, 
when all questioning is done, add everything at once. This has the 
advantage that you can freely move back and forth until you finish the wizard.

> > 5. Yep, how could that look like; should I provide users with a text area
> > or what?
>
>In the dtml/ directory of mk-zprod you have Add2.dtml, that's the page the
>user is redirected to after adding an object.  Maybe a text area with a
>suggestion (like Add2.dtml) in it?

Sounds good.

>Hubbliski.  We could provide them with standard classes as defaults
>(Persistent, Explicit/Implicit, AccessControl) and suggest some
>others.  I'm not too sure about the ZClass thing.

Okay, for the first version that will probably suffice.

> > I usually add the 'default' key to each property dictionary and write
> > a two liner in the __init__ method to generate the properties with
> > their default...
>
>Why not just have:
>
>         def __init__(self, attrib1, attrib2='something'):
>                 """doc string"""
>                 self.attrib1 = attrib1
>                 self.attrib2 = attrib2

Because this is horribly ugly and unflexible when you have 20 attributes. I 
always have to change several places, if I modify, add or edit an 
attribute/property.

>which could come from such a description:
>
>         attribs:
>                 name: attrib1 default value: None
>                 name: attrib2 default value: "something"

Well, we can describe that right away in the standard property dictionary 
form; then we do not need to parse or do anything else.

> > 9. Again, that would be a loop. But my question here would be: Are you
> > using sub-classes that much. I have written one so far in all the
> > products ...
>
>My latest projects sub-classes left, right and center.  If we just have
>the logic for a recursive loop there the user could add as many as s/he
>wanted without it being much more work for us.

Okay, I just wanted to make sure it really has the additional usage, for 
the extra effort.

>Well, I was, but I'm moving to France the 8. of July and I've just come
>home (to Norway) from England.  England, Norway, France, Germany, France
>all in just three weeks is a bit much :)  (Oh, and I have to get an
>apartment in Antibes.)

Okay. It would have been a good place to discuss this further.

Now, I looked at the mk-zprod code again. We need to make it a real Zope 
Product with a nice management API, so that I can use the functions from 
the Wizard.

For example we would need:

manage_make_initializeProduct(...)
manage_make_addClass(...)
manage_make_addProperty(...)
manage_make_addIcon(...)
manage_make_addSubClass(mainClass, ...)

If we define this API clearly, then we can use it later to automatically 
generate ZClasses as well. Once the work, twice the reward! ;-)

Regards,
Stephan

--
Stephan Richter
CBU - Physics and Chemistry Student
Web2k - Web Design/Development & Technical Project Management