Thanks, now it works. Slowly this module becomes useful.

That really is the only option? Damn, I already had that. I had a page I could copy into the module that, whenn called, would automatically run the tests for that one. But I wanted one page where all (multiple modules plus core) tests are shown and so I tried my luck with a dedicated module.

I don't know if this is still a beginner question, but how do I get a objecthandler that is from another module? Sure, I could extend that class in the module in question, but that will be a lot of work, as I have to do this a lot.

Maybe I should explain the situation. I wrote myself a module that integrates SimpleTest in the XOOPS framework. That module searches for testsuites allover XOOPS and executes them. The Problem is, they are executed under the SimpleTest module, not the module the tests are from and the handler searches for the classes in the Simpletest Module, not the module to be tested.

So I see two theoretical solutions:
1. Make XOOPS believe it is the other module
2. Tell the handler in what module to find the classes

I have no idea on how to do either of them so any help would be great.

Jesore

As we will put whatever I get to work under GPL, you'll get your hands on the code of course. It will be very specific for our needs though.
The module(s) will have the following features (subject to change):
- On registration time the user can choose wether he wants the free membership (group registered users) or a membership to our association (www.webmasters-europe.org if you're curious ).
Also we offer companies the possibility to join. The most important feature they will get is to associate users with their company, making them "paid" members.
So essentially that last level will be a "buy several memberships" and one user can upgrade several others. Also the company information can be shown with every associated user.
There are currently no plans for different levels of membership, like the typical "normal" and "gold", so I don't think, I'll put functionality like that into the code. But I promise to keep the code expandable.

My personal plans for the project are to integrate SimpleTest into the XOOPS framework (already done on a primitive level) as we will use unit tests on this project and a decent php checkstyler. If I find time, I will repackage that into real modules that are releaseable.

As I'm relatively new to XOOPS (written two small modules till now - nothing very interesting) I'm grateful for any hints and tips on implementing that features.

Thanks for pointing me to the other thread by the way. Does anyone have that module for me to download?

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.