[Zope-CMF] Saving custom data in a MemberData-objectfrompython
marc lindahl
marc@bowery.com
Tue, 24 Apr 2001 02:19:01 -0400
OK, I made some progress, and have a question for some brains out there.
To change the signup form, I made a new skin and copied 'join_form' into it.
Then I hacked in code from properties.dtml and got it so I can tag
properties from portal_memberdata as 'required' or 'optional' and show up on
the signup form. So far so good (I'm taking notes, so eventually I'll do a
how-to or something)
Then, since I want to qualify members as being over age 13, I had to change
the method testPropertiesValidity. So I made a new product, and put a
Zclass in it called portal_registration, with base class CMFDefault:
Registration Tool. Then I deleted the regular portal_registration from my
test site, and put the new one in instead. Then, inside my new product,
inside the portal_registration class, I put a PythonScript called
testPropertiesValidity. Cut'n'pasted the code from the regular one, and
started hacking :)
Now for the question. I want to pass this pythonscript a list via REQUEST
and it seems to be coming thru as a string. The data is originally a
'token' list property, which is then passed thru the join_form by:
<input type="hidden" name="required:token" value="<dtml-var
"getProperty('required')">">
(the property name is 'required', and typically it might have in it
['birth_date', 'location']
In the python script, when I do a props.get('required'), I get this:
"['birth_date', 'location']" - in other words, string-ified. I want to get
the list, to iterate over to test the 'required' properties.
Am I missing something? Or... how do you un-stringify a list??
> From: Tres Seaver <tseaver@novacoxmail.com>
> Shane is recommending replacing the instance, named
> 'portal_registration' in the root of your CMFSite, with an
> instance of another class; you wouldn't (ordinarily, at least)
> want to muck with Products.CMFDefault.RegistrationTool (the module
> which exports the class of the current instance).
>
>> If there were some way to modify the portal_registration tool
>> once the CMF site was created, like the way portal_memberdata
>> properties can be added, would that be a way to do it?
>
> The current implementation of the registration tool doesn't permit
> any "through-the-web" tweaking of its policies. We typically expect
> to replace several of the tools with custom versions; the registration
> tool is one of these.
>
>> Is this kind of thing the purpose of the CMFDefault directory?
>
> The tools and content in the CMFDefault product provide working
> versions of the components needed to build a CMF-based site; many
> sites can happily use them, *where the policies they implement are
> reasonable*. We moved the different "services" of the site into
> replaceable "tool objects" precisely to allow a site to replace one
> or more of them, while leaving in place those "default" versions
> which are acceptable.