Contenido: Themefähigkeit, "Ajaxifizierung"...

trixta · Beitrag von **trixta** » Sa 2. Dez 2006, 14:04

Hallo,

ich habe gerade damit begonnen, mir das Backend in punkto Themefähigkeit und mögliche Ajaxifizierung anzugucken, um den "Workflow" zu verbessern.

Beispiel: Es wäre ja ein wirklicher Vorteil, wenn bei der art-overview die Funktionen (Wiedervorlage), Online/Offline, Artikel einfrieren/auftauen, Artikel kopieren und Artikel löschen "ajaxifiziert" würden, so dass beim ändern der Seite, nicht die ganze Seite neu geladen werden müsste und man beispielsweise in einem rutsch relativ schnell alle erstellten Artikel online stellen kann (da das ja asynchron und ohne neu laden läuft, wäre das ja echt nen netter Vorteil).

Bzgl. Themefähigkeit ist mir die cfg[colors] aufgefallen, welche ja nur teilweise genutzt wird und meiner meinung nach letztendlich obsolet sein sollte, da die Farbangaben ausschließlich über das css gesetzt werden sollten.

Das ganze wäre natürlich ne grosse Fleißaufgabe und daher stellen sich mir folgende Fragen:
1. kann man damit rechnen, dass 4fb eine solche Änderung meinerseits in zukünftige Releases einbauen würde (Es ist klar, dass das - ohne die Änderungen zu kennen - hier nicht abschließend gesagt werden kann.). Aber, ob dahingehend Interesse besteht.
2. Welche Dinge sollte ich berücksichtigen, damit die Wahrscheinlichkeit steigt, dass dies übernommen wird.

Ich könnte Mitte/Ende nächster Woche mal eine Änderung der art_overview hier vorstellen, damit das beurteilt und man eine Art Style-/Programmier-/Codeguide für die weitere Überarbeitung festlegt. (Ich setz mich allerdings da nur ran wenn 1. Frage zumindest mit nem waagen ja beantwortet wird.)

i-fekt · Beitrag von **i-fekt** » Sa 2. Dez 2006, 14:21

Die Themefähigkeit war mal geplant soweit ich weiß, aber im Laufe der Weiterentwicklungen hat sich das verlaufen und zu sehr vermischt, als dass man das "mal schnell" machen könnte.

Beitrag von **Dodger77** » Sa 2. Dez 2006, 14:36

Es gibt Pläne, gerade den Bereich "Content" extrem zu ändern/vereinfachen. Das wurde auf dem Communido schon besprochen. Wie weit das jedoch ist, kann ich nicht sagen.
Ich denke, dass dabei auch etwas in Richtung Realign des Backends allgemein abfallen wird. Mehr CSS-Einsatz, schlankerer Quelltext und die Verwendung von Ajax sollten eigentlich drin sein.

trixta · Beitrag von **trixta** » Sa 2. Dez 2006, 14:55

@i-fekt
dass das nicht mal auf die schnelle geht, ist mir mehr als klar. -> ("Das ganze wäre natürlich ne grosse Fleißaufgabe").

@dodger77
k, interessant. wenn die natürlich weiter fortgeschritten sind, hat sich das erledigt. ansonsten ist man evtl. an einer aufgabenteilung interessiert und hat bereits, da man sich damit beschäftigt hat, schon sehr konkrete antworten auf meine 2.frage.

herrb hat doch den direktesten draht zu denen, oder?

p.s.: ich hätte grossen bock da was zu machen...

trixta · Beitrag von **trixta** » Mo 4. Dez 2006, 19:02

kann ich die ausbleibende antwort jetzt als nein verstehen?

Beitrag von **Dodger77** » Mo 4. Dez 2006, 19:18

Was ist denn mit einem kurzen Anruf bei 4fb? Da wird man sicher die aktuellsten Informationen bekommen. Ist ja nun seit dem Communido auch schon wieder etwas Zeit ins Land gegangen.
Wenn sonst keiner was sagt, wird es wohl bisher auch keine weiteren Informationen seitens der Community geben.

