It is a difficult subject to discuss as the implications can be far-reaching.

If we divide modules into ports or native XOOPS modules, there will be borderline cases that could go either way. As Tom says, a ported module could be fully xoopsified or merely using XOOPS mainfile and have a xoops_version.php

But is it a measure of quality? Both yes and no, I'd say. No, because it says nothing about the quality of the code. Yes, because the more XOOPSified it is, the higher the chance of it working fully with future XOOPS versions - and the higher the chance of someone else being able to do further work on parts of the module.

On one hand, a simple checkbox for "ported module" could be added and show an image that says that this is not a native XOOPS module - but it would not have the gradient in how much it has been XOOPSified. On the other hand, it would not make sense to have module developers rate their modules on a scale that goes from "basic port" to "fully XOOPSified" with several steps inbetween. And having qualified XOOPS module developers go through each module and assign a value would not be practically possible.

We shall also consider the work involved in creating and managing categories for these two types of modules - there are 60 categories in the modules repository at the moment. Even though there wouldn't be ports in each of these, it would still be necessary to create quite a number of categories for ported modules.

It's tough.

At this point, I'm asking myself what we will accomplish from having this rating/distinction/marking of modules as being ports or not. I'd rather see the QA checklist being incorporated as it would give quite a few answers to the gradient. But again, that is a question of resources.

And for me as a module user, it doesn't really matter _that_ much (except that it would be nice to have a full QA checklist) whether the module is fully XOOPS coded or a basic port. If it doesn't work as I want it to or is too cumbersome because it uses a completely different interface, I'll find something else.
Or use it as inspiration for a new module.

Thanks all for your increasing number of comments
(i would like to hear some from the people who usually only observe and download on this site too - anyone reading this?)

some loose thoughts:

- Need to keep it simple in the end

- Some of this is drifting into the qa(quality assurance) area though. ;)

- Just my opinion: grading could be difficult for the tasks i have in mind which affects news and repository because it involves much more work which i see as a problem. So this might therefore be better put in the area of QA. Its simply not possible to deep investigate everything before publishing news or files because it would slow down things considerably. Based on QA such a classification could always be added afterwards to files in the repository.




@tom: i wouldn´t know of a reason why you should not assume that


[edit]Ok mithrandir posted faster

Couldn't we have like a cross between the rating and gradients like a MacDonald’s star system (not that I have ever worked there) yet asked what they mean.
Or like boy scouts that there is a system where you get badges for each thing accomplished...

like if a module has languages a box that is ticked in a normal repository heading... no separating as this means loads of extra work for admin and our self’s... deciding each time.

Yet instead have a place to check for each fulfilled item the module has.
So then showing any user what they are getting and where it may let them down?

I agree it could become quiet difficult, but only if you make it that way.

The way I see it is you have a check list, separate to the QA type thing, whereby you install a module and and test it, as it meets the standards the list is checked and the rating given.

The QA team then as you say at a later date after the submission can then give it a QA rating.

So you have an on the surface simple report/image rating and then a more in-depth one later.

With regards to the download section, I think creating separate sections for ports, true modules, ect would be lengthy work and again could be accomplished much easier by giving each module a rating, via an image.

Sorry to go back to joomla again but maybe you have an editors pic there too:



An editor could review the module and give feedback if the grading system is too complicated.

And the compatibility issue, with images:




As a seperate issue, is the idea of having an XOOPS demo site still kicking about, whereby released modules can be demo'd along with themes. like the open source site that lets you try out all different CMS's, but geared towards XOOPS modules and themes.

I know off topic again sorry, but are we going to at some point, have all modules and themes submited to the downloads sections and source forge to ensure availability is always there.

Quote:

Oh yes, it's certainly happening... and not too far off I believe (More news closer to the time )

Quote:

I have a feeling you wont wait too long for this either

But we are going off topic a bit

Thanks for that David, good to hear of more improvments on the way.

IF it contains ALL the essential elements contained in the
How to build your own XOOPS module
@2004 The XOOPS Project.

Document released under the Creative License.

Author theCat
English Translator hsalazar

It is a XOOPS module!

How To build a XOOPS Module

BS
Note: I did a google search to find the link to the documentation.

I agree documentation is a little hard to find, but google does help , I believe this is something that will be greatly improved over the following month or so, with the new XOOPS server, site, etc.

wow this post is from last year, forgot all about it.