CMS Made Simple Forums

Ich drehe mich seit Tagen im Kreis.

Ich bin dabei ein eigenes Modul zum Erfassen und natürlich Visualisieren eines Musikbestandes zu entwickeln. Bei der Erfassung der Covers stoße ich an meine Grenzen.

bevor ich jetzt ins Detail gehe, hier der Uploadlink http://rockarchiv-berlin.de/uploads/Rockarchiv.zip

Nicht erschrecken, das ist ein bisschen umfangreicher.

In action.recordedit.php versuche ich ein xajaxaufruf auszuführen. Der Xajax Aufruf wird aber irgendwie nicht richtig eingebunden.

Erstmal die Frage, mag mir jemand helfen?
Wo soll ich anfangen zu erzählen?

Denke, wenn das Modul fertig ist, ist das auch für die Gemeinschaft hier eine Bereicherung.

Da es schon sehr viele gelesen haben, aber noch kein Post zurückgekommen ist, mal ein bisschen Background.

Ziel ist es, in einer Eingabemaske ein Image hochzuladen. Damit der, der die Daten erfasst auch sieht, ob er das richtige Image hochgeladen hat, soll er es auch gleich in der Eingabemaske angezeigt bekommen. Außerhalb von CMSms habe ich das durch einen ganz kurzen ajaxscript Erfolgreich umgesetz bekommen.

CMSms bietet als Interfce Xajax an. Um eine 100% Integration des Moduls zu gewährleisten, will ich dieses Interface nutzen.
Soweit sogut. Nun zum Modul.

Das Modul Rockarchiv gibt (besser soll mal geben  )  Basieren auf eine Musikgruppe "MainDatensatz", die Möglichkeit, Tonträger, Platake, Bandreport usw. zu erfassen. Zu den Tonträgern soll natürlich auch ein Cover erfasst werden. Das erfassen von Tonträgersstammdaten erfolgt in der Datei action.recordedit.php.

diese beginnt mit der Xajaxeinbindung.
pageheader wird als Variable definiert, damit es nur im Recordedit, durch das Template, eingebunden wird. Das sieht auch sehr gut aus.

Die Function "show_CoverUploader( $coverImage = "" )" stellt das schon geladene Image oder ein dummyImage dar, wenn noch keins geladen wurde. Des weiteren wird ein Button visualisiert, der die Möglichkeit geben soll, das Image zu löschen, bzw. ein Image hochzuladen. Das ist dann auch der Ansatz für die Ajax_Funktionen content_loadCover und content_eraseCover.

Zur Zeit sollen Sie aber erstmal nicht mehr machen, als eine Meldung ausgeben, das sie Aufgerufen wurden. Das mit diesem Code:
Beim Aufruf der Funktion tut sich aber nichts, als würde diese Funktion nie aufgerufen werden.

Für Lösungsansätze bin ich dankbar.

Hast du schon versucht, die Ajax-Einbindung mit dem AMS-Modul umzusetzen?

http://dev.cmsmadesimple.org/projects/ajaxms/

To provide a module with an API allowing module developers to easily add Ajax functionality to their module without having to know the dirty javascript-stuff.

Das ist leider nur für's Frontend. Dachte, ich hätte da was überlesen, aber dem ist wirklich so.

Wollte das Modul gerade mal testen und erst mal eine Band eingeben.

Habe alle Felder gefüllt, aber nur eine Fehlermeldung bekommen  ...

Unknown column 'contact' in 'field list'

Stimmt, die Install legt nur einen Bruchteil der benötigten Felder an. Da ich noch in der Entwicklung des Moduls bin, habe ich mich darum nicht gekümmert. Der Ansatz gefällt mir aber. Werde jetzt die Installroutine bereinigen, einen Modultag erstellen und dann hat jeder die Möglichkeit, sich an der Sache zu beteiligen, bzw. die Ansätze für seine eigenen Module zu nutzen.

Dann isses natürlich schwieriger, etwas zu testen  ... was sagt eigentlich Firebug (FF-Plugin) dazu?

So, das Projekt aktualisiert, Installation legt jetzt alle Tabellen und Felder an. Modul im SourceForge beantragt.

FF-Plugin habe ich noch nicht benutzt, nur die Xajax Debug-Console. Die Meldet, wenn ich einen Bugy-Aufruf mache, zB Datenfelde auslese die garnicht vorhanden sind, genau das als Fehlermeldung. Wenn alles Fehlerfrei - naja ich denke, das Fehlerfrei - dann wird noch nicht einmal die Debug-Console gestartet.

Habe schon einen möglichen Ansatz, 2 Nächte mehr drüber im Bett rumgewälzt, da passiert viel, will das heute validieren, wenn ich damit weiterkomme ist es hier zu lesen.

Aus Funktionen, die in action.[name].php geschrieben sind, bekomme ich keinen Aufruf zum caller hin. Wie wird eigendlich die Datei action.[name].php verarbeitet?

Wenn ich mir die Ausgabe einer Moduladministration im Viewer ansehen, sehn ich als URL "admin/moduleinterface.php?module=[module]", bei Unterdialogseiten ist es dann "admin/moduleinterface.php?mact=[module],m1_,[action],0&[paramlist beginnend mit m1_].

Die alles Entscheidende Datei für die Modulabarbeitung scheint also die moduleinterface.php zu sein. Ich hab einen Ansatz, also nix wie hin dahin.

Der erste Blick, ist es eine flache Struktur, Objektorientiert oder Funktionsorientiert. Für Leute die sich noch nicht so sehr mit den objektorientierten Programmstrukturen beschäftigt haben, erstmal nachgesehen steht da irgendwo zum Anfang als Schlüsselword "class". Das ist die Einleitung für eine Objektorientierte Struktur. Sofort Zettel nehmen und aufschreiben, von wem ist die class abgeleitet, also folgt dem class noch ein extends. Weder das eine noch das andere ist in unserem Fall der Fall. Nächster Blick, ist der Aufruf Funktionsorientiert? Ganz schnell mal runtergescrollt, irgendwo das Schlüsselword "function" zu finden, dem ist aber auch nicht so. Das bedeutet, der Quelltext wird, so wie wir ihn lesen, von oben nach unten verarbeitet.

Die Datei beginnt mit der Prüfung der übergebenden Parameter und der Speicherung derer. Danach wird die Gültigkeit der "erkannten" Module geprüft und jetzt kommen wir zum Punkt, der uns wichtig ist. Ertsemal was, was man nebenbei mitnimmt. Wenn ich als Parameter "module_message = 'msg'" oder "module_error = 'msg'" übergebe bekomme ich eine Ausgabe, bevor mein eigenes Modul überhaupt gestart wurde, wao das könnte man für Fehlerausgaben nutzen. Aber nur so nebenbei. Viel wichtiger ist der Aufruf

echo $gCms->modules[$module]['object']->DoActionBase($action, $id, $params);

und da verlassen wir unsere scheinbar flache Abarbeitung. Um die Sache abzukürzen, es ist ein Sprung in /lib/classes/class.module.inc.php

.... ende für heute

Wie war die Frage nochmal? 

Ich glaube Du solltest Dich mal mit der API des CMS auseinandersetzen:

http://www.cmsmadesimple.org/apidoc

Lade Dir doch mal das Skeleton-Module herunter. Da wird eine Menge drin beschrieben, wie Module aufgebaut sein müssen etc.

CMSms führt automatisch die action.default.php für das Frontend und die action.defaultadmin.php für das Backend aus.
Das wird von der moduleinterface.php geregelt.
Wie Du selbst festgestellt hast steht in der URI:

1.) admin/moduleinterface.php?module=[module]

Wenn da nix weiter steht führt die moduleinterface.php automatisch die entsprechende Default-Aktion aus.


2.) admin/moduleinterface.php?mact=[ModulName],m1_,[Action],0&[paramlist beginnend mit m1_]

Die moduleinterface.php sucht also im Ordner des Moduls mit dem internen Namen [ModulName] nach einer Datei namens action.[Action].php.
Die Parameter werden dann in einem Array namens $params übergeben.

m1_ ist nichts weiter als eine ID für das Modul. Da Module unter Umständen mehrfach aufgerufen werden können, muss das CMS ja wissen welches Modul gerade welche Aktion ausführt. Diese ID wird in der Regel in der Variable $id übergeben.

NaN wrote: Lade Dir doch mal das Skeleton-Module herunter.

Evtl. helfen auch Lösungsansätze aus anderen AJAX-basierten Modulen

http://dev.cmsmadesimple.org/search/?ty ... arch=Suche

j.schwerin wrote: Ich bin dabei ein eigenes Modul zum Erfassen und natürlich Visualisieren eines Musikbestandes zu entwickeln. Bei der Erfassung der Covers stoße ich an meine Grenzen.

bevor ich jetzt ins Detail gehe, hier der Uploadlink http://rockarchiv-berlin.de/uploads/Rockarchiv.zip

Aufgrund einer Anfrage im Forum - ist hier noch eine finale Version zu erwarten?