Kategorienbaum und Artikel abbilden
Kategorienbaum und Artikel abbilden
Hallo zusammen,
was ich im Core von Contenido vermisse, ist eine zentrale Stelle, sei es eine Funktion oder ein Objekt, über die man einen kompletten Kategorienbaum und eventuell die dazugehörigen Artikel bekommt.
Zur Zeit ist es so, dass diese Funktionalität des Öfteren verwendet wird.
Es sind mehrere Bereiche im Backend, die diese Baumstrukturen erstellen:
- Der wysiwyg-Editor für interne Links
- Kategorien den Artikeleigenschaften
- Statistik
- usw...
Alle verwenden im Grunde ähnlichen, wenn nicht den gleichen Code. Ist es eigentlich vorgesehen, dies in der zukünftigen Version Zentral zu verwalten?
Das würde die Redundanz/Wartung minimieren und die Programmierung von Modulen, Plugins vereinfachen.
Grüße
xmurrix
was ich im Core von Contenido vermisse, ist eine zentrale Stelle, sei es eine Funktion oder ein Objekt, über die man einen kompletten Kategorienbaum und eventuell die dazugehörigen Artikel bekommt.
Zur Zeit ist es so, dass diese Funktionalität des Öfteren verwendet wird.
Es sind mehrere Bereiche im Backend, die diese Baumstrukturen erstellen:
- Der wysiwyg-Editor für interne Links
- Kategorien den Artikeleigenschaften
- Statistik
- usw...
Alle verwenden im Grunde ähnlichen, wenn nicht den gleichen Code. Ist es eigentlich vorgesehen, dies in der zukünftigen Version Zentral zu verwalten?
Das würde die Redundanz/Wartung minimieren und die Programmierung von Modulen, Plugins vereinfachen.
Grüße
xmurrix
Re: Kategorienbaum und Artikel abbilden
ob es vorgesehen ist weiss ich nicht... vernünftig ist es allemal...xmurrix hat geschrieben:Alle verwenden im Grunde ähnlichen, wenn nicht den gleichen Code. Ist es eigentlich vorgesehen, dies in der zukünftigen Version Zentral zu verwalten?
*** make your own tools (wishlist :: thx)
Ich bin auch dafür - tatsächlich würde ich die aktuelle class.article.php (in contenido/classes) gerne in die Tonne treten und zusätzlich die Kategorien mit ins Boot holen... Eine schöne Idee.
Gruß
HerrB
Gruß
HerrB
Bitte keine unaufgeforderten PMs oder E-Mails -> use da Forum!
Newsletter: V4.4.x | V4.6.0-15 (Module, Backend) | V4.6.22+
Standardartikelliste: V4.4.x | V4.6.x
http://www.contenido.org/forum/search.php | http://faq.contenido.org | http://www.communido.net
Newsletter: V4.4.x | V4.6.0-15 (Module, Backend) | V4.6.22+
Standardartikelliste: V4.4.x | V4.6.x
http://www.contenido.org/forum/search.php | http://faq.contenido.org | http://www.communido.net
Hallo,HerrB hat geschrieben:Ich bin auch dafür - tatsächlich würde ich die aktuelle class.article.php (in contenido/classes) gerne in die Tonne treten und zusätzlich die Kategorien mit ins Boot holen... Eine schöne Idee.
Gruß
HerrB
gibt es schon Ansätze/Überlegungen, wie man sowas mit einer Erweiterung der DB-Abstraktionsklassen (Item, ItemCollection) realisieren kann?
Ich sehe da eine Schwierigkeit in der Umsetzung (Beziehung verschiedener Tabellen untereinander).
Gruß
xmurrix
Das an sich wird wohl nicht so das Problem darstellen, auch wenn die jetzigen Klassen in contenido/classes/contenido (eine Ebene tiefer) in dieser Hinsicht noch fehlerhaft bzw. unvollständig sein dürften.
Ich denke, dass class.article.php (bzw. ein Nachfolger) eine Zusammenfassung verschiedener Klassen sein könnte. So eine Artikel- und Kategorie-API wäre ja schon eine feine Sache.
Gruß
HerrB
Ich denke, dass class.article.php (bzw. ein Nachfolger) eine Zusammenfassung verschiedener Klassen sein könnte. So eine Artikel- und Kategorie-API wäre ja schon eine feine Sache.
Gruß
HerrB
Bitte keine unaufgeforderten PMs oder E-Mails -> use da Forum!
Newsletter: V4.4.x | V4.6.0-15 (Module, Backend) | V4.6.22+
Standardartikelliste: V4.4.x | V4.6.x
http://www.contenido.org/forum/search.php | http://faq.contenido.org | http://www.communido.net
Newsletter: V4.4.x | V4.6.0-15 (Module, Backend) | V4.6.22+
Standardartikelliste: V4.4.x | V4.6.x
http://www.contenido.org/forum/search.php | http://faq.contenido.org | http://www.communido.net
Hallo,
habe mit das Thema die letzte Zeit durch den Kopf gehen lassen, und etwas 3 DB-Abstraktions-Klassen (ApiRelation, ApiRelationCollection und ApiRelationItem) gebastelt, die Ansatzweise der Klasse Item und ItemCollection ähneln und Daten über mehrere Tabellen auslesen können. Davon kann man dann weitere Klassen ableiten, um auf Daten zwischen mehreren Tabellen zu kommen. Eine Manipulation von Daten ist nicht integriert.
Als Vorlage habe ich den Code zum Generieren der Linkliste in wysiwyg Editor hergenommen, sollte aber auch möglich sein, dies für andere Bereiche zu verwenden.
Aus dem Code der Linkliste aus wysiwyg-Editor (abgespeckte Version):
ist dann folgendes möglich:
Natürlich ist die neue Variante etwas langsamer, da hier die SQL- Statement zusammengestellt werden und auch zusätzlich einige Variablen, Funktionen, usw. ins Spiel kommen.
Was haltet ihr davon, lohnt sich das oder soll ich Idee verwerfen?
Grüße
xmurrix
habe mit das Thema die letzte Zeit durch den Kopf gehen lassen, und etwas 3 DB-Abstraktions-Klassen (ApiRelation, ApiRelationCollection und ApiRelationItem) gebastelt, die Ansatzweise der Klasse Item und ItemCollection ähneln und Daten über mehrere Tabellen auslesen können. Davon kann man dann weitere Klassen ableiten, um auf Daten zwischen mehreren Tabellen zu kommen. Eine Manipulation von Daten ist nicht integriert.
Als Vorlage habe ich den Code zum Generieren der Linkliste in wysiwyg Editor hergenommen, sollte aber auch möglich sein, dies für andere Bereiche zu verwenden.
Aus dem Code der Linkliste aus wysiwyg-Editor (abgespeckte Version):
Code: Alles auswählen
$html = '';
$db = new DB_Contenido();
$db2 = new DB_Contenido();
$sql = "SELECT *
FROM
".$cfg['tab']['cat_tree']." AS a,
".$cfg['tab']['cat_lang']." AS b,
".$cfg['tab']['cat']." AS c
WHERE
a.idcat = b.idcat AND
c.idcat = a.idcat AND
c.idclient = '".$client."' AND
b.idlang = '".$lang."'
ORDER BY a.idtree";
$db->query($sql);
while ($db->next_record()) {
$spaces = ($db->f('level') > 0) ? str_repeat(' ', $db->f('level')) : '';
$html .= $spaces.$aCat['name'].":\n";
if ($cfg['is_start_compatible'] == true) {
$sql2 = "SELECT *
FROM
".$cfg['tab']['cat_art']." AS a,
".$cfg['tab']['art']." AS b,
".$cfg['tab']['art_lang']." AS c
WHERE
a.idcat = '".$db->f('idcat')."' AND
b.idart = a.idart AND
c.idart = a.idart AND
c.idlang = '".$lang."' AND
b.idclient = '".$client."'
ORDER BY
a.is_start DESC,
c.title ASC";
} else {
$sql2 = "SELECT *
FROM
".$cfg['tab']['cat_art']." AS a,
".$cfg['tab']['art']." AS b,
".$cfg['tab']['art_lang']." AS c
WHERE
a.idcat = '".$db->f('idcat')."' AND
b.idart = a.idart AND
c.idart = a.idart AND
c.idlang = '".$lang."' AND
b.idclient = '".$client."'
ORDER BY
c.title ASC";
}
$db2->query($sql2);
while ($db2->next_record()) {
$html .= $spaces.'-> '.$db2->f('title')."\n";
}
}
print '<pre>'.$html.'</pre>';
Code: Alles auswählen
$html = '';
$CategoryTreeRelationCollection = new CategoryTreeRelationCollection();
$CategoryTreeRelationCollection->select();
while ($CategoryTreeRelationItem = $CategoryTreeRelationCollection->next()) {
$aCat = $CategoryTreeRelationItem->getFields();
$spaces = ($aCat['level'] > 0) ? str_repeat(' ', $aCat['level']) : '';
$html .= $spaces.$aCat['name'].":\n";
$CategoryArticleRelationCollection = & new CategoryArticleRelationCollection($aCat['idcat']);
$CategoryArticleRelationCollection->select();
while ($CategoryArticleRelationItem = $CategoryArticleRelationCollection->next()) {
$aArt = $CategoryArticleRelationItem->getFields();
$html .= $spaces.'-> '.$aArt['title']."\n";
}
}
print '<pre>'.$html.'</pre>';
Was haltet ihr davon, lohnt sich das oder soll ich Idee verwerfen?
Grüße
xmurrix
Ohne die Klassen ist das schwer zu sagen (hast Du sie schon oder war das mehr ein theoretisches Konstrukt)?
Persönlich fände ich es besser, wenn man der ItemCollection mitteilen könnte, wie zwei Tabellen zu verknüpfen sind und welche Felder zurückgeliefert werden sollen ... Dann brauche ich nur noch die drei Klassen zu cat_tree, cat_lang und cat zu verknüpfen und fertig ist der Lack.
Das Ganze würde ich dann in einer class.api.category.php in eine Funktion einbauen, die mir ähnlich der vorhandenen Funktion in functions.general.php die Liste der Kategorien mit Eigenschaften zurückliefert...
Gruß
HerrB
Persönlich fände ich es besser, wenn man der ItemCollection mitteilen könnte, wie zwei Tabellen zu verknüpfen sind und welche Felder zurückgeliefert werden sollen ... Dann brauche ich nur noch die drei Klassen zu cat_tree, cat_lang und cat zu verknüpfen und fertig ist der Lack.
Das Ganze würde ich dann in einer class.api.category.php in eine Funktion einbauen, die mir ähnlich der vorhandenen Funktion in functions.general.php die Liste der Kategorien mit Eigenschaften zurückliefert...
Gruß
HerrB
Bitte keine unaufgeforderten PMs oder E-Mails -> use da Forum!
Newsletter: V4.4.x | V4.6.0-15 (Module, Backend) | V4.6.22+
Standardartikelliste: V4.4.x | V4.6.x
http://www.contenido.org/forum/search.php | http://faq.contenido.org | http://www.communido.net
Newsletter: V4.4.x | V4.6.0-15 (Module, Backend) | V4.6.22+
Standardartikelliste: V4.4.x | V4.6.x
http://www.contenido.org/forum/search.php | http://faq.contenido.org | http://www.communido.net
Die Klassen existieren schon, wollte es nicht hier posten, da es zusammen über 1000 Zeilen sind. Das Beispiel vom vorherigen Posting funktioniert.Ohne die Klassen ist das schwer zu sagen (hast Du sie schon oder war das mehr ein theoretisches Konstrukt)?
Das wäre bestimmt die bessere Lösung, aber ich wollte an den vorhandenen Klassen kein Refactoring vornehmen, zumal ich ja noch nicht alles, was in Item und ItemCollection passiert, verstanden habe. Für mich ist er einfacher gewesen, was neues auf Basis der beiden Klassen zu erstellen.Persönlich fände ich es besser, wenn man der ItemCollection mitteilen könnte, wie zwei Tabellen zu verknüpfen sind und welche Felder zurückgeliefert werden sollen ... Dann brauche ich nur noch die drei Klassen zu cat_tree, cat_lang und cat zu verknüpfen und fertig ist der Lack.
Habe die Sourcen gezippt und auf meinem Webspace abgelegt. Wie schon vorher erwähnt, das Ganze ist nicht ausgereift, und daher ist der Code hier und da nicht unbedingt sinnvoll/richtig.
Download:
class.genericdb.rel._experimental.zip
Einzig die Pfade sind anzupassen, da ich hierfür einen eigenen Ordner innerhalb von 'cms/includes/' verwende.
Gruß
xmurrix