CMS Made Simple Forums

I am curious whether the module class allows a way for one module to modify another.  I can think of two examples where this ability would be useful:

Example #1 - Authors as an extra field
Suppose you have a client who is an online content publisher.  You want to use either News or CGBlog as the article engine.  But you want to create a separate module for Authors that generates a bio page with links for each Author in the system.

But now you need to put a dropdown list of Authors as an "Extra Field" for the Article/News module.  This list is dynamically generated by the Authors module.

Example #2 - You want to build a tags module to work with news, with auto-suggestions, similar to the tagging module in Wordpress.

If there was some kind of "Extra field class" that would allow one module to register with another as the supplier of an Extra Field with a dropdown menu, this would allow some very powerful mods.

Anything like that exist?  Should it exist?

Sorry to bring back this old thread, but I thought these questions were interesting. I've stumbled quite a few times on them already:
"FEmessages", for instance, retrieves FEU users dropdown
"Attach" retrieves pages, news and such
Modifications to CartMadeSimple to make it compatible with other modules
and I'm trying to implement cross-module genealogy for the next release of CTLModuleMaker...

But as to whether there should be a class method for doing this, I'm not sure...

Let's take FEmessages: I wish to retrieve a FEU user dropdown, and I need the user name and user id. But the username to display depends on what you're doing (something you wish full name, sometime something shorter) and on the FEU settings (are there name fields at all?). And for integration with NMS, for instance, I didn't need userid at all, but user email instead...
Even if we create a method with parameters, for example : Then you have to ask in which data the format is returned: FEU works with associative arrays, in which the properties is a sub array, whereas other module may work with StdClass or such... If there is a uniform method, it should return uniform things. Which means that the FEU module, in order to implement the GetEntities function, would need to rewrite a whole fetching function outside its api.
So the question comes down to whether it's more work to do it yourself (by hacking the news module, for instance) every time you wish two modules to work together. When you look at it, or query the db tables yourself isn't very complicated, and it allows you to fetch exactly what you want, exactly the way you want it in this precise case.

Of course, theoretically speaking I love the idea that each module handles entities and that entities should have a basic shape. But it would be a pain to the developers to adapt to it, and I wonder if it's worth it?
plger

It is easy enough to write a UDT or plugin to produce the output that I want.

The problem is making it easy for the end user to add articles, etc.  If they have to look up an author ID in the author module and then enter it in the article module, it adds a few steps that few are likely to remember to do.

I am generally reluctant to modify standard modules like news, because it becomes a major hassle each time I upgrade the CMS core to go back in and redo my changes.

So what I would like to see is a standardized way of calling a 2nd module to populate a pulldown list for an extra field.

Ken

I understood very well what you wanted, I'm just unsure what kind of standard would be useful.
As you say it, you can very well call a UDT to get the desired output - I usually have a "text" extra field, I hide it's normal input in the form template and instead call a UDT to display its dropdown version. It requires no modification of the News module (just templates) and users don't even see it.
But to me this reflexion went further that this specific problem, and further than a feature request for the News module... but like I wrote, all my ideas ended up being more problematic than helpful, so I thought I'd enter the discussion...