I've being using Soapbox and Tiny Content.

Not that there is anything at all wrong with their functionality, but here is what I would like to know and/or suggest to the XOOP development team and other module developers.

When I change the name of Tiny Content in the modules admin, it would be nice if it would be propagated throughout the tiny conent module. So in instead of hardcoding the title to the "Tiny Content Menu" in it's block it would pick up the title of the Module name I set.



Any way thats my two cents for the moment.

This is an issue with TinyContent only? in that case it should probably be directed towards Chapi, who's made the module.

No it is not an issue with Tiny Content,

I used Tiny Content as an example.

It's an issue with just about any module.

While the user is given the option of renaming 'News' in which changes its name in the main menu, it does not change it any where else.

So what I am suggesting, is that when modules are written, and when the developer of the module refers the 'News' module in onscreen content, rather that just hardtext the word 'News' to use the name of the module as the user has defined it.

So that the blocks and fixed content as it were, headers, and were ever one would normally use the word "News' or 'Tiny Content', or whatever module they are writing, they instead insert a variable that references the user-defined name of the module.

krc

krc:

The propagation you mention shouldn't be really that hard, but in fact, module making implies taking care of two different propagations. Let me see if I can explain it right. Every module has in its table two variables: name and dirname; sometimes these variables have the same string; sometimes they don't (for instance, the News module has them equal, while the forum module has name = Forum and dirname = newbb).

For each module, you have access to these two variables through two lines in your xoops_version.php file:

$modversion['name'] = _MI_MD_NAME;
$modversion['dirname'] = _MI_MD_DIRNAME;

Of course, you can also write the names directly into xoops_version.php, but the recommended way is to use language constants so a user can change them at will.

In the modules admin page, each installed module is shown with a name under the icon. This name is extracted from the name field using:

$module->getVar('name', 'E')

So, basically, what's needed here is that, everywhere you want to display the module's name, instead of hard-coding it, you might use:

$module->getVar('name')

I learned this the hard way. While building Soapbox, I was asked to make it easy to clone. So I changed the name references. But instead of using the name, I was dumb enough to use dirname, which then I had to capitalize:

ucwords($module->getVar('dirname'))

or

ucwords($xoopsModule->dirname())

In fact, I still haven't finished correcting this stuff, but I wanted to share this here to maybe save a few minutes' time to other module builders.

So, the lesson is this: when building a module, create display references to the module by using

$module->getVar('name')

And, to make the module easy to clone, or easy to install in a directory different from the default one, create functional references to the modules directory by using

$module->getVar('dirname')

Maybe some code wizard could add a few points here (or correct me if I'm wrong), but this is really something that has to be taken into account if you want to build modules that users can easily adapt to their needs.

Cheers.

hsalazar .. thats the information I was referring to and thanks for your detailed explanation.

It was enlightening and helpful and I hope all modules developers would and will make use of it.

krc

This is an extremely useful thread. Quick follow-up:

Quote:

I am making a module that was originally going to be for reviews, but has grown into something much more flexible. If I want to enable an ability to rename the module at will through a preferences page in the admin menu, is this possible?

In other words, currently the line in my xoops_version.php looks like this:

$modversion['name'] = _MI_PJREVIEWS_NAME;

and my language file looks like this:

define("_MI_PJREVIEWS_NAME","Reviews");

So, I have to go into the language file and physically hard code the name. Is there a way to do it programmatically? Has anyone tried this before?

It occurs to me that I will also want to change these lines:

define("_MI_B_LATEST","Latest Reviews");
define("_MI_B_SUBMIT","Waiting Reviews");

So, it isn't just one line that a user would have to change to make the whole module take a different name.

Thanks in advance for any advice.

*bump*

You could perhaps make the name "Reviews" a module config option, but it would be difficult to incorporate into all your strings.

Would the following accomplish what you want? i.e. just require a change in one place?

define("_MI_PJREVIEWS_NAME","Reviews");

define("_MI_B_LATEST", "Latest " . _MI_PJREVIEWS_NAME);
define("_MI_B_SUBMIT", "Waiting " . _MI_B_SUBMIT);

Note also that for naming your language constants, it would be better to use _MI_PJREVIEWS_B_LATEST and _MI_PJREVIEWS_B_SUBMIT instead of _MI_B_LATEST and _MI_B_SUBMIT.

Quote:

Yeah, that would make things easier. But it would still require a change to a file, rather than in a control panel. I'm trying to make renaming this module as painless as possible, since I want to have two or three instances of it on my site for very different purposes. I guess there's a limit to how much flexibility it can have, though.

Quote:

Yes, thank you for reminding me. I have a bit of this kind of cleanup to do before I can safely release the module.

Not that I fully understand all the code posted so far, but isn't there two issues here?

How to make the modules almost effortlessly cloneable, and naming the module?

I mean from an admin point of view there is simply using the dirname or at least just one line in the xoops_version file (or whereever one names the module). So that achives cloneablity, assuming one writes it accordingly.

The second question is from a user standpoint, i.e. how does the 'module', and it's elements (entries, lists, categories) present themselves on the screen?

For my 'very' limited experience in adapting modules, I simply use the language file to achieve the modules' 'user side' functional/appearance. For instance I wanted a simple directory that users could submit a 'statement' about some project they are involved in. So I worked on adapting 'myguestbook' by narga. I fould I could do a lot by using the 'language' file to do a 'makeover' of a module.

that's my thoughts for the moment.

krayc