Please find enclosed a new version of our work.
thanks for your comments.
We have to improve this, especialy on certification process.
marco

nb : this tool is designed for devs to help them : not to forget which core feature a module should have, which documentation, which tests it should pass, etc.. It's working paper, just use it as it is and do not hesitate to provide feedback/enhancements !

A new (draft) version is out.many thanks to kaotik.
Next step is to :
- freeze items,
- set certification process definitively.
- make a smoketest if necessary (beacause this tool is for devs only, since some technical aspects are listed).

marco

Comments:
I love the division into separate sheets. Gives great overview.

D1) Module Version
XOOPS uses a three-part version number for clarification, but modules should use a simple, two-part one. This is because the version is saved in the database as an integer with the value of the version number multiplied with 100.
So 1.4 would become 140 in the database. 1.4.1 would not be interpreted correctly by the system.

D4) Logo
Consistency is good, but maybe this one ought to be optional? At least it should not count too badly, if the logo is in a different colour or in a different design - as long as it is there.

D7) Extra directory
Classes should be in /class, admin files in /admin, sql files in /sql, blocks in /blocks, templates in /templates, language files in /language. After that, it's fair game, where the module developer puts module files.

A14) Duplicable
What is this doing here?
If module writers spent half the effort, they spend on making modules duplicatable, on proper categorisation, configuration and structure, the only reason for duplicating a module should be to get another element in the Main Menu block - which is hardly a good reason. I certainly don't think it is necessary to encourage this

S8) There is no XoopsTicket class. It is called XoopsSecurity.

Good work. We are getting really close now.

hello,

thanks for your comments, mith.

1/ Duplicable
Quote:
that's not the only reason. Many of us duplicate modules, especialy if you have a big website and many content writers.
Making module duplicable is easier if you think about it at the beginning of your module dev', by choosing good names ofr variables, etc.... I think is a worth extra feature, but should not count too badly.

2/ Module Version, Extra directory, XoopsTicket
corrected.

3/ Logo
where can I find original blanck logo ?
I'm ok with your coments. It deals with ergonomy, design constistency, and it's very important (think about our competitors)

I've added php5 compatibility + SEO. For this last, it's a way for XOOPS to be professionnal (i'll write some rules on that point).
I'm looking for a w3c compliant theme, that could be used as QA_testing_theme.
Mith, have you add "minaiato"'s hack (, as I can remember, sorry for mispelling) into 2.2RC, hack that brought XOOPS fully xhtml compliant?
I've added some security related links. I think this last part could perhaps be improved a little bit.

marco

Quote:
This should not be a discussion about whether cloning is good or bad, but you answer why you are doing it, not why you think it is necessary.

Whether a module can be duplicated is irrelevant to a QA test. It's just a feature of a module, like any other feature, and should not be part of the QA testing process.

And to answer your question Mith, of why... well, I can think of two reasons that I would want that feature available in some modules.

1. To group information logically.
imo the URL should reflect the content, because it's what people see and are used to using to get their bearings about where they are and what they expect to read.

A site that has many distinct sections of information can use a duplicated module for each area. That way all the pages belonging to a single section have modules/[section name]/ in the url. I don't like 'modules' in the url either, but that's off-topic, and something I've already been ridiculed for saying. It just depends on personal preference, like many other things.

2. For non-English sites.
It's more appropriate for non-English sites with non-English domain names to have the rest of the url using names that actually mean something in that language.

Well anyway, that's my view.

thanks rowd and mith for your comments.

We spoke around @xoops france about this tool, especialy about duplicable feature.

My intention was to find a great way to test if a module would interfer with another one. This test could be a way to test wether personalized function/constants could interfer with function of another module or not (ex: just Remember wfsection 1.5 permission control function).

After some discussion, the best and only way is to look deeply in the code to see if code use XOOPS naming convention. I can remember rowd worked a little on that point in the wiki.
--> I conclude this action can only be done manually, by an experimented dev. Checking and setting duplicable functionnality as a standart is not the best way.
--> this item will be removed

Nevermind, I will publish this week a new release, then make an official announcement in XOOPS news to have some feedbacks from devs.
In this one I have worked on some SEO optimization, that I think must be a standart if we want to promote XOOPS as a professionnal system.

marco

nb : thanks to hervet, thecat and french speaking team for their help and conviction !

I've opened a new thread.