[as solved as it can be] Proper way of retrieving another module's parameters

[plger]

Hi everyone,
I've been creating modules for a while now, and still struggle with the following problem. It has been slightly touched in other topics, but never got a satisfactory solution...
Let's say we have a template with two columns : the left one calls a module (we'll call this module call A), and the right one is the {content}. Now let's say that in the {content}, I click on a link to a module action, and my {content} is replaced by a call to a module (module call B), which could be the same module as call A or any other. Now the problem is the following : in module call A, how can I know what parameters are given to module call B?
So far, I've found 2 possibilities :
1) We move module call B BEFORE module call A, so that we can store the params for the module call A to retrieve. The output of module call B can be assigned to a variable and displayed later. But this seems inelegant, plus it requires changes to the code of both modules (if there are different).
2) We read the parameters of the module action (module call B) from the url. That's what I do right now, but it can get complicated because you have to deal with cases of normal, pretty or rewritten urls...

So basically, I'd like a way for my module to get to know what the other modules (or at least the module action link I've clicked on) are doing in the page. The cms decodes the url to get the module, action and parameters - so I find rather dumb to do it again by myself.
Have I just not found where it is stored? Is there a way to retrieve this?

Thanks,
Pierre-Luc

[calguy1000]

Module parameter information isn't stored.

It's parsed form the URL and from the POST variables, and then sent to each appropriate module.
the module id and the destination page is what controls what parameters get sent to which module.

What you want is a basic way of communicating state information between modules.  One way of doing this is to set data into session variables (that's probably the most convenient way).  However if module A needs to know about module B then you have an "order of execution problem"  (module A is called before module B) to work around.

The easiest way to do this would be to call module B before module A.  Module B could then set it's session variables, and module A could then read them. 

i.e:
{cms_module module='module_B' set_session_vars=1 assign='module_b_output'}
{cms_module module='module_A' read_b_session_vars=1}
{$module_b_output}

I think that this is the most elegant solution because it allows for the independent use of modules A and B.  and it allows for their use in different situations.  The website developer wanting to use them in this configuration just needs to be aware of the order that things get processed in.

[plger]

Thanks for the answer.
That's exactly what I was refering to as possibility 1). The problem with this is that you have to do some changes to B so that is stores the variables in the session. If I want to know which news articles is watched, I don't want to change the news module (granted, I could probably do an event...)
But is there really no other possibility? I mean, when the parameters are parsed, they aren't stored anywhere before being sent to the appropriate modules? (or is that done only when the {content} tag is met?)
(Sorry for the stubborness and thanks again)
Pierre-Luc

[calguy1000]

Nope... module parameters aren't stored anywhere.  They're passed to the module, then they go out of scope.

Now it wouldn't be hard to do... but you'd have to make a modification to any file in the core that calls DoActionBase
i.e: something like:

$gCms->modules[$modulename]['actionparams'] = $params;

and... there's no event that gets called before a module action is called either.

BTW:  I only see ctlmodulemaker assigned to you?  Have you written more modules?  Where are they?

[plger]

Ok, thanks for the confirmation, I'll stop searching

Rest assured that if my other modules are not in the forge, it isn't because of a greedy lack of cooperation, but simply because I consider them either unworthy (or too specific or immature), or because I did way too many times the kind of things ctlmodulemaker is designed to do...