I ought to add that I want to present the _content developer_ with the list of paradigms that exist within the calling folder _at the time the class instance is made_. I just don't know any way to get a list of the contents within the calling folder into HTML code that makes up the web page for the initial properties of the ZClass. As far as I can tell, the "folder" for creating a ZClass instance is different from the calling folder. Hence my problem. This might be solved if there is some mechanism for getting content from the calling folder _before_ calling the zclass_addForm so that the creation of that web page can reflect the contents of the calling folder. That would be quite a trick. Ron

...

"Ronald L. Chichester" wrote:

...

The bottom-line question is, can I make a list for an HTML list box with the contents of the folder that calls the addForm method?

I found that the power of using ZClasses was in being able to define a META TYPE. This gives you a lot of handling capabilities in many situations. So instead of having one Zclass with a boolean to select whehter it's an issue or a paradigm. I would create two separate Classes. The overhead is pretty small compared to what you get back in power.

I am using two ZClasses. One for the paradigm (which has one set of properties) and another for the issues (with yet another set of properties). Both classes do different things. They are, however, related in that they reference each other. The question then becomes how to contain those references. One of the classes has to maintain a reference. Note, one issue can reference multiple paradigms. Each paradigm, in turn, may reference several issues. The reference-back (when viewing the paradigm) can be done (I think) through dtml by picking out those issues that contain the link to the paradigm in question. I wanted to adopt this technique because it is scalable and flexible.

I could have created a set of classes with direct links (e.g., boolean properties that indicate whether a particular issue contains one of the paradigms. This would be fine for one subject (the subject being a set of paradigms and issues). However, I would have had to derive a whole new class for each subject. The method I'm trying to work out here would be flexible enough to work on mulitiple subjects without having to change/create a new product. All the content developer need to is pick the same product whenever he wanted to set up something like this.

...

For the association part, your issue will need a lines property that will contain the associated paradigm ID's. When you add an issue and select the paradigms from the multi-select then your form handler will have a list of paradigms to fill this property with.

Correct. That is the goal. The problem comes on how to load the list of paradigms into the add_form/edit_form for the ZClass.

...

Do the paradigms available to an issue span mutiple folders or are they all co-located?

Yes. All of the paradigms and issues reside in the same folder (that is called a "subject" folder). In fact, we don't want to mix paradigms/issues with other folders.

...

The former gets pretty tricky and is better implemented with a URL vs. just the ID.

I would agree to that.

Thanks,

Ron

_______________________________________________ Zope maillist - Zope@zope.org 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 )