1
redheadedrod
"Universal" module framework...

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?


2
Balzac
Re: "Universal" module framework...
  • 2010/8/4 7:36

  • Balzac

  • Just popping in

  • Posts: 68

  • Since: 2010/1/11


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.

3
Catzwolf
Re: "Universal" module framework...
  • 2010/8/4 9:04

  • Catzwolf

  • Home away from home

  • Posts: 1392

  • Since: 2007/9/30


Quote:

Balzac wrote:
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.


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.


4
redheadedrod
Re: "Universal" module framework...

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:

No offence taken,

I have been around Xoops for a long time and to me this is the second worst idea after dropping modules from the core package and I was proven right then and I fear I will be proven right again.

Little history lesson for you since I see you're pretty new. In 2002 I along with Herko created the XMDT, to help module aid modules developers and it did that well, in 2003 it because part of the core. I created dev.xoops.org along with many other module developers and we created many team to bring new modules to the Xoops users. There wasn't a need for a frame work then because the Core developer at the time reconsigned how imported modules were to the whole system. If we needed anything we proposed it to Ono and in most cases what we asked for was implemented into the core. For example, notifications, group permissions etc.

At the same time heading the XMDT, I also had my only module team running along side that, in fact, you will be hard pressed to find a module that doesn't have some of my own work in there.

2004 I created the very first framework for modules, DJ was next and then Smartfactory after that, why? Because the Xoops development team decided that module development wasn't important enough to warrant the time and effort to implement the most basic features that we have been asking for time and time again.

If you read back in these forums, you will see people do not want frameworks of any kind, the module developers don't wont one either and I can tell you this, me not wanting a frame work is utter bull, I want the framework where it should belong, with the core package. I have created enough of my own frameworks to get around the bugs, limits and the non existence of class and functions that should be available to all developers.

So, you propose that we have a framework for modules? Nice idea on paper, but it wont work for the very same reason that we have a crisis over the development of modules. Sure, at the start it will be looked after, but after a while it will just become another victim like most of all the other modules you see today.

I want a real lasting solution to the problem we have right now, the blue move that I started was to solve that problem, but unless it is done right, it will not work and I can tell you now, unless that frame work is developed, maintain and distributed by the core, it will not work.

Take a look around the other CMS's and you will not see anything as ludicrous as this idea. You will not see it in Wordpress, Joomla, drupal or even XoopsCube and yet we are expected to clear up a mess that we warned would happen 5 years ago.


And more from Catzwolf...
Quote:

Oh and a final word,

The other day I installed Wordpress for the first time in over 5 years and I was really impressed with what they have done. At that time, wordpress didn't have a look in, but now towers all over Xoops.

It was also nice not to have to go hunting to find modules (that may or may not work) and actually be able to create content straight out the box, and that is the way it should be.

As a module developer, I want to create modules, not frameworks to be able to just create new modules that of a standard that is required with web2. Because, the more time I spend doing that, the less time I spend on actually creating and updating my modules and that means, you the end user has to wait a lot longer for them.

5
Catzwolf
Re: "Universal" module framework...
  • 2010/8/4 18:57

  • Catzwolf

  • Home away from home

  • Posts: 1392

  • Since: 2007/9/30


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.





6
trabis
Re: "Universal" module framework...
  • 2010/8/4 19:39

  • trabis

  • Core Developer

  • Posts: 2269

  • Since: 2006/9/1 1


http://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.


7
Mamba
Re: "Universal" module framework...
  • 2010/8/4 20:39

  • Mamba

  • Moderator

  • Posts: 11366

  • Since: 2004/4/23


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?

Support XOOPS => DONATE
Use 2.5.10 | Docs | Modules | Bugs

8
redheadedrod
Re: "Universal" module framework...

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

9
skenow
Re: "Universal" module framework...
  • 2010/8/4 23:00

  • skenow

  • Home away from home

  • Posts: 993

  • Since: 2004/11/17


Quote:

trabis wrote:
It is heavily based on smartobject and IPF.


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

10
Balzac
Re: "Universal" module framework...
  • 2010/8/4 23:06

  • Balzac

  • Just popping in

  • Posts: 68

  • Since: 2010/1/11


Quote:
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.


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:
Don't ask what XOOPS can do for you, ask what YOU can do for XOOPS!

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.

Login

Who's Online

185 user(s) are online (102 user(s) are browsing Support Forums)


Members: 0


Guests: 185


more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: Mar 31
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits