Thanks for your compliments Xoobaru, Mamba and Culex

There is also Cacao and Candy, hehe.

Volunteers designers, this is the time to offer your architectural ideas theme, before the new Xoops 2.6.0 version is released.

Five including Cifug (think motorcycle helmet)

It is nice to see some people taking interest in helping out for sure. I have not been available myself for a variety of reasons but would like to help out. Just have been stretched to thin with too much going on while working 40 hours a week and going to school. But I do know that the current Github version of 2.6 is NOTHING like 2.5.7 or even the older 2.6 alphas. Going in a great direction just taking a while to get there because of all of the old code in place. I doubt there is a file in the source that hasn't been touched.

The really big issue is that the work isn't only on the theme front, but mainly on the modules. Almost all of them have hard coded HTML, as Bleekk mentioned, and that needs to be removed to get everything working smoothly. That means all frequently used modules need to be rewritten in terms of layout, which is a huge task.

How can the theme designers be involved more into the development of 2.6? I've tried to get it to run on both my local PC and my remote developement server, but it won't run on either one (strangely).

Some time ago, it was suggested that Wishcraft team up with "module buddies" that would benefit module creation/revision with his conceptual/technical/programming strengths, and supplement it with their more thorough follow-through strengths.

Recently, when trying out the X-Payments module, I was delighted to have everything work correctly.... this from someone that stopped trusting any module prefaced by the letter X.

On closer look, it was noticed that this module version (originated by Wishcraft) was associated with several names supporting the module , including Wishcraft, Mariann (themer) if I remember, Mamba, and someone else.

This was a good example of successful cross disciplinary module development (teamwork) as you mentioned, that while worked for Wishcrafts situation, would make perfect sense for just about any other module.

Prioritizing resources by module value would make it manageable.

The biggest things about future modules is that they MAY work with little updating with 2.6 but there are a BUNCH of things that are changing with 2.6 that will make rewriting many of the modules the best choice but before that happens we need to lock down some items within 2.6 more so we only need to rewrite modules once.

I would suggest any modules that do get rewritten to follow a strict MVC model so it makes things much easier to modify down the road. By making a module fully MVC you are forced to group things together in the same area instead of threading them through the code and it will make life MUCH easier down the road.

In Brief, MVC seperates a program into three sections...
M = Model - The code that does the actual work.. This should be the code that uses a lot of Xoops API. This will save variables, load them, and do all of the calculations etc...

V = View - This is the interface to the program. This would be written mostly in Smarty but setup with some basic PHP. There should be NO HTML code anywhere other than in here.

C = Controller - This is the decision making portion and basically interfaces between the View and Model. The View communicates with the Controller and based on what it needs the Controller communicates with the Model to actually do the work.

This forces you to NOT sprinkle HTML code throughout and by the grouping required should make things much easier to upgrade down the road. When you clone a module you may be able to just clone a portion of it instead of the whole thing too.

Rodney

Quote:
Rodney, MVC seems to be a little bit outdated, and there are some new and cool variations of it, like the ADR (Action-Domain-Responder)

An interesting article about "Alternatives to MVC" was published by Anthony Ferrara, as a follow-up to his article "A Beginner's Guide To MVC For The Web", and Paul Jones (author of ADR) responded here.

There is also an interesting comment about ADR by Akihito Koriyama, who himself is working on yet another framework called BEAR Sunday.

Please note that Richard has already experimented with ADR and there were several aspect that the he liked about it.

However, the main key will be to bring all the pieces in sync, especially the Presentation Layer that Eduardo is porting to XOOPS 2.6.0 from his "Common Utilities" and the work that Richard was doing on Core, incl. his various experiments with XMF, MVC, and finally ADR.

The opportunity for XOOPS is that because we won't have any "legacy" code written using the classical MVC, we can choose and take advantage of some of the newer ideas, and have XOOPS again on the cutting edge of development

I would like to credit here both Richard and Eduardo for their willingness to look at new ideas from others, test them, and then select the best and implement them in XOOPS! The "Not invented here" syndrome is gone from XOOPS!

Quote:
Please follow the link to GitHub from this article

Michael,

About Development

Please, you should be adopt MVC pattern.
Seriously, nobody gives a single f8cking sh*t for others patterns.

Use namespace, instead long Class Name like ZF.
Use PHP-CS-Fixer to fix coding standards issues with PSR1 and PSR2.
Make an API with Samin
Use Pimple as DI library or similar.

Modules
Can you make a list of official modules supported for 2.5 and 2.6?
For now, I'd like to help update these modules.

2.5.x
In SVN, What is the main branch for 2.5.x?

Quote:
You obviously didn't read the articles in these links that I provided
Why should we use the classical MVC if there are improvements to it?

Quote:
Yes, we're doing it - please check the code of XOOPS 2.6.0 on GitHub

Quote:
We're doing it!

Quote:
I am not aware of Samin, but it doesn't mean that Richard didn't look into it already.

Quote:
Yes, Richard is a big proponent of DI

Modules
Quote:
Awesome! Thanks for the offer to help! Publisher will be definitely one going forward.
Others to be considered:
- NewBB
- XoopsTube
- WF-Downloads
- MyMenu
- xNewsletter
- Tag
- XoopsPoll
- Contact
- SmartFAQ
- extCal
- extGallery

This list is not final. The code is on GitHub, and you can fork and contribute there.

The modules that will move to 2.6.0, will be added to this GitHub repository

Quote:
Look in Branches. The current trunk is 2.5.8