There has been discussion about making a Framework for modules to make developing modules easier and hopefully faster by providing many often used functions.

Currently many module developers either create a "library" module (Example. Smartobjects), or they make a set of often used functions that they copy into ever module they make. This makes for larger modules, more chances of bugs and a non standard way of doing things.

So by us having a supported official module framework we can hopefully help module developers develop modules faster, with fewer bugs, and smaller amount of code.

My thoughts on this also would be that such a framework should be kept separate from the core. Trabis has already come a long ways towards building a module framework. If done right, by keeping it separate from the core, it is more likely we can keep modules compatible much further down the road. If the framework needs to be modified to take advantage of new features then it can be modified while keeping older modules still compatible. This shouldn't replace the Core API in any way but should be more of a way of extending it without effecting the core its self.

Thoughts?

I can only say:
I second this.

A seperate universal framework is handy for module developers and core developers.
Updating a module framework is much easier than a whole core for just a few modules.

Xoops descision was to split modules from the core several years ago. From that moment the module problems began.
Problems because every module developer stumbled up into develop problems because there where core code lacking. Therefore some module developers created their own specific framework. Which in fact is absurd.
One universal module framework can solve this whole module and compatibility mess.

Quote:

It is really quite clear that you have no idea what you are talking about do you or you wouldn't be sitting there writing this?

Now I am going to defend every module developer out there who has HAD to use their own framework, it was born out of necessity and not pride or nor vanity.

The core has been neglected for the last five years, we have had to find our own solutions to problems that has either been caused by the lack of interested or by the bugs that are in the system already.

If you had any IDEA what so ever the problems faced creating modules on en-mass you wouldn't be sitting there stating what you just did.

What would sort out this whole mess, if the core took one little bit interest in actually working with us, rather than against us and it worked pretty darn well when Ono was the lead developer. Least he understood the importance of modules.

Catz, I do hope I am not offending you in any way with anything I am saying. I am relatively new to some of these things but I do hope I Am on the right track...

I am hoping to learn and grow while helping make xoops a much better system.. Anyhow I am quoting your text here to try and get this discussion out of THAT thread.

Catzwolf said...
Quote:

And more from Catzwolf...
Quote:

The best-laid plans of mice and men often go awry

When developing any software, there is a technique called the development cycle. This outlines the basic structure that all developers should follow and is one of the most important elements within Xoops that has been missing for a long time.

http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle
http://www.pd-how2.org/1_2.htm

1. Development Team: What's the point of having a saddle if you don't have a horse? All the plans in the world will mean nothing, if you do not have the team in place to carry them out.

Should this team be the core development team or module developers? It should lie firmly at the door of the core and there are a number of very good reasons for this:

• Most of the main classes, methods and files are already situated within the core and would require little tweaking. If we do this within a module framework outwit the core, we again will have to split most classes, functions, and files up, and this would mean double the work and out of all these, XoopsObject and XoopsObjectHandler comes to mind straight away.

Just about everything within Xoops now runs through the two classes I have mentioned, it seems illogical to me to have two different versions of the same classes being used within the same system, basically, one for modules and one for the core. To me, this is impractical for all concerned.

Another variable you have to take into consideration is this, when a class or function is part of the core, this is generally considered the correct way of adding functionality to your module. For example: Notifications or group permissions. Generally, I will write new code only if the core cannot provide me with a real solution, or there is a bug or the code is too restrictive in its approach.

• Who will maintain this framework? If you are suggesting that module developers should maintain this library, I would suggest you rethink that approach. One thing is certain here, module developers come and go, modules fall off the map, but the core will continue even after a developer quits. Ask yourself this question, what is the current state of the modules that were part of the core and yet, module developers were ‘asked‘ to maintain those modules, but that never happened? What makes you think this will be any different?

2. Follow the development Cycle: Xoops is a large-scale project, yet it’s being treated daily like someone’s private own script with no real organisation or thought process. When was the last time that the roadmap was last revised? In fact, when was the last time that there was any meeting to actually discuss in any great detail to what is required of Xoops and how to actually go about adding new features, fixing old ones and removing obsolete code? This certainly did not happen with Xoops v.3.

There are rules and guidelines that must be adhered to when you have (or should have) many different people working as a team within the same project and yet, Xoops as a project ignores these principles, but yet, I’m still getting asked to design unit tests on code that was never designed to run unit tests in the first place.

For the last six to seven years I have been saying the exact same thing, things have to change, because the way we currently are doing things is wrong on so many different levels. There is no development cycle, no real structure, and no delegation of tasks and when people do offer to help, they are generally left out in the cold and in most cases, just walk away.

You say you want a framework. So do I am many other developers, but the biggest difference is in the way we both think it should be done. I am saying no to a modular framework, because I believe it is the wrong way forward for exactly the reasons I have stated already and I believe that if this if going to be done correctly, it should be within the core and maintained by the core.

I think am really done trying to get changes here, and personally I’m getting sick and tired of constantly having to butt heads with people over what should really be normal working practice in a community like this. The people I feel sorrier for the normal users, who just want to have their websites with good working modules.

hhttp://code.google.com/p/xuups/source/browse/trunk/modules/

I'm comiting xmf and xtest to Xuups repository as I type.

It has a lot of bugs, many typos. I'm mainly trying to structure this framework the way I would like Xoops to be structured. It is heavily based on smartobject and IPF.
I'm trying to favor composition over inheritance. There are some object helpers that can add behavior to objects on the fly, for example, objects can be initialized from an existing database table, title and description of object vars can be populated from a translation file, others to come...
There is the concept of object forms, object forms can recieve an object (previously decorated with an object helper) and render a full form based on the object settings. This way we favor configuration and convention and avoid the trouble of writing code.
There is also support for object datatypes (dtypes). Instead of being limited with int, textarea, textbox, url, ldate... we can drop other datatypes (currency, float, etc) with no need to hack any file.
There are classes for handling request validation, about pages, admin pages, etc

It is just an idea, I don't mind to trow this code to trash and pick a better one. It is just some food for thought.

Thank you Trabis!

Finally something that we can work with!

We all agree that XOOPS will benefit from a module Framework.

However, let's not make this a religious war about where it should be - stand-alone, or included in the Core.

The most important issue will be that developers agree on a particular framework and its features!

Then we can decide where is the best place for it...

So can we focus now on the Framework itself and its features?

Catz, I do appreciate all you said as it does help ME understand what is going on here better.


One of the strengths of OOP is that it is designed to be team based and when done correctly you can change the actual objects but the clients using those objects still work the same.

And maybe what I spoke before was not fully clear. In my mind the core and modules are two separate entities but they depend on each other. The core should be the backbone for everything regardless. They should both take on equal importance because one without the other is like having a car without doors, seats, pedals or steering wheel.

Sounds like what your saying is we have been building a car without an interior or doors and depend on the buyer of the car to include their own interior and doors.

MY intent with this if I am involved is to do pretty much what you suggest catz. The intention is more that it would be an extension to the core as opposed to a replacement or such. And with the intent of NOT duplicating code.

And yes I think we can all agree if something good comes of this it should be included in the core package and yes it should be updated to take advantage of new things as they become available.

And yes I DO hope that with this we build something that will be continually updated. Hopefully with a solid framework we can extend the lifetime of any "blue move" modules and any future modules that are created.

Anyhow enough said on this...

As someone somewhere else said...

Back to work... ;)

And thanks to those that have provided intelligent responses. This is a learning experience for me and I am trying to get up to speed so I can help out and it all helps.

Rodney

Quote:

'heavily based' doesn't even come close to describing the origin of the code.

Quote:

Please Catzwolf, quote all the lines in what I've written concerning this matter.
See the bold line which you left out, where I stated the reason why module developers started to create their own frameworks. Every module developer who creates his own framework for his module to work. And this exactly is what I find redicoulous.
I am pretty sure some code within these different frameworks are the same. And exactly this is what I find redicoulous. Therefore I like the idea melting these code together into one framework.


Since there were talking about the framework proposal, I wasn't talking about how xoops 3, or for that matter 2.4+ is developed and updated.
But if you want to know:
I second (and I am quit sure I've said this somewhere within another topic) that there must not be only one core developer. Open Source is working together, getting involved and be open about core code changes and informed about core code changes.
Getting involved is much more than on a regulary bases asking the community to get involved concerning the repository, wiki and so on (the way mamba keep on doing) but left out for participation concerning xoops core development. This doesn't give the overall spririt back into Xoops. Speciallly not to those who are over the years good and proven trustworthy xoops developers. They were set on a sidetrack which wasn't and isn't good.
Quote:
Developers keep asking (for years) what they can do for xoops, but unfortunately they are kept out of the core bussines. For reasons I still cannot understand.
The above sentence works both ways. Or at least should be working both ways. This will bring the spirit back into Xoops as a whole and even more.
For several years xoops development is cripple. And if nothing changes it will stay that way.
To be honest, the recent news release XOOPS Core Development Updates As Of August 1st, 2010 doesn't change much of this core (read X3) development problem. The basic structure, one man, stays the same, which is to my opinion a real pitty.


Don't forget, I do understand the frustration about module development and their developers also developers who have the ability to work on future xoops core but are left out. But I really believe that by creating a solid framework it would be a progression.

As of now I will shut up and let the pro's, if they still feel up to it do their work.
In advance I would like to say thanks for alle your efforts.