Beitrag von **HerrB** » Mo 4. Dez 2006, 19:22

An der Planung hat sich nichts geändert. Den aktuellen Stand kann man sich in den Snapshots ansehen - Änderungen in der vorgeschlagenen Richtung wurden noch nicht gemacht.

Gruß
HerrB

trixta · Beitrag von **trixta** » Mi 6. Dez 2006, 16:35

Hallo,
ich habe jetzt nun doch ne kurzvariante der art_overview erstellt. alle stile sind nun in der contenido.css. ajax habe ich derzeit nur für online/offline machen erstellt. das entsprechend zu erweitern dürfte aber kein problem sein. (frage ist nur, ob das vom grundaufbau so bleiben kann).

downloaden könnt ihr das unter:
http://pfirsichmelba.de/art_overview-contenido.zip

installation einfach ins contenido verzeichnis (einige dateien werden überschrieben also sichern!)

einiges ist etwas unsauber, insbeonsdere bei der datei ajaxmain.php bräuchte ich hilfe, wenn das was werden soll. bei der datei handelt es sich um eine verstümmelte variante von main.php (gibt grds. kein xml aus).

Beitrag von **HerrB** » Mi 6. Dez 2006, 18:41

Hey, es hat jemand angefangen. Fein.

Ich würde alle Dateien, die für Ajax aufgerufen werden, zunächst in ein separates Verzeichnis stecken (z.B. contenido/ajax oder contenido/includes/ajax, betrifft include.artactionxml.php).

Die "ajaxmain.php" ist die Leitdatei, die als einzige Aufgabe zunächst nur die Überprüfung der Session durchführt und danach die eigentliche Funktions-AJAX-Datei aufruft/includiert/ausführt, die dann wiederum zunächst die Berechtigung überprüfen muss. Richtig?

pseudocron, $sess->register("errsite_idcat"); $sess->register("errsite_idart"); und das Setzen des Frames ist IMHO nicht notwendig, select($area) weiß ich gerade nicht.

Das sollte IMHO bereits in eine Switch-Anweisung, die eine area und action auswertet:

Code: Alles auswählen

include_once($cfg['path']['contenido'].$cfg['path']['includes'] ."include.artactionxml.php");

Die include.artactionxml.php sollte am Anfang überprüfen, ob sie auch von der ajaxmain.php aufgerufen wurde.

Das Ajax-Rückmeldungs-Template sollte generisch sein (braucht man dann evtl. mehrere für):

Code: Alles auswählen

<?xml version="1.0"{ENCODING}?>
<!-- BEGIN:BLOCK -->
{CONTENT}
<!-- END:BLOCK -->

Code: Alles auswählen

<!-- BEGIN:BLOCK -->
<{ELEMENT}{DETAIL}>
{CONTENT}
</{ELEMENT}>
<!-- END:BLOCK -->

Das würde schon für alles mögliche reichen.

Aber man kann natürlich auch noch die Detail-Ebene mitnehmen:

Code: Alles auswählen

<!-- BEGIN:BLOCK -->
   <{ELEMENT}{DETAIL}>{DATA}</{ELEMENT}>
<!-- END:BLOCK -->

My 2 cents...

Gruß
HerrB

trixta · Beitrag von **trixta** » Do 7. Dez 2006, 00:49

Hey, es hat jemand angefangen. Fein.

thx, is ein kleiner ansporn. der wichtig ist, angesichts des umfangs (mein template-ordner zählt 88 dateien, grauenvoll)...

Die "ajaxmain.php" ist die Leitdatei, die als einzige Aufgabe zunächst nur die Überprüfung der Session durchführt und danach die eigentliche Funktions-AJAX-Datei aufruft/includiert/ausführt, die dann wiederum zunächst die Berechtigung überprüfen muss. Richtig?

ich sag mal ja, du hast das besser erfasst als ich. deshalb meinte ich ja, dass ich hilfe brauche.

das setzen von area scheint notwendig zu sein, zumindest, führt er sonst keine änderung aus. setframe konnte ich streichen, musste jedoch darauf achten das function.con includet wird (in der geuppten version hatte ich das ding pseudomäßig mit nem frame-parameter gefüttert.)

