Having had a few weeks to tinker with XOOPs, I have a question? and need some feedback. While it appears that the core is written as objects, am I safe to say that many of the 3rd party modules are not?

And (excuse my lack of understanding here ) if I wrote an 'article' modules that was completely object-oriented and say a 'ad' module also written as a classes and methods, wouldn't it make sense to be able to write a third module lets say its called 'page' that could combine 'articles' and 'ads'? and that the page module wouldn't be much more than a 'container' or 'collection' module?

I thinking along the terms of if every element i create adheres to some clear OO standards, ie has it's own display, admin methods,etc, etc.. then it would be easier to mix and match elements in other modules?

Or am I way off base here?

If someone(s) on the Core XOOP team could check in on this thread, I would appreciate it.

krayc

I've been thinking the same thing. As I begin to write my first module, I notice that a huge majority of 3rd party (and some core modules) don't seem to use OOP. They do use core classes, but some, like the downloads and links module don't use OOP.

I started my module without utilizing objects, then and stopped and thought that my code could be cleaner and more organized if I used objects. Then I sought an existing complex OOP module as reference and couldn't find what I wanted. Some of the core modules use OOP, and almost none of the modules in the downloads section (sorting by popularity desc) used modules.

Mithrandir's "Team" module is a pretty good module to use as reference. A lot of object use there, but it seems differently implemented than the core modules. The team module doesn't extend the XoopsObject class, while the core ones do. So you end up having a lot of methods retrieving internal variables, setting internal variables, etc. when XoopsObject has methods to do this with less code. I'm not knocking Mithrandir's module, but when you have different implementations to utilizing OOP, it's quite hard to know where to begin, or how you should approach something. Should you use XoopsObject or not? Because, whether you do or don't your corresponding code looks different.

Doing my module straightforward seemed pretty easy, but when you want to take the objects route it gets increasingly complicated. XOOPS supplies you with things to help you within its framework, but when do you use it? Should it be used more often? I would think so considering a major feature of XOOPS is that it's OOP, but module devs don't seem to be using it.

PS: OOP isn't the best or most efficient way of doing everything, but where you would think it would be good to be used it seems the dev community isn't.

A lot of third party modules are written to deal with a certain functionality and not everybody is as OO minded as the core coders have been.

I myself is a good example on this.
I first made Team without a single class, but since then, I switched to OO to make the php files cleaner. Unfortunately, I didn't really get how to use XoopsObject and XoopsObjectHandler (the latter, I am still a little uncertain about, but I'm getting there)

I have meant to rewrite Team in the same style as the core, but I have simply not got the time to do so, as I instead focused on getting the News module out as well as I have been very busy. Not to mention, Team is quite a large module with 8 classes and 8 templates (and that's just the smarty-enabled pages) - so it is quite a big task to reengineer the module, which is the main reason why it hasn't been done yet.

Therefore, by means should you use Team as a complete reference guide, but merely as a step in the right direction. I do think that modules should be more OO and inline with XOOPS core classes. (Oh, and thanks for the nice words )

Yeah, I realize that not everyone is OO minded, but I went to browse random modules in the downloads section and I could find maybe 1 module using OO. It's not really a complaint, just a curious observation. Maybe the OOness of XOOPS in modules isn't demonstrated enough in module examples and tutorials. When I was looking at the wiki docs and other examples I found nothing directly related to OOP.

I started doing the same thing with my module, since I used other modules as references, none using OOP. Your Teams module looks really clean and well written. Extending the XoopsObject class simplifies a few things (I've only strated to use some of it's methods), so if you get around to implementing it it might be useful. I'm also not certain about XoopsObjectHandler.

I'll probably continue using your Team and other core modules utilizing OO as my reference. I hope other core modules get converted to OO sometime in the future. I think some mod devs use XOOPS dev code as their reference. Something like mydownloads and mylinks would be a great referece, since news (extends xoopsstory), xoopspoll, etc. don't seem complex and large enough to give a good reference for OO modules. Something as complex as your Teams module in OO utlizing XOOPS' object classes would be perfect. I hope you get around to it sometime. =)

I can only echo the same. I've learned lots from Mithrandir's modules. My modules don't ever end up being completely OOP as I'm still discovering the core and documentation is a work in progress (but getting fuller and fuller all the time).

There is the makings of a module development wiki over at dev.xoops.com. I think improving the quality of 3rd party modules is just a matter of getting more examples posted in a format like the dev wiki.

Yep, I totally agree. If the wiki docs included some more info about how to implement objects in the XOOPS framework it would help. As would maybe a good example as reference.

The more I look into how many core modules are implemented the more you see the different implementations different devs take. This can also be confusing because as a module developer with multiple references that differ so much, you can get confused on which to take.

Onokazu himself seems to create a class, and then add a corresponding object handler class to take care of data manipulation between that class and the database. In fact, a majority of the kernel classes (which are written by onokazu) are done this way with an object then the corresponding object handler.

buennagel does the headlines and the poll module, but the implementation here is completely different. There is no handler class at all. The data manipulation methods are within that class. There is, however, a renderer class which has display methods. Some developers might keep some display code in the calling page or some of it in the templates pages, buennagel makes a class for that additional purpose.

These 2 are the original developers of all the core modules (at least it's credited that way, I'm sure bugfixes and upgrades have been done by others). Mith's module doesn't extend the object or object handler class and thus it looks completely different too. If you wanna take the OOP route within XOOPS which way do you go? What do you use as reference. I've only been working with PHP a few months on and off, it isn't clear to me yet why Onokazu separated all database manipulation methods into the handler class. Nor is it clear why you would make a renderer class when you have the template and page calling the class. It seems to me like you're putting presentation into an additional place, which doesn't seem necessary. It can be frustrating developing a module.

P.S. While I was looking at code examples in XOOPS, it looks like edituser.php uses 'if' functions to divide operations, while register.php uses switch/case, which to me, seems like the better option. Although it doesn't affect functionality, I wondered about inconsistency or perhaps there was a specific reason this was done.