I am looking at the module "profile" and trying to figure out how things work with it. I will keep coming back to this message thread when I find something I don't understand and can't find an explanation. Basically I want to understand how every line in this program works..

I am documenting for my own purposes every line of every file while trying to figure out how it works. The end result is that I better understand how modules are built in general but also how profile is setup. I am using this to build a new module like "xroster" with the flexibility of profile and then potentially making some major changes to profile its self. Once I have "decoded" profile I will be sharing my results to help other new module developers with developing modules in general. And will be looking for inputs for improvements to make. HOWEVER this thread will be sticking to JUST what things mean in the module PROFILE as it is now. (Version included in xoops 2.5)

I do expect to have fewer questions as I move through this code and learn what it is doing.

Next message will contain my first question. I will greatly appreciate any feedback. The quicker the feedback the quicker I can move forward. Thanks much!

Going through the admin directory first and going alphabetically through the files...
The first file I am going through is catagory.php
In one of the first lines I have the line...

$handler = & xoops_getmodulehandler('category')

After I searched the forums it looks like this function looks in profile/class/catagory.php and loads some sort of handler for data.

I see within profile/class/catagory.php there are two classes.

ProfileCatagory
With functions
ProfileCatagory (The constructor)
getForm

ProfileCatagoryHandler
with functions
ProfileCatagoryHandler
__Construct


So what am I missing?

I see calls to the following functions but I don't see how they are included here???

$handler->getobjects();
$handler->create();


And some others...

So if I am understanding this right, this call to getmodulehandler is adding the classes and functions from profile/classes/catagory.php to the definition of xoopsobject (extending class xoopsobject) and then setting it to $handler for use in the program?

Thus when I see the above two lines they are actually calls to xoopsobject->getobjects() ?

Thanks!

Looks like I need some documentation on xoopsobject and xoopsobject handler but doesn't appear to be any?

The class is an extension of another class and all underlying functions are automaticaly inherited by the new class.

It is for a slightly earlier version of Profile (1.51 not 1.57 or 1.58) but this
location explains the workings of the module.

http://dev.xoofoo.org/modules/profile/

This inheritance list is sorted roughly, but not completely, alphabetically:

* XoopsObject
..... o ProfileCategory
..... o ProfileField
..... o ProfileProfile
..... o ProfileRegstep
..... o ProfileVisibility
* XoopsPersistableObjectHandler
..... o ProfileCategoryHandler
..... o ProfileFieldHandler
..... o ProfileProfileHandler
..... o ProfileRegstepHandler
..... o ProfileVisibilityHandler


The authors are listed as
Author:
Jan Pedersen

Taiwen Jiang

Is there much value in forking from the path when XOOPS is in such an aggressive development mode?

The problem with hacking any module is that when the next generation of XOOPS comes out, the hack has to be redone or you have to stay with the older version.

Would it not be better to collaborate with whomever currently controls development of this core module to get them to include the functionality that you need in the next version?

Quote:

Thanks ghia, I sorta answered my own question without realizing it.. When I went back and read it to myself it was a "duh!" moment...

Unless I am mistaken, to this point the profile module has been pretty much abandoned by the programmers as they have other things to do. I did find a message from DJ from 2008 that said the new version of profile would be written from the ground up and allow much more. It appears to me that X3 is well on the way to getting done but needs more work so the core programmers are spending the majority of their time there.

If I actually get to a point of coding I do expect to look at who is working on the new profile module but at this time I suspect that there is no one working on it.

There have been no major additions to the profile module in quite some time. My intentions as mentioned above are to "decode" this module so I understand how it works. Then go from there. I already am learning a lot that I haven't gotten from any of the tutorials I have looked at and I am only 2 files through the program at this point.

So thank you again for your input but I am doing this as a learning experience. If I DO in fact decide to write a new profile module from the ground up I will do my best to document it well. At a minimum I will be writing a new module to do things similar in implementation to profile but far different in application.