Hard to understand what you type but you might want to check out the Service Manager.

Your modules can "provide a service" to the system and any module can take advantage of it. MOST of the system modules that are used by other systems will eventually all be converted to the Service Manager.

I mention this because time allowing I will likely be doing much of the updating. I am finishing up a phpmailer service in the next week or so and will be documenting the requirements to do so.

This is new to 2.6 but is a VERY powerful system.

Very cool... Will have to check it out.. I think I have some documents around here that could use some modification and uploading.. After finals I will have to play with it a little.

Rodney

Should be a simple database dump then import.. You may have to drop some fields or add some.

At this time It is my opinion from what I have seen that 2.6 will not be MVC but there will likely be some items setup with it in mind.

With modules it makes a lot of sense in many ways but for the core there is too much work to be done to make the changes to make it truly MVC at this stage.

There are other things that Modules can benefit from when in an MVC format as well. It makes cloning a module much easier because you can clone JUST the controller and the view if you like and leave the model alone.

I am excited by the combination of MVC and the Service Manager in 2.6 because it can make my previous "dream" of module libraries a reality.

Note that by my mentioning MVC making it easier to make modules 2.5.x and 2.6.x compatible only relates to the code differences. While there are attempts being made to make 2.6 backwards compatible with 2.5 modules there are additional features in 2.6 not available in 2.5. By making modules in an MVC format you should only have to modify the Model to work with 2.6 and hopefully only minimally if at all.

Rodney

What is MVC?

M - Model = This is the portion that DOES the work.

C - Controller = This is the portion that Controls what happens.

V - View = This is the actual user interface that the user accesses and views.

With Xoops we have a system that for years basically has consisted of a template that is loaded with values from a module. In other words we are already 2/3rds the way there with a standard module.

In my "advanced" java class our instructor explained this model in a manner where each component of an MVC design should theoretically setup in a manner that it can be pulled out of the program and replaced without impacting the program.

What this means for instance is the Model did all of the actual work. It communicates to the database, validates the data, or whatever other job the module is supposed to do. Such as calculate a date or whatever. When writing a Model it is a good idea to have it be able to stand on its own. It should NOT depend on anything being returned to it from the controller or from the view. It should only act on the data sent to it and return any results back to the calling procedure.

The view should also be able to work on its own. It should present data to the user or retrieve data from the user. In my Java class we had to have a console based View and a GUI based view. This entitled that the View wasn't directly dependent on any other component. It only showed what it was told to show and only returned what was requested.

The controller is the brain of the system. It will take input from the view, send it to the model to process and display results back to the view. In my Java class we had to build 2 different controllers to do totally different things with our Model and our View. This allowed us to have two totally different, but similar, programs by just changing the controller but using the original view and original model.

Separating your program into these three components helps in many ways. You can reuse your code easily in other modules and you could actually build a Model that could be used by many different programs or modules like a framework of a sort. You could also make it easier to be compatible with other versions of xoops by insuring all of your xoops related code is in the model. A service provider could be written much easier for xoops 2.6 as well.

Another thing it helps with is testing. phpUnit can test functions much easier in an MVC environment. It can really test the Model objects well since they are designed to be self contained. The controller can also be tested easier because you should be able to run controller functions without a view. The view may not need to be unit tested and may not be able to be unit tested.

Regardless to what some developers might believe MVC is here to stay. It makes sense and in the long run will make a developers life much easier by simplifying the code.

Rodney

I have some comments. I have not had time to look at this as I am finishing up my semester. But yes I think there are five considerations at this time that should be considered on building this.

1. XMF, XMF SHOULD be the basis of any module that can make use of it. This will help make a module 2.6 ready and make any necessary conversions MUCH easier.

2. MVC should be the rule for modules of the future. It does make things much easier to debug and sort of forces use of OOP.

3. We need to make a standardized folder format. In the near future we will be looking at automating installations and it is important to try making the zip folders the same so an installation program knows where to put them.
I suggest the following folders which follow the main xoops installation.
html - should contain all files in the proper folders for installation. An
installation program will just take the folder and copy it into the main
directory.
extras - should contain anything extra that isn't normally included in the main
install but may benefit some users.
docs- any help files that may be included. These should be separate and not
installed automatically and should contain any extended help. A future
installer may use this directory to allow someone to install help menus
for a module but for security or to save space may decide not to install.
upgrade - should contain any files or other items needed to upgrade a module
from older versions or perhaps have conversion scripts to allow a new
module to replace an older module.
An install program will likely only use the html and docs folders. The other folders are to help users get their module up and running. May be able to just use the extras folder and not need an upgrade folder.

4. With xoops 2.6 we have a service manager that will allow a module to provide services to other modules. This will become more common place as the manager evolves but in essence a program like xoopspoll that can be used by other programs should have functions setup that are generic and can be accessed on their own by other modules. When building an MVC setup this becomes much easier to do because you can pretty much make the whole "Model" portion into a service manager provider and the "Controller" would make use of it. For xoops 2.5.x you could still make use of such a format but just be aware of the importance to generalize it.

5. Another consideration with an MVC build is that the Model can be built to have objects that are generic and can make service manager service providers easier but can also help clone modules much easier. You should only have to clone the Controller and View portions of the module in this manner. You can leave the original module in place and just copy the view and controller to make a second copy that is totally different than the original. If built with this in mind it can make life much easier in the future.

My semester ends shortly and depending on how next semester lines up and how much I get done during winter break I may be able to help with this. I don't have any pressing projects for xoops other than some service manager stuff I need to finish up for 2.6. I also will only have 2 classes next semester instead of my current 4 which should help dramatically.

Anyhow great start!

Rodney

While it is true that the 2.5 is lacking at this time there is development being done to majorly upgrade xoops with 2.6. It is a major rewrite and is mostly done by one person with others helping as they can. If you load up the current version of 2.6 from github you can see the new direction we are headed in. Since it is an early alpha much of it is still under development. The installer and the themes have not been updated much for 2.6 but pretty much every line of the core is being touched in one way or another.

The best I can suggest is if you can help that would be great. If not, just keep coming back and check on 2.6 and see where we are at.

Rodney

Something you probably don't really want to hear but...

Chances are that your installation is too old to update easily.

You will spend a LOT of time trying to get it updated and you would be better off just starting from scratch to 2.5.7.

What kind of site is it, how many modules do you have installed and how much would you lose if you just started fresh?

For 99.99% of the users of Xoops, using CSS or JS files that are external to your site is a waste of time.

The ONLY times I would worry about this is if:
#1, your host is slow and anything offloaded from your host makes a difference.
#2, You are being charged for bandwidth and you are looking to save anywhere you can.

For most of us the time savings would be barely measurable and by no means noticeable. Unless of course you have a very busy site and lots of users at the same time.

It is hard to use externally hosted CSS file unless you are using a standard one that hasn't been modified. You might be able to use something like Google code or something to post it but I have not done this.

If you are using a standard JS library such as Jquery you could use the library from Google or another host. The point of this is that Google is generally much faster than your host and the bandwidth would be used from Google instead of your host.

Realistically, CSS and JS files are cached in your browser and generally never change so the savings really is only for those members that clear their cache all the time.

Rodney

If it required a major update then it is likely not going to happen any time soon. Most of the major updates to modules are being done to support 2.6 and some of the programmers that would be able to do this are working on 2.6.