Daigoro, I understand what you mean. Using an abstraction layer can slow you down, and you want the raw sql queries optional so developers can speed up their modules if they want to. Well that is the trade off, speed for flexibility, in this case different database types. Allowing devs to use "raw" queries could break functionality in another environment. You either want a slightly slower database access mechanism with support for multiple database tpyes, or you can hard code everything and it'll be fast, but you're sacrificing flexiblity, in this case that being MySQL restricted. The current system is like a hybrid, it doesn't support other database types, but there is some abstraction there to make your life easier. Alot of queries are currently hard coded sql statements.

Besides a few, like union, I also don't know much about the differences between database types. I've mostly used mysql, access, and a little mssql.

I might still try to integrate MDB2 into XOOPS (at least partially), if anything to see if it makes a developer's life easier and if there's a big hit on performance.

Daigoro, that looks fine, but if you want to support other db's you have to make it so that there are no "raw" queries. If you have to hardcode an SQL string in there then that string may not be supported by another db and thus may cause an error when using another db. There's a lot of db abstraction layers like mvandam pointed out. To me it would seem more prudent to incorporate one of them than to reinvent the wheel.

About a year ago I suggested MDB (the first version) as a possible database abstraction layer for XOOPS. It was beta then, or maybe alpha. Maybe MDB2 would be ideal for Xoops3. Yeah it's still very immature, but the format of it seems to be the same as MDB1. I was thinking of actually attempting to rewrite a portion or a module in MDB1 or 2 (ADOdb did look bloated to me, although mature) just to see the feasibility and maybe run a profile and see how much it adds to parsetime, but then came the problem of Pear. If you don't have pear installed, then you need to install or if you don't have ssh access install it using the upload method and adding an init path. It seemed like it could be a hassle when you installed this version of XOOPS.

In any event, converting or expanding the database abstraction layer now would be a lot of rewriting and testing. Whether it's something you want to implement for 2.2 or 3 is up to the core dev team. If 2.2 is looking to be the focus of the rest of this year, it might make more sense to do this for Xoops3.

Quote:

That's what I had figured. Most classes done this way in the core seem to have a constructor and 1 or 2 methods, and then a huge handler for all the DB stuff. It didn't look necessary to separate out the 2 when the actualy object class has so few methods generally, but I understand the reasoning. Is this part of the "recommended" method?

Quote:

You know I actually would if I was confident what I've been doing was correct. I might just take a core module like the polls and improve on it using the "recommended" way. I've been looking at the various dev.xoops.org modules, maybe 2 or 3 of them are using OOP, and out of those I don't believe any of them are written in the "recommended" way (ie extending XoopsObject AND using initVar, getVar, etc). Not that they're bad, they just don't follow the core classes/modules. I don't know how important that is to the XOOPS core/module devs.

I've noticed that extending the XoopsObject class conveniently formats text for you assuming you initVar to set the data types, and then getVar and setVar will "sanitize" the text for database entry or display. I've also seen kernel and some OO based core modules also include a corresponding Handler class to handle database manipulation. Howvever, there exists very very few modules that actually take this route. The few modules that are OO either create a renderer class for display (I don't even quite understand why you'd throw in an extra layer between the calling page and smarty, why would you even need another class to render output for you.) or throw in database manipulation methods into the that very class.

I'm wondering what the benefit is by separating "data access mechanisms" methods into a handler class? No one seems to be doing it, but the core classes are practically all done this way.

In addition, it'd be very useful to include the initVar, getVar, setVar, etc functions in the module developement wiki. Alot of people don't use what's supplied in the core, and it would help them tremendously to know these tools are provided to you.

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.

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'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.

I'd like to know as well.

I understand how this could be a security risk, but I think it should be an option for the site admin. I myself find it really annoying that I need to re login at xoops.org every time I visit it. The system at work and home are both my systems and are not public system. I'm aware of who uses my system and I know to logout when I finish. I know if that I set a cookie to keep me logged in at all times, that it'd be relatively secure. I think the trade off between security and convenience should be up to the site admin. I'd definitely want my users to be able to be logged in at all times. I'll risk some users who don't know better leaving their cookies on a public machine, if it'll convenience the majority of my userbase and promote user interaction/participation, then I'll opt for that.

The truth is that people are lazy. I've often found myself wanting to reply to something in these forums, and then find there's no reply button because I'm not logged in. Sure it only takes you only a few seconds to log in, but by then I think that my reply isn't worth the logging in time, or that I'll do it another time. Just look at the Who's Online module. Right now there's 5 memebers and 24 guests. I'll bet you that some of those 24 guests are just not logged in. Imagine the amount of members you'd be able to see online if you didn't force people to login so often.

Well.. upon registration the admin could enter a key. The key could be used as a seed to encrypt the user string. Though I think the password stored in the MySQL database is a md5 hash of the password you enter on registration. So then the server doesn't even have your original password. I suppose you could also encypt the md5 hash of your password as well. Could be done, if you lose that key or change it all those cookies will be invalid. But I guess at worst is you'd need to login again.