[Zope-CMF] Saving custom data in a MemberData-objectfrompython

[marc lindahl]

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.