This thread is to discuss two different concepts I am considering to reduce my code writing. This is along the line of the universal framework I had considered before but have pretty much dropped due to X3 coming out.

I will explain both of these ideas but I am thinking due to X2's development being dead that this would require a module to administer but could be something built into X3 in part or in whole.


The concepts I am looking at here are an Action Que and a library of classes. I will make two separate messages to explain what I am thinking with these and hope to get some feedback. Since they are related I decided to keep them in the same thread.

These concepts could be used for any module that wants to access data or functions that another module uses. The idea is to minimize the rewriting of code in the secondary module to make full use of the primary modules features.

As an example. CBB uses xoopspoll as an add on. Currently when you look at CBB the file poll.php is the file to interface into xoopspoll. Although there is some reuse of functions from the xoopspoll module there is alot of code to make it all work with CBB. And if you make any major changes to xoopspoll it will require a rewrite of the CBB poll.php file to make it work right. (See umfrage for example of this...)

The concepts I present here I present as a way to minimize this. I may have presented portions of this before but didn't have a clear mindset on how these would work together.

Action Que...

This would be something setup to allow a string of functions to perform a task. Currently this can be done in a messy sort of way by hacking code to call external functions and using class overwriting and a bunch of other tricks. But those tricks break easy and can be hard to maintain.

Why consider an Action Que? What benefit is there?

Well lets take one action and look at it...

Deletion of a user. This is something that we all do. But if we just delete the user we end up with a lot of crap laying around that confuses the system. We have forums and perhaps other modules that have submissions from that user. So it ends up being a real hassle at times to delete a user from the system because things "get left behind". Then you have to go through each module and perform some ritual to clean the database. In the end it is simpler to just add the user to a group that has no permissions.

Instead when we have a function that could impact more than one module we should have an "action que". This action que would contain a list of related functions that need to be done to complete an action.

Lets say in this case the delete user function is in profile. But we also want to perform some functions in our forum when a user is deleted. So we have a delete user function built into profile that will delete a user by their UID and one in Forum that will perform actions related to deleting a user as well. Both register these options into the action que for the deletion of a user. When we decide we want to delete this user, instead of calling the function directly from profile we call the action que instead. The action que will then call the profile deletion function then when done call the delete function in the forum module. The action que would need to also have a priority of actions as well. In this case we might want to make sure we do all the deletion cleanup in forum before we actually delete the user using profile.

Chances are there are only a few user actions that would benefit from this but I am sure if it is built someone will find a use for it that I am not considering.

Another thing this could be useful for...
Lets say we have an event module that we post an event for... This is a party and we want lots of people to come. We want to post it in the news articles to advertise it, we want to create a thread in our forum to discuss it and we want to setup a picture album to hold pictures for it...
Try doing this now...

If we try to do this now you are going to end up with modules with duplicate code that has to be maintained if you upgrade versions and have to be debugged again and becomes somewhat of a nightmare. What if you want the functions of a new gallery program but it isn't supported by your event calendar? Oh crap.. Now we have to build a new "plugin" for it...

With an action que, we set up the que and the supporting programs see the que and put related functions in it. If you upgrade a module that is action que compatible.. No big deal.. Just update it, no coding required.

The que identifiers and call functions should be standardized.

Thus we can build a "New Event" with any type of event module and it would work with any forum, gallery etc.

No need for alot of the plugins we now do...

There are some more specifics I have figured out to make this work such as selections in the call so that if you want to just post a new event but you just wanted to post a news item you could do that and NOT setup an album and forum thread...

Hoping I have presented this idea pretty cleanly so it can be well understood. I really think this concept will reduce alot of the coding we do when other modules are available.

The second concept is a Library of functions/Classes. This idea has been developed due to the concept of making a module easily modifiable for xoops forks or potentially upgrades of xoops down the road. This concept may also allow easily going to the MVC structure of X3. (I have NO experience at this time with MVC and this came from trying to reuse code. If this sounds JUST LIKE the zend framework it just means I am not the first to have this idea..)

The idea here is that when I build a module I concentrate on the concept that every thing I can gets put into a function. Everything I can put into a function gets put into a class. And all the classes go into a library related to those functions. This Library then becomes available across the system and my module just accesses these libraries just like any other module would. These Libraries would be different than a normal framework because they would be installed similarly to how a module would be installed. Thus they have a database table etc. The module then would just access the library and would not need its own database table if designed with the module.

So in profile for instance.. To add a user I would just call a library function called "profile::adduser($id)"

If I was in another program and wanted to add a user.. I would call... "profile::adduser($id)"...

Or however it ends up.

You would also need to have a way to register the functions available from the libraries so you know what you can use. By using classes this may be a moot point.

Installing a module then becomes a little different with this concept. You install the library first... Then the module. When the module is installed it looks to make sure all the libraries are available that are needed.

You also need to have the modules register that they are using the library and deactivate them if the library is updated to force them to be updated as well.

This concept is similar to MVC as I currently understand it...
The V or View would be dealt with Via Smarty Templates...
The M or Model would be the Libraries of classes themselves..
The C or Controller would be the module.

The modules themselves would end up becoming very light as most of the functions would be handled in the libraries.

In stead of a Case statement that runs a whole page or two with code.. You end up with a couple lines in each statement.

You could then in essence develop the libraries separate from the modules since the module depends on it but the library can exist on its own. Why the heck would you want this? Well lets say you have a forum program you want to add a poll system to but you don't need the poll module otherwise.. Just load the poll module library and not the module and you are all set... And if you ever wanted to add the poll module later it would be simple as the module would be more of a controller in this case and may not be necessary otherwise. (Except if you want admin functions)

Why the heck am I even considering all this?

Well this came from being introduced to a fork of xoops before X3 became available as an alpha and long before I knew what the heck zend was. This to me sounded like a method of being able to make modules flexible across the board and the more I thought about it the simpler it seemed to make my future projects.

If I build a controlling module to keep track of all this stuff then start rebuilding alot of the common modules out there to take advantage of such a system all the modules shrink by a major portion. It does require making generic classes that can handle alot but in the end it is worth it.

I have edited a few modules now and looked through others and it is apparent that we continue to rewrite the same stuff over and over again. In order to link modules we have to do plugins where we are rewriting some of the other modules code.

Down the road I am looking at redoing profile into a majorly improved module. In the mean time I am looking at ways to simplify that. If I redo xoopspoll, tags, extcal, extgallery and perhaps some of the new stuff Simon has done to be in this format then each of those modules will be strong on its own but other modules can draw from them as well easily. (I am sure I can think of others as well.) So when I get to a module like Profile I can reuse the code from the above modules that have been developed on their own and be able to use ALOT less code. And if a module is improved along the way? Well then Profile could make use of the new modules functions without doing anything to profile other than updating the module.

Not to mention that migration to Xe from a design like this should hopefully be simpler especially if there is a way to build support for this stuff into core of X3. I think it could be a very powerful addition if not already possible.

Rodney

A couple of concepts introduced into X3 might suit for your requirements: event, plugin, service, module API

In terms of profile, the features are available in /usr/apps/user/class/gateway.php

Action que, done by service/event

Furthermore, X3 supports multi-engine and multi-library, Thus if you build your own libraries or engines, you can just add them without "hacking".

Sounds like maybe I will just develop for Xe then and not do much with the older stuff.. Sounds like it already has the stuff I want built in perhaps.. I have abunch of books on Zend now so I guess the next step is start reading...

Thanks again DJ.


Cant wait to see the docs on implementing xoops engine.

Rodney

Quote:
If you don't have anything yet done, and are thinking about rewriting existing modules, I also think that XE would be you better choice, especially since you could be taking advantage of all the Zend components available natively to you in XE

Code wise I havent done much yet.. Just considerations. I need to do a little more for the team site and go from there. It is looking more and more like one way or another I should have some time opening up soon and will be able to start working on some of this stuff but the zend framework will be a whole new world...

And its not like I was real comfortable with the whole "legacy" world yet...


Rodney

While looking through some modules and trying to get ideas on how to modify them and such I have come up with a need to start a project. When I am closer to reality with this project I will post more but I need to know what Libraries are out there that could be used with xoops modules and are commonly used. There are PEAR libraries that are used in both extcal and extgallery and I am looking to do some interesting things with these but I am curious if there are any other frameworks out there like this that are available?

PEAR is included in most PHP installations but I am curious if there are any others out there.

Thanks!

Rodney

I have begun working on this project and started with the TDMCreate module to build my skeleton.

I am currently working with the PEAR modules and may also look into the PECL modules as well. At this point it will only inventory what is on the system.

Next I will begin working on a "universal" framework to go with this module that will combine a number of available xoops frameworks into this one.

As mentioned before I will begin taking modules and splitting them up so they have a generic OOP section and the module section. The generic OOP section will be added to THIS module as an add on "library" with the intent of being usable by ANY module.

THIS module will be used to keep track of dependencies of the modules that use this module as their base. The intent of this whole thing is to reduce code requirements and make upgrading of modules easier in the long haul.

I will begin with Base modules that other modules include such as Tag and XoopsPoll and go from there.

At this time I am curious again if anyone can suggest any other much used PHP add on's beyond PEAR or PECL?

I may consider integrating Zend down the road as well but at this point with XE in development it doesn't sound like an idea worth the bother.

Oh yea, as a last note, This will be designed to work with 2.4.5+. Once XE is further along I will look into creating an XE version as well that will make use of the built in XE libraries. That should allow any of the modules written depending on this module to be able to make use of XE with little trouble. Hopefully will allow any module written in this manner to be installed without issue and without needing legacy support when used with XE.

Rodney