Re: Something better than ZClasses (was: Re: [Zope-dev] Re: Zcatalog bloat problem (berkeleydb is a solution?))
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
On Thu, 28 Jun 2001, Stephan Richter wrote:
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.
From the filesystem of the user?
BTW, the /img directory is non-standard. Better would be www/ since other products use it as well.
Sure thing. (Although, www/ indicates to me .html pages and various other things too.)
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:
Yes. This is what mk-zprod does today :)
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.
Sounds good :)
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.
Could you give me an example of how you would do it? (Then I could modify the mk-zprod code.)
Well, we can describe that right away in the standard property dictionary form; then we do not need to parse or do anything else.
Nice :)
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.
Morten Petersen from Thingamy will be there, I'm sure he has some thoughts about it.
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.
I'll start typing right now. I'll probably have something premature by tomorrow.
If we define this API clearly,
Ok. I'll just write up mk-zprod as a Python Product and the API is defined as I go. Then, you could have a look and we can unite on one API and I make the necessary changes in the code. Yeah? Unless, of course, you have some specific requests right away.
Once the work, twice the reward! ;-)
I like.
On Thu, 28 Jun 2001, Stephan Richter wrote:
For example we would need:
manage_make_initializeProduct(...) manage_make_addClass(...) manage_make_addProperty(...) manage_make_addIcon(...) manage_make_addSubClass(mainClass, ...)
I just realised something. How do you need this to work? With regards to the wizard. Should mk-zprod produce the files and add them to a folder in itself? Or should it return everything for the wizard to handle?
participants (2)
-
Erik Enge -
Stephan Richter