Paul Winkler wrote:

In that case, I'd write a filesystem Product for the logic.
Replace the scripts with methods of the Product class.
Make it folderish so it can contain Forumator forms and anything
else you want: inherit from Folder and use its UI to manage

You could then use AbracadabraObject to clone instances of
this thing; or you could do it all in code and have a manage_afterAdd method that adds a preconfigured Formulator form.
Source and/or docs of Formulator should give you a clue how
to instantiate one with the right config.

That's kind of what I was thinking. AbracadabraObject appears to have a method call that allows you to use its magic in code, which I think is exactly what I want, although as before I'm very surprised that this sort of functionality doesn't exist in Zope proper.

I guess my desires aren't actually all *that* in-line with the main body of Zope users, as I do *not* want the users of this application to ever see a ZMI screen. So I need this half-and-half situation where I or another admin can tweak some aspects of a class (e.g. Formulator forms, ZPT) via the ZMI or WebDAV, but the instances of those objects are instantiated *via code only*, by Python logic and my own (ZPT-driven) HTML form interface.

Another possibly far-fetched feature I'd like, which again I believe was part of ZClasses, would be to be able to tweak the instances' Formulator forms after the fact...e.g. add another data field a year down the road. Of course this then means that I both do and don't want these cloned forms to match up with the central one, and I'm not at all sure that I can accomplish this without writing lots of my own code to handle it.

Thanks for the help, by the way, it's appreciated.

Zope maillist -
** No cross posts or HTML encoding! **
(Related lists - )

Reply via email to