hab mir mal den core ein wenig angeschaut, allerdings aus zeit gründen nur den von der 4.5.3 beta.
In der Datei
contenido/includes/function.con2.php Zeile 244 und 245
Code: Alles auswählen
$thisModule = '<?php $cCurrentModule = '.((int)$a_d[$value]).'; ?>';
$thisContainer = '<?php $cCurrentContainer = '.((int)$value).'; ?>';
wie du hier siest werden 2 Variabeln definiert, und mit einem Wert gefüllt ...
und Zeile 248
Code: Alles auswählen
$output = $thisModule . $thisContainer . $db->f("output");
Hier wird in einer Variabel die 2 generierten Variabeln mit dem des Outputcodes eines Modules zusammengeführt. Ergo ist müssten die beiden im Output code zu finden sein.
Im INPUT Bereich hab ich in der kurzen Suche die Stelle nciht genau verifizieren könne, aber nachdem ich mit die Datei
contenido/includes/include.tplcfg_edit.php und respektive die anderen die teplconfiguration betreffende dateien angeschaut habe (eher überlfogen ) konnte ich nur Folgende These aufstellen, die es noch zu belegen/beweisen gilt:
Im INPUT Bereich steht $cCurrentModule zur verfügung, da diese PHP-Variable mit in die TPL-Configuration einfließt, wie auch immer dies genau geschieht.
Für Die Containernummer innerhalb eines Templates gilt folgendes:
OUTPUT ----> $cCurrentContainer
INPUT ---> $cnumber ( wenn man die THese ableitet für diese Variabel ).
Naja, dies war ein wenig die Theorie, hier mal ein kleines Modul zum Testen:
Input:
Code: Alles auswählen
?><?php
echo "idmod: " . $cCurrentModule . "<br>containerid in tpl: " .$cnumber;
?><?php
für den OUTPUT
Code: Alles auswählen
<?php
echo "idmod: " . $cCurrentModule . "<br>containerid in tpl: " . $cCurrentContainer;
?>
setz dieses Modul in ein Layout/Template ein, und schau dir mal die Ausgabe an.
Am besten mit nem Layout in der Art:
Code: Alles auswählen
<html>
<head><title>test</title></head>
<body>
<container id="1" name="test_con1" type="test_modules" mandatory="optional" default="test_mod1"></container>
<br><br><br>
<container id="2" name="test_con2" type="test_modules" mandatory="optional" default="test_mod2"></container>
</body>
</html>
Hinweis: Ich kann weder absehen, in wiefern die Nutzung dieser Erkenntiss für Entwicklung von Modulen als gesichert sein mögen.
Auf jedenfall werd ich versuchen, diese Erkenntniss zu vertiefen, hoffe aber das vlt evtl Timo, Emergence oder einer der anderen erfahrenen Coder hier im Forum vlt nen Gedanken/Meinung/Hinweis dazu haben.
Und natürlich versuchen dies, insofern möglich ist, geschickt einzusetzen:
so long
Stefan
P.S.: Bei sowas kommt mir in den Sinn .. was wäre wenn mann beim anlegen eines Moduls nen weiteres Feld hätte -> reserve_X_vars und diese dann als combo machen könnte:
Code: Alles auswählen
$startValueID = $cCurrentModule * 1000;
$endValuID = $startValueID + <reserver_x_vars>;
damit könnte man eine möglichkeit schaffen, module mehrfach nutzbar zu machen, ohne das unerfahrene evtl CMS_VALUES/CMS_VAR einstellungen i code direkt suche müssen.
Allerdings würde dann eine überprüfung wieder sinn machen, die sicherlich nur mit sehr viel aufwand zu realisieren ist ... leider. Auf der nderen seite, 1000er Bereiche sind ja meistens ausreichend ... allerdings komtm dann vlt wiederum evtl eine Begrenzung des Zahlendatentyps zu tragen .. vlt, aber auch nur vermutung *seufz*
An einen Mod: bitte den thread mal in ein korrekteres board schieben, das hier hat nix mit 4.4.x zu tun, eher mit 4.5.x 
danke