[collective-cmfmember] Eliminate the default schemata! (was CMFMember registration hack)

[Mick D. <mi...@po...>]

Dan,

I'm copying the list on this so it can get some visibility.

Attached is yet another update to my registration "hacks" which address
your use case of not having *any* registration fields contained in the
default schemata of your member type.  The "fix" only involved two minor
changes to the reg_form which should be compatible with any schemata
configuration.  I think the added flexibility of being able to do this
is a great feature to have.

I've tested these changes on my system and was actually surprised to
find that I was able to move all standard registration fields (including
ID and password) to something other than schemata 'default'.  The
registration process worked flawlessly and I have seen no adverse
effects anywhere else.  I had previously thought that some of my updates
to the registration process would, in theory, allow this to happen.  I
just never had a reason to test it before now.  Thanks!

NOW THE REALLY FUN PART...

As an added benefit, you can now completely eliminate the 'default'
schemata, provided you override ALL fields and place them somewhere
other than 'default'.  I've tested this and it works great!

Why would anyone want to do this?  A: So you can have complete control
over the placement of fields within schemata, and name those schemata
anything you want.  When a member edits his preferences, you can show
them something like "account details" instead of "default".   Perhaps
with other schemata pages such as "preferences", "membership", "billing
details", etc.  You are free to place any of the standard Plone fields
on whatever schemata you think makes most sense for your use case and
needs.


You mentioned you are running CMFMember 1.1b.  If this isn't the latest
beta2 version from SVN, I would recommend that you get it from the
repository located at
https://svn.plone.org/svn/collective/CMFMember/trunk.  It was updated as
recently as Oct 11 and I make all my changes against the most recent SVN
trunk revision.  I myself develop against Plone 2.1 and haven't tested
against 2.0.5 in some time, but these changes *should* be Plone version
independent.

If you continue to get errors from register_schemata after applying
these patches (using the latest CMFMember from the repository) then
we'll need to look elsewhere for your problem (perhaps a 2.0.5
compatibility issue I'm unaware of).

Please let me know how it works out.

Regards,

Mick



=20

> -----Original Message-----
> From: Dan Keshet
> Sent: Thursday, October 13, 2005 11:19 AM
> To: Mick Drevyanko
> Subject: Re: CMFMember registration hack
>=20
> On Thursday 13 October 2005 10:08, you wrote:
>=20
> > > Thanks so much for your CMFMember registration hack.  Registration
> > > takes ungodly resources over here, and I desperately needed to
split
> > > things up into seperate schemata.
>=20
> > > A few bugs I noticed:
> > >
> > > 1) if there is a fieldset 'default', but no registration fields in

> > > it, it causes an error.  That's because it picks 'default' as the=20
> > > fieldset, but 'default' isn't in the "fieldsets" list.
> >
> > It sounds like you have a fairly unique use case for CMFMember.  I=20
> > assume you have overridden the default CMFMember schema and placed
the=20
> > 'usual' registration fields like ID, password, confirm_password,
email=20
> > and mail_me on a schemata other than default?
>=20
> Yes, I did that, but I switched a few of them back so that it=20
> would work.  I wouldn't even call it a workaround; I had no=20
> coherent reason for moving them away from default in the=20
> first place. :)
>=20
> > I've looked at the code
> > and I believe it should be relatively easy to accommodate this.
From=20
> > what I can tell, it would only require making a few minor changes to

> > reg_form.  My only concern with your approach is how well Plone in=20
> > general will handle having these fields on something other than the=20
> > default schemata.  If you could provide me with a sample of your=20
> > custom member schema I might be able to make the changes you need do

> > some cursory tests for other compatibility issues.
>=20
> If you want it, but let me stabilize it first.
>=20
> > > 2) I ran into error after error using "new_context" in=20
> > > register_schemata.cpy, but it works just fine if I use plain old=20
> > > context.  I don't fully understand portal_factory, so I don't know

> > > if I ruined the whole point, but that was just my experience.
> >
> > I have no idea why you would experience errors in the=20
> > register_schemata script.  Can you provide me with a traceback of
the=20
> > errors you are getting?
>=20
> When I switched from new_context to context, the error went away.=20
>=20
> Traceback follows.  The extra variables in the exception are=20
> respectively "index" after it's been incremented,=20
> "len(schematas)", and "schematas".
> -----------
> Traceback (innermost last):
>   Module ZPublisher.Publish, line 101, in publish
>   Module ZPublisher.mapply, line 88, in mapply
>   Module ZPublisher.Publish, line 39, in call_object
>   Module Products.CMFPlone.FactoryTool, line 341, in __call__
>   Module ZPublisher.mapply, line 88, in mapply
>   Module ZPublisher.Publish, line 39, in call_object
>   Module Products.CMFFormController.FSControllerPageTemplate,=20
> line 98, in __call__
>   Module=20
> Products.CMFFormController.BaseControllerPageTemplate, line=20
> 39, in _call
>   Module Products.CMFFormController.ControllerBase, line 191,=20
> in getNext
>   Module Products.CMFFormController.Actions.TraverseTo, line=20
> 36, in __call__
>   Module ZPublisher.mapply, line 88, in mapply
>   Module ZPublisher.Publish, line 39, in call_object
>   Module Products.CMFFormController.FSControllerPythonScript,=20
> line 105, in __call__
>   Module Products.CMFFormController.Script, line 141, in __call__
>   Module Products.CMFCore.FSPythonScript, line 104, in __call__
>   Module Shared.DC.Scripts.Bindings, line 306, in __call__
>   Module Shared.DC.Scripts.Bindings, line 343, in _bindAndExec
>   Module Products.CMFCore.FSPythonScript, line 160, in _exec
>   Module None, line 36, in register_schemata
>    - <FSControllerPythonScript at=20
> /machinescience.org/register_schemata used for=20
> /machinescience.org/portal_memberdata/portal_factory/Student/s
> tudent.2005-10-12.1346>
>    - Line 36
> Unable to find next field set after default, 1, 1, ['default']
>=20
> > Also, what version of CMFMember and Plone are you running?
>=20
> CMFMember 1.1b (with your hack from the mailing list of a week ago).
> Plone 2.0.5
>=20
> Thanks!
>=20
> --Dan
>=20