6
Sometimes my timing is quite good, as I'm looking in exactly this kind of problem.
Our company wants to use XOOPS (afer evaluating a lot of other portal systems - your framework is great) as a community that requires membership in different levels - like free base membership and two or three more expensive levels.
The User already gets to choose what kind of membership they want at registration time. So, depending on what they want, the get different registration fields and maybe even a direct payment option (that's very distant at the moment though).
I'm now investigating, wether it would be easier to "include" the functionality we need in to the registration as it is or to write a completely new registration (via module), that makes heavy use of the user, group and profile classes - and forms of course.
I'm leaning towards writing a new module, as it shouldn't be that much work thanks to the advanced framework and it would make updates of XOOPS less painful - if the API stays stable.
Any experience on that matter or any practical tips on how to design such a module?
I'm especially interested in wether it is more elegant to use the original profile module and make my module an addition (make the two work together) or to write a complete new module and not use profile (besides inspiration of course).
Btw. I'm developing on XOOPS-2.2 already, as it will be some time, before we go online anyway.