SimpleXML: Code-Modul streikt bei "zuviel" Zeilen.

evaki

Vorab gesagt, hier ging es um ein Experiment, bei dem der gereichte Code mal eben so per Copy-Paste zur Ausführung kommen sollte, was mit "textlong" nach entsprechender -          - Zeit gelang, weil der Vorgang an allen Ecken des Systems an Grenzen stieß. Die Dokus sprechen hier ja eine deutliche Sprache. Die - also uns auch bekannte - sinnvolle Ausführung über das Einlesen einer Datei stand somit in diesem Moment nicht zur Debatte - sondern es ging nach dem Motto, das mach ich mal eben mal so schnell nebenbei, also durchaus bastlergerecht. Ich bin nicht unglücklich darüber, daß wir hier vor Ort derartiges einfach mal so ausprobieren können!
Wie so manche Vorgänge, die mal eben so nebenbei..... , barg dieser - wie schon vermutet - auch Lernpotential.
Genau das >>"Wäre doch mal etwas, worüber man nachdenken könnte???" wurde also durchaus berücksichtigt. Was es in letzter Konsequenz bedeutet bzw. bedeuten könnte war aber nicht zu Ende gedacht, weshalb die Frage an DEV wichtig war.

Konsequenz = nix mit "textlong", weil's in der Praxis überhaupt keine sinnvolle bzw. entsprechende Verwendung gibt, außer es soll nach dem Motto "mit dem Kopf durch die Wand" gelöst, bzw. unbedingt das System gestreßt werden.

MfG. Evaki

DarkViper

Ich frage mich immer wieder, weshalb Probleme immer nach dem Motto "mit dem Kopf durch die Wand" gelöst werden sollen. ??
Ist da jemand so masochistisch und gibt !! 8756 !! Zeilen Text (was XML im PHP-Umfeld ja im Grunde ist) im Online-Editor ein???
Das sind bei durchschnittlich 50 Zeichen pro Zeile incl. Leerzeichen etc. rund 428 kByte.. eventuelle Multibytezeichen noch gar nicht mitgerechnet.

Selbstverständlich kann man die Datenbanktabelle 'aufbohren'. MEDIUMTEXT z.B. würde 16 MByte Daten fassen.. also 280.480 Zeilen ;)
Das wird dann interessant, wenn die Frage auftaucht, wer mehr Arbeitsspeicher verheizt, eine Instanz des Code-Modules oder das komplette WebsiteBaker. ;)
Auch stellt sich die Frage, wann die Speichergrenze des Javascript-Editors im Backend des Code-Moduls erreicht wird. Der Browser stellt bekanntlich für JS nur einen begrenzten Speicherbereich zur Verfügung, egal wieviel Arbeitsspeicher der Rechner hat.
Ich nehme jetzt einfach mal an (was mir logisch erscheint), dass der XML-Teil komfortabel in einem beliebigen Editor erstellt und per Copy&Paste in den Editor des Code-Moduls eingefügt wird.
Eine, in meinen Augen sinnvolle, einfache und komfortable Lösung könnte sein, nicht mit dem Kopf durch die Wand zu rennen.. sondern eine seitliche Eingangstüre zu nutzen.
Wie wäre es, den erstellten XML-Text in einer Datei zu speichern. Dabei die Section-ID in der Benennung zu verwenden um die Zugehörigkeit nicht zu verlieren.
Diese Datei in ein definiertes Verzeichnis im Media-Bereich hochladen.
Jetzt genügt im Code-Modul der Eintrag:

$xmlstr file_get_contents(WB_PATH.'/media/xmlcode/section_n.xml');
(evt. noch eine is_readable() Abfrage einfügen)

So wird der XML-Text direkt in PHP eingelesen und muss niemals durch den Javascript-Editor geschleust werden. Auch die Datenbank wird deutlich entlastet.

Wäre doch mal etwas, worüber man nachdenken könnte???
[url=http://www.youtube.com/watch?v=tmzDAz6ZvFQ]Der blaue Planet[/url] - er ist nicht unser Eigentum - wir haben ihn nur von unseren Nachkommen geliehen[br]
[i]"You have to take the men as they are... but you can not leave them like that !" :-P [/i]
[i]Das tägliche Stoßgebet: [b]Oh Herr, wirf Hirn vom Himmel ![/b][/i]

evaki

Anmerkung:
Mir ist bewußt, daß diese direkte und simpelste Form der Ausführung von xml normalerweise vermieden werden sollte, allein schon wg. Speicherverbrauch. Da springt der Hoster im Dreieck bzw. es wird möglicherweise die Ausführung verhindert. Bei eigens lokal konfigurierten Servern (inhouse) ist das aber kein Problem.
Man kann's also auch mit einem nachträglichen Patch ändern. Aber letztlich weiß der Modulnutzer bei derartiger Codeausführung schon was er da macht.
Mich interessiert aber hier die DEV-Seite, hier also die Frage, ob prinzipiell etwas (anderes) gegen longtext spricht.
MfG. Evaki
ps. Nur zu Info: XML kann auch in den Templates so per simplexml ausgeführt werden.  8-)

evaki

So wie das aussieht, das ist dann eine Frage an die DEV, ist anscheinend der Tabellentyp für "content" von TEXT auf LONGTEXT zu ändern, um das Ding zum Laufen zu bekommen?

Könnte man bei der nächsten Version also nicht nur eval() sondern auch das anpassen?

ps. Ist da außer in install-struct.sql `content` text noch was zu ändern?
Auch nochmal der Hinweis auf eval() "forum.WebsiteBaker.org/index.php/topic,31485.0.html"

So wird das Modul recht universell - für die, dies zu nutzen wissen - ohne für's Modul großartig klamüsern zu müssen. Bisher sind's zwei klitzekleine Änderungen, alls läuft wie gehabt bzw. gewohnt, kann aber mehr...
MfG. Evaki

evaki

Das kann ich man gaar nich ab.

Funktion is man soo:
<?php
$xmlstr = <<<XML

<?xml version="1.0" encoding="UTF-8"?>
xml-blabla...............


XML;
?>

Bei ca 1800 Zeilen is Sense - hab' aba 8756.

Bei kleinen Projekten klappte bisher alles reibungslos, aber nun "is die Kacke am dampfen".
Wer helft misch?
MfG. Evaki