It seems to me that there is a trend which I am not sure is a good one. Now, families of modules are requiring their own frameworks (to borrow a word) to be installed in the XOOPS root directory or elsewhere. This procedure is required for PHPPP's family of modules as well as for some of the Smartfactory modules. I understand (I think) the reasoning behind this: install common things just once instead of with each module, but the way it is being implemented seems to me to be counterproductive. The more steps there are in installing a module, the more room for error, the higher the probability of problems, the higher the number of requests for assistance, the heavier the burden on those who can help, and so on.

For example, take the installation of the Article module. If I understand it correctly, here are the steps:

1. Download Article
2. Since it requires Frameworks 1.10, download this
3. Since it requires Xoopseditor 1.10, download this
4. Extract Article to local disk
5. Find the article folder, buried 3 levels down, and FTP this to the modules directory. (Actually, I do this differently since FTP'ing multiple folders and files causes problems for me, but that's another story)
6. Extract Frameworks to local disk
7. Find the Frameworks directory, and FTP this to the proper locations
8. Extract Xoopseditor to local disk
9. Find the Xoopseditor folder and FTP this to the proper location
10a. (2.2 users) Now, you have to download the whole of XOOPS 2.0.16 just to get 2 files
10b. Extract 2.0.16, find the 2 files, and upload these to the proper location
10c. Since you are using 2.2 and don't need multiple megabytes of 2.0.16 taking up space on your hard drive, delete all of this extra junk
11. Go to modules admin, install the module, and test it
12 When it doesn't work, because somewhere along the way, you have missed, skipped, or screwed up a step, spend a lot of time trying to figure out why
13. When you can't figure it out, open a fresh bottle, get a long straw, and proceed to become inebriated
14. Once good and inebriated or when the bottle is empty, whichever comes first, swallow your pride and go hat-in-hand to the XOOPS forums and timidly ask for help, knowing all the while that it is your fault because you did something really stupid which any kindergartener should have been able to spot

Come on, there must be a better way. Mustn't there?

(Going to show the true depth of my ignorance, now)
Why, for example, can't the whole mess be included in one tar.gz file (so as to extract properly in cPanel which many use) which would then be uploaded to the XOOPS root folder and extracted? Each file would then extract to its correct location automatically.

"But," you say, "having the Frameworks files in place means that they do NOT have to be continually uploaded with each new module in the family." Well, so it does. The solution might be to have two tar.gz files: one WITH Frameworks, and one WITHOUT. Considering the many extra support requests saved, this seems to be a good investment of time.

I'm sure that there are 30 or 40 really good reasons why this can't be done, but still, there must be a better way. Mustn't there?

JFM

I see what you are saying, yet also see some of the bits that are not practical...
Xoops framework evolves at a different rate to that of modules, yet it is required by all.
So if that got updated and Article didn’t, then we would be stuck making new releases.
Also not everyone needs all the XOOPS editors and so left optional.
As 2.2.5 and 2.0.16 are merging, this will become less of a problem with extra files when finished.
Yet considering how complicated XOOPS is overall, it is far easier then some systems.

Would it be possible to make the frameworks into a "module"?

I know, it's fundamentally different from what a module really is. But if it could be treated like one by users it would really help simplify things again for the average XOOPS user. Install it like a module. Check versions like a module. Upgrade it like a module. Make changes to it like a module.

It would be a module that other modules use.

And then do the same thing for the editors?

Not really - by their nature, Frameworks & XoopsEditors aren't really modules.... call them "system files", if you like?

Basically they're files that extend XOOPS with other functions. Framewors includes other useful things such as Catchpas and others - that many modules can use.

I believe the 2.3 alpha uses a system directory called "Frameworks" - so Phppp's files are essentially using the same principle.

(The only exception is SmartObjects - which does the same sort of thing, but lives in the module directory)

The problem is that progress in core development is so slow. Module developers are forced to add features that should already be supported by the core.

and looking at the way things are going, frameworks will more then likely be a part of the core so that of the confusion will be lost.

Frameworks and xoopseditor both have me confused. I don't know if I have broken files, incomplete uploads or have something misconfigured. php_version is correct, but when I enable a different editor in what ever module offers the option, everything works fine except the form field itself, like "the scoop" in news for instance.

The dhtml option works, and thats it. I really haven't seen any benefit to having these "system" files added, but they're required by the module in order for them to work. So, I just have them there, and just let the modules that use them do their magic.

I'm so confused!

I spend more time baffling with various wysiwyg editors than anything else. There's only one that works properly OOTB and thats the one integrated in Content module. The idea of integrating an editor is a mixed blessing. It works without any hacking or fiddling, but at the same time, it's stupid to keep reusing editors that are cumbersome file structures.

Like Studio, Im confused and fed up with the hours of FTP-ing new editors to try.

Frameworks is pretty straight forward... but I wish more developers would also use Phppp's XoopsEditors as well - reducing the amount of messing around, duplication of work and files needed....