Das sollte IMHO bereits in eine Switch-Anweisung, die eine area und action auswertet:
Code:
include_once($cfg['path']['contenido'].$cfg['path']['includes'] ."include.artactionxml.php");

das muss natürlich flexibler werden. meinst du ich soll jetzt mit nem get-parameter, das laden der jeweiligen Funktions-AJAX-Datei (zur zeit is ja eh nur eine) steuern oder in der art, wie contenido das in main.php macht? letzteres habe ich nicht nachvollzogen.

Die include.artactionxml.php sollte am Anfang überprüfen, ob sie auch von der ajaxmain.php aufgerufen wurde.

ist das notwendig, ohne aufruf durch/über eine "berechtigte" datei, produziert das teil doch eh nur fehler (die contenido-eigenen dateien, führen derartige sicherheitsabfragen doch auch nicht durch)? -> füge ich aber ein.

Das Ajax-Rückmeldungs-Template sollte generisch sein

wie das genau in der endfassung aussehen wird, steht noch nicht fest und hängt davon ab wie ich möglichst einfach alle actions erfassen und weiterverarbeiten kann. es gilt allerdings (soweit der planungsstand) ausschließlich als rückmeldung für die actions in der art_overview.

bin arg krank, werde aber versuchen im "fieberwahn" in den nächsten tagen ne nette version mit allen features zur verfügung zu stellen, die ich dann aufgrund deiner/eurer hinweise überarbeite und mich dann wohl oder übel auf das nächste template stürze (art_props; habe schon ne coole idee, welches die benutzerfreundlichkeit für den redakteur steigern sollte.)

Beitrag von **HerrB** » Do 7. Dez 2006, 11:43

meinst du ich soll jetzt mit nem get-parameter, das laden der jeweiligen Funktions-AJAX-Datei (zur zeit is ja eh nur eine) steuern

Ja. Im Moment würde es reichen, die Area und Action auszuzwerten - die main.php geht mit den Angaben in die DB und ermittelt dort (unter Verwendung von frame) via frame_files und files die Datei, die ausgeführt werden soll. Das gleiche Prinzip könnte man auch hier einsetzen (z.B. als eigene Tabelle oder als zusätzliche Spalte oder mit neuem Typ [statt inc und main dann ajax]. Das würde ich aber erst zum Schluss einbauen - ist jetzt noch nicht relevant.

Aber die später erforderlichen Parameter sollten halt heute schon übergeben werden.

ist das notwendig, ohne aufruf durch/über eine "berechtigte" datei, produziert das teil doch eh nur fehler (die contenido-eigenen dateien, führen derartige sicherheitsabfragen doch auch nicht durch)?

Sagen wir mal so, persönlich bin ich nicht so glücklich, dass man sich darauf verlässt, dass ohne gültigem Rahmenwerk wohl nix passieren sollte (die class.inuse.php und andere hatten da mal eine offene Tür).

Dass der direkte Aufruf im Moment keine schwerwiegende Folge hat, liegt nur daran, dass $tpl kein Objekt und $db keine gültige DB-Verbindung enthält. Aber will man sich wirklich auf darauf verlassen, dass man da nicht was tricksen kann und der PHP-Interpreter wirklich abbricht?

Daher auch der Wunsch auf einen Basis-Schutz - erspart auch die (u.U. kritischen) Fehlermeldungen...

es gilt allerdings (soweit der planungsstand) ausschließlich als rückmeldung für die actions in der art_overview.

Hey, wenn, dann entwickeln wir hier für die Ewigkeit: Ein generischer Ansatz kann auch den Einzelfall abbilden, der Einzelfall keine anderen Fälle...

Das hat mit der Action zunächst nicht so viel zu tun - mit AJAX muss ja die aufrufende Webseite immer das Feedback auswerten, d.h. es muss immer Feedback als XML gesendet werden. Mit den zwei oder drei Templates kannst Du eine beliebige Verschachtelungstiefe erreichen und damit für egal welchen Bereich das Feedback bereitstellen (und brauchst nicht für jede Action ein eigenes Template).

Aber Du könntest auch die class.cmltree.php verwenden: Damit sollte man objektorientiert die benötigte XML-Datei erzeugen können. Wäre sogar der bessere Ansatz...

Beispiel für die Verwendung findet sich in der class.module.php:

Code: Alles auswählen

    function export ($filename, $return = false)
    {
    	cInclude("classes", "class.xmltree.php");
    	$tree  = new XmlTree('1.0', 'ISO-8859-1');
    	$root =& $tree->addRoot('module');

		$root->appendChild("name", htmlspecialchars($this->get("name")));    		
		$root->appendChild("description", htmlspecialchars($this->get("description")));
		$root->appendChild("type", htmlspecialchars($this->get("type")));
		$root->appendChild("input", htmlspecialchars($this->get("input")));
		$root->appendChild("output", htmlspecialchars($this->get("output")));
		
    	if ($return == false)
    	{
			header("Content-Type: text/xml");
    		header("Etag: ".md5(mt_rand()));
    		header("Content-Disposition: attachment;filename=\"$filename\"");
    		$tree->dump(false);
    	} else {
    		return stripslashes($tree->dump(true));	
    	}	
    }

Gruß
HerrB

trixta · Beitrag von **trixta** » Do 7. Dez 2006, 12:42

hi herrb,

die class.xmltree sieht interessant aus. folgende fragen:

die class führt dazu, dass ich die ajaxmain wegschmeissen kann? ->

ich nutze die main.php gehe in die datenbank und nutze die von contenido bereits genutzten tabellen, um meine ajax-antwort-datei mit allem was ich brauche zu laden. statt wie bis jetzt ein template zu erzeugen, verwende ich dann die oben genannte class?

so gut und sauber?

trixta · Beitrag von **trixta** » Do 7. Dez 2006, 13:18

hi,

habe das jetzt mal kurz durchgetestet. ich mach das definitiv mit xmltree und nicht mit template. wahrscheinlich werde ich das noch -anders als unten gesagt - von der main getrennt lassen und die ajaxmain beibehalten.

was allerdings nur den grund hat, dass man sich die frage, wie man das am ende genau inkludiert bis zum schluss aufhebt. sollte 4fb das dann tatsächlich übernehmen, können die das über die bereits vorhandene struktur mit der main.php laden.

bis denne
alex

Beitrag von **HerrB** » Do 7. Dez 2006, 13:49

Um trotzdem drauf zu antworten:

die class führt dazu, dass ich die ajaxmain wegschmeissen kann?

Nein, Du brauchst ja erst die ganzen Objekte, die Session-Überprüfung usw. - das macht die ajaxmain.php.

Die main.php sorgt für die Webseiten im Backend - das würde ich nicht mit der zentralen Schnittstelle für AJAX vermischen.

Gruß
HerrB

Beitrag von **HerrB** » Do 7. Dez 2006, 14:16

Kannst Du erläutern, was in dieser Funktion passiert (z.B. die $-Syntax, woher das ajax stammt usw.):

Code: Alles auswählen

var rowid = $(elem).ancestors("tr").id(), artaction = elem.getAttribute('class');
	$.ajax({
  		type: "GET",
  		url: "ajaxmain.php?action="+artaction+"&frame=4&idart="+rowid.split("-")[0]+"&contenido="+sid+"",
		dataType: "xml",
  		success: function(xml){
			if(artaction == "con_makeonline"){
				$("#"+rowid+" .publisheddate").html($("published",xml).text());
				$("#"+rowid+" .con_makeonline img").attr({ src: $("online",xml).attr("src"), title: $("online",xml).attr("title"), alt: $("online",xml).attr("title") });
				($("online",xml).text() == 1) ? $("#"+rowid).removeClass('offline') : $("#"+rowid).addClass('offline');
				$("#"+rowid).removeClass('inProgress');
			}
  		}
	});
	$("#"+rowid).addClass('inProgress');

Kann sein, dass ich da schon ein wenig eingerostet bin...

Was macht die Datei jquery.js?

Ist das ein bekanntes Framework?

Gruß
HerrB