hi guys
In recent months, for my job, I've been working on updating some modules to make them compatible for use with Xoops 2.5.7 and update them using, where possible, the latest features offered by Xoops.
I saw that the differences between all those modules are huge, there is not a common standard, so I decided to create a "standard", "generic" and "empty" module that could be the starting point from which to create any other module

This is my work

https://github.com/luciorota/module_skeleton

When finished it could be a model for create modules with TDMCreate

Each contribution is really appreciated, in creating standard teamwork is essential.
So, please, contribute where and how you want.

Thanks

Excellent news!

I'll be testing it this weekend!

Lucio, this looks very good - it's definitely a very good start for a discussion about standard for a modules.
I have submitted few changes to GitHub, feel free to use or reject them.

I still have problems on the Front End with the \class\common\choicebyletter.php, but didn't have the time to dig deeper there.

Questions: why are you using a separate module Request, instead of the XoopsRequest?

tnx mamba
i'm still bust in module structure
i'm working on administration side, when finished i'll set my mind on frontend side
i'll remove custom request asap, in xoops 2.5.7 request class there are some issues when managing arrays that could be better...
thanks again for your submissions, just merged!

There is no rush, it's better to use this module as an "experimental lab" to try different approaches, while we're researching for "XOOPS Best Practices" is module development to be incorporated here.

I had the same issue as you did, i.e. there are too many variations on how to solve a particular issue, e.g. uploading a file, do pagination or do search in a table, etc.

In the past we had several attempts with the goal to standardize our key modules, like the "Blue Move" initiated by Catzwolf, then we talked about Admin GUI standards, which resulted in a great "Module Classes Admin GUI" by Mage. This was used to convert several modules to our "Basic Module Pack" that had the same Admin GUI across all of the modules.

Irmtfan did a very good job with his Tutorial on "How to write a standard module for XOOPS"

I am glad that slowly we are finally getting to have our key modules simplified and standardized for XOOPS 2.5.7.

However, the biggest challenge, and the most fun will be to work on a conversion of our key modules to XOOPS 2.6.0, using the wonderful work on "Common Utilities" by Eduardo "BitC3R0" that he will be porting to XOOPS 2.6.0. There is also the XMF (XOOPS Module Framework) done by Trabis, on top of which Richard did some experimental MVC that actually worked. Plus some very cool approaches developed by Tad and his team from XOOPS Taiwan.

So the plan is to refactor/rearchitect the Core and prepare it to be fully MVC (based on XMF), which is currently being done by Richard. Then use Common Utilities" from Eduardo as our "Presentation Layer", while extracting all cool features that are not directly related to "Presentation" and incorporating them into the Core. At the same time, we hope to engage Tad and his team, so we can benefit from their expertise as well.

But the first step is to use the current time to convert and standardize our existing key modules, so once we start moving to XOOPS 2.6.0, we'll need to convert each feature/functionality only once, and then reuse it in all the other modules. Pretty much the same what we did with the "Admin GUI"

Please help us by testing the module created by Luciorota, and by providing suggestions, or even better: a working code, that could be used in this module.

hi,
Too bad the name of "class" are written in hard. It should take all the files and rename hand.
I have used variables, classes and functions dynamic
Look at my old modules which I use as starting skeleton.

http://sourceforge.net/projects/chgxoops/files/Modules/vide.zip/download

Nothing to rename, just a copy / paste (except for MySQL file) for an operational base module and not conflict with other modules.

This module is not perfect and is not yet the standard of practice but XOOPS 2.6 to start and especially for cloning.

Viewing:
./include/install_function.php
./class/class_class.php

Cedrik, this exactly the feedback and suggestions that we would like to receive in this thread. In Open Source we are learning from each other, so your active participation is very much appreciated.

While our individual efforts might not be perfect, by working together and exchanging ideas, we can create something much much better!

I hope, others will jump in as well!

Cedrik, i'll study your work, it's an interesting approach to the problem.
I think that using variable variables could decrease performances and i suppose (but i'm not sure) that it could be a problem when you would create a module with more than 1 item...

I would like to create a skeleton module as template and use Smarty engine to generate all php code i need.

ie:


with



will be rendered as



It is a different approach... do not you think?
Xoops and Smarty have all structures and tools to do this.

ps: congratulations for the Wideimage Framework, we need a common image processing framework in Xoops core, and your work could be what we need.

Quote:
In XOOPS 2.6.0 we are using Zebra_Image, so I was planning to convert the modules I'm working on and which currently are using phpThumbnail to Zebra_Image. I've already done it here for the Pedigree module.
Source code of Zebra_Image is on GitHub

The nice thing is that is a compact (one-file only), lightweight library, and object-oriented:
Quote:
If you're missing something from the functionality there, please let us know.

Hi,
The use of a dynamic system (class, variable, function) above allows me to quickly create a module in the shortest lines.
In terms of resources, the module is not very greedy (except some parts which demand to be optimized). The biggest module I wrote for a client, contains 42 MySQL tables, it is a module of ERP for automotive dealerships. And in addition I can easily clone the module. The only real job is to change the language files, the file instaalation MySQL and add the files to add the necessary options.
I'll try to explain how the basic module:
in the file for the web page called:
"$entree" table contains all the fields for the page.
"$class" table contains all the class to load
 
In the "class" matching file:
$table_item, MySQL columns


The idea is:
- To create a fully clonable module (without further manipulation as copy / paste / rename the module directory)
- Creation of "class" generic for basic functions (read / write BDD form, security ...)
- Quick Add feature (by copy / paste) so each function, class must be completely modular.
- Cache system for dynamic class already generated.
- Quickly Adding fields in a file.
- The page loads only what it needs for its operation.

I am to create simple modules, secure, requires very little hardware resources, fast, functional and easy to modify (even for a novice)

If I understand, you want to use smarty to generate (or simulate) a module.
I haven't explored this track, I don't know if it's a good idea.
We don't have the same approach, I try to keep a (speed RAM, PIC, size,) hardware and ergonomic approach to the user. To estimate a module, I look at the lines of code (graphics rendering happens at the end)
It's good to have multiple approaches.