anmerkungen: class.genericdb.php

[timo]

achso nein

link wird (bzw sollte) nie innerhalb der childklassen verwendet werden (z.b. im konstruktor), außer, wenn die Klasse selbst abfragen verwendet. link sorgt dafür, daß im Ergebnis einer Abfrage auch entsprechende Unterobjekte zurückgeliefert werden bzw daß man danach sortieren kann. Beispiele gibts leider noch keine, die finden sich bei uns in den Plugins (Contenido ist da an sich noch nicht so weit).

Die Thematik ist leider etwas schlecht zu erklären, ich mach's mal an einem Beispiel:

Beispiel 1: Möchte der Modulentwickler alle Artikel haben, die in einer bestimmten Kategorie vorhanden sind, so erzeugt er ein Artikelobjekt, verwendet darauf die Methode link, um die Kategorien zur Restriktion zur Verfügung zu haben. Das ist dann ein Aufruf direkt aus dem Modul.

Beispiel 2: Möchte ein Klassenentwickler, der die GenericDB nutzt, selbst eine Abfrage durchführen, wird er link in seiner Methode verwenden, z.b. Artikel->fetchCategories() würde z.b. ein Artikelobjekt instanziieren, dann mit link wie im 1. Beispiel verlinken und dann alle Kategorie-Objekte z.b. als Array zurückliefern.

[emergence]

ähm ja, ich bin grundsätzlich immer von beispiel 2 ausgegangen...

ich häng das mal ran -> http://www.contenido.org/forum/viewtopi ... =genericdb
damit ich's nicht suchen muss...

wenn ich das ganze richtig verstanden habe bildet die generic db an sich nichts anderes wie eine tabelle ab, deren einzelne objekte nach gewissen einschränkungen zusammengefasst sind... und ansteuern lassen sich die einzelnen objekte nur mittels primary key...

theoretisch müsste man aber vergleiche mit jeder x-beliebigen tabelle und feldern anstellen können um das ergebniss einschränken zu können...
die einschränkung ist aber nur dann möglich wenn eine weitere abgeleitete klasse basierend auf der genericdb existiert bzw man bedient sich der alten eingeschränkten select methode...

nur mal so nebenbei wie siehts da eigentlich mit dem speicherverbrauch der klasse aus ?

bitte das ganze jetzt nicht falsch verstehen,
aber es fehlt mir irgendwie der nutzen den mir das ganze bringt...

die entwicklung geht nicht schneller
die routinen oder abläufe benötigen mehr zeit
es ist komplizierter fehler zu finden
und der schlussendliche code wird immer schwerer lesbar
ziemlich massive einarbeitungszeit in den code

zumindestens ist das mein resümee nach zwei tagen intensiven zerpflücken der klasse...

[timo]

hinter dem Konzept der GenericDB liegt ein anderer Ansatz, der womöglich zu dem nichtverständnis der GenericDB führt:

Man möchte Tabellen in der Datenbank abfragen.

Was das Konzept hinter der GenericDB ist:

Sie ist ein Persistenzadapter für Objekte.

Was das Ziel ist: Niemals mit den Datenbanktabellen oder deren Funktion in berührung kommen. Das kann natürlich erst funktionieren, wenn alles innerhalb von Contenido auf GenericDB-Objekten passiert.

Das Problem ist, daß man die Konzepte nicht versteht, wenn man nicht schon längere Zeit mit Objektorientierung gearbeitet hat (soll kein Vorwurf sein) und POAs (so heissen die Java-Equalänte) kennt.

Um die Anschauung etwas zu vereinfachen: Es gibt Objekte, und diese haben Eigenschaften. Die Eigenschaften werden mittels GenericDB persistent gemacht.

Mein Eindruck von den negativen Punkten ist genau umgekehrt, ich versuche mal zu begründen:

- Die Entwicklung geht auf lange Sicht schneller, da sich der Entwickler, der die Objekte am Ende verwendet, sich nicht um irgendwelche Datenbankspezifischen oder Logikspezifische kümmern muß. Stand heute muß ich z.b., wenn ich die GenericDB verwende, mich nicht um Escaping kümmern. Ich weiß noch, daß ich früher ständig dieselben Probleme hatte, insbesondere eben das Escaping zur Datenbank.

- Die Routinen und Abläufe brauchen mehr Zeit, das ist richtig. Das ist ein Nachteil der Objektorientierung, ist aber nicht anders zu lösen. Ein Produkt, welches einfach wartbar ist, hat einen erhöhten Wert als ein Produkt, welches ständig durch Fehler Bauchschmerzen bereitet.

- Geht man davon aus, daß die GenericDB und die Konzepte dahinter fehlerfrei sind, so ist die Fehlersuche einfacher.

- Ich finde den Code lesbarer, aber noch nicht optimal.

Vielleicht wird es einfacher, wenn die GenericDB in Contenido selbst häufiger eingesetzt wird. Leider habe ich im Moment nicht die Zeit, meine Wünsche in Contenido umzusetzen - aber ich kann immerhin Anhand meiner Projektarbeiten belegen, daß ich 50-70% meiner Entwicklungszeit in Projekten einsparen kann.

Wenn jemand gerne direkt mit SQL-Statements arbeitet, so soll er das machen, aber ich verwende weiter die GenericDB, weil sie mir bei meiner Arbeit hilft.

[emergence]

Das Problem ist, daß man die Konzepte nicht versteht, wenn man nicht schon längere Zeit mit Objektorientierung gearbeitet hat (soll kein Vorwurf sein) und POAs (so heissen die Java-Equalänte) kennt.

mir ist schon bewusst das objektorientiertes programmieren eine andere denkweise für problemlösungen benötigt, aber es ist bei mir nun mal jahre her, dass ich irgendwas auf der basis gemacht habe...

eine etwas sauberere strukturierung des codes hätte mir beim verständnis der klasse sicher geholfen -> dem war leider nicht so...

Vielleicht wird es einfacher, wenn die GenericDB in Contenido selbst häufiger eingesetzt wird.

dem ist ganz sicher so...

aber ich kann immerhin Anhand meiner Projektarbeiten belegen, daß ich 50-70% meiner Entwicklungszeit in Projekten einsparen

ähm glaub ich dir auch sofort, wenn man die ganze zeit damit arbeitet ist das ja auch logisch...
wenn man neu damit anfängt benötigt man natürlich auch mehr zeit...

ich weiss nicht, mir fehlt da noch das tüpfelchen auf dem i, damit ich es effizent und zielgerichtet einsetzen kann...

auf der anderen seite, man muss nicht immer der selben meinung sein...

ich geh jetzt mal auf ein paar bier... prost

[timo]

viel spaß

[emergence]

den hatte ich

ähm ja sag mal was ist den class.metaobject.php ? da fehlt noch ziemlich viel doku in dem file...

ich seh mir gerade die classes/contenido/ files durch...
wenn ich eine klasse benötige binde ich die mittels

Code: Alles auswählen

cInclude("classes", "contenido/class.filename.php");

ein ? oder kommt da noch ein automatischer klassen nachlader ? (wär ne witzige idee)

na wie auch immer es wäre zb nicht schlecht wenn die genericdb eine info funktion hätte... sowas wie das hier

Code: Alles auswählen

function print_methods($obj) 
{
   $arr = get_class_methods(get_class($obj));
   foreach ($arr as $method) {
       echo "\tfunction $method()\n";
   }
}

dann wüsste man wenigstens was in der klasse zur verfügung steht ohne direkt nachzusehen...

[timo]

die Metaobject kannst du vergessen, das war mal ein Test

das mit dem cInclude wurde ja gemacht, weil es damals Probleme mit Windows gab und es durch include alleine nicht abgefangen werden konnte - normalerweise sollte jede Klasse die Dateien nachincludieren, die sie benötigt.

[emergence]

die Metaobject kannst du vergessen, das war mal ein Test

okay

das mit dem cInclude wurde ja gemacht, weil es damals Probleme mit Windows gab und es durch include alleine nicht abgefangen werden konnte - normalerweise sollte jede Klasse die Dateien nachincludieren, die sie benötigt.

ich weiss, bezieht sich auf das hier -> http://contenido.org/forum/viewtopic.php?p=33520#33520

ich meinte kommt da was zusätzliches für
Currently defined areas

also das man anstelle von

cInclude("classes", "contenido/class.filename.php");

cInclude("generic", "class.filename.php");

verwenden kann...

vielleicht sollte ich mich einfacher ausdrücken...

was hältst du von der info funktion idee ?

[emergence]

wie gesagt ich sehe mir gerade die classes/contenido/*.php durch

ein paar fragen dazu...

class.client.php

find ich bei class cApiClient
function deleteProperty

in class.genericdb.php hingegen nicht... würde diese methode nicht noch benötigt werden ?

zusätzlich in class.client.php findet sich zu beginn

Code: Alles auswählen

cInclude('classes', 'class.properties.php');

wird nicht benötigt da die class.genericdb.php diese datei ebenfalls included...

class.module.history.php
da fehlt anscheinend

Code: Alles auswählen

cInclude("classes", "class.genericdb.php");

ist sonst fast in jeder datei vorhanden...

class.categorytree.php
findet sich

Code: Alles auswählen

cInclude("classes", "class.metaobject.php");

wird nicht wirklich benötigt...

class.categorylanguage.php

Code: Alles auswählen

$this->_setMetaObject("cMetaCategoryLanguage");

und

Code: Alles auswählen

class cMetaCategoryLanguage extends cMetaObject
{...
}

wird dann an sich auch nicht benötigt... weil du gemeint hast ist nur ein test...
ähm wieso wird da und bei class.categoryarticle.php

Code: Alles auswählen

cInclude("includes", "functions.str.php");

eingebunden... ?

class.category.php

Code: Alles auswählen

cInclude("classes", "class.metaobject.php");

und

Code: Alles auswählen

$this->_setMetaObject("cMetaCategory");

und

Code: Alles auswählen

class cMetaCategory extends cMetaObject
{ ...
}

werden anscheinend doch benötigt ??

class.articlelanguage.php

Code: Alles auswählen

cInclude("includes", "functions.str.php");

schon wieder ?

mir ist grundsätzlich schon bewusst warum die functions.str.php includiert wird, aber die jeweiligen includes für die $this->_setJoinPartner... gehören meiner meinung direkt in die jeweilige klasse...

ähm nichts dabei denken ich mag die einzelnen sachen gerne vereinheitlicht... sich dann wieder durch das ganze system suchen zu müssen um rauszufinden wo die einzelnen includes nun sind ist gelinde gesagt ein schmarren....

[emergence]

hmm...

blöde frage

class.genericdb.php

wofür werden denn die

function _setMetaObject
und
function &getMetaObject

benötigt ? sind die nur testweise da ?

[emergence]

ich hab ne neue methode geschrieben damit man relativ easy rausbekommt welche es eigentlich gibt...

wird am ende von class ItemCollection ergänzt

Code: Alles auswählen

	/**
	 * showMethods()
	 * Shows all methods from genericdb class
	 *
	 * @param $showall boolean	show private methods
	 * @param $print boolean  return array or print result
	 * @return array or prints array
	 * @author Martin Horwath <horwath@dayside.net>
	 */
	function showMethods($showall = false, $print = false)
	{
		$arr = get_class_methods(get_class($this));
		foreach ($arr as $entry) {
			if (!preg_match('/^_/i',$entry) || $showall) {
				$result[] = $entry;
			}
		}

		if ($print) {
			print_r($result);
		} else {
			return $result;
		}

	}

die syntax ist ganz easy

möchte man zb alle methoden die nicht private sind bekommen
kann man das jetzt ganz easy wie folgt rausbekommen...

Code: Alles auswählen

<?php

$inuse = new InUseCollection();
echo "<pre>";
print_r($inuse->showMethods());
echo "</pre>";

?>

wie im comment enthalten schluckt das teil zwei parameter

Code: Alles auswählen

print_r($inuse->showMethods(true));

liefert auch die private methoden

möchte man sich das print_r sparen

Code: Alles auswählen

$inuse->showMethods(true, true);

tuts auch...

ich finds ganz hilfreich...

[timo]

die Metaobject-Sachen wurden in Kombination mit eben jenen Metaobjekten verwendet, werden aber nicht benötigt. Drinlassen müssen wir es trotzdem, da es noch mehrere Projekte gibt, in denen diese Funktionen verwendet werden (deprecated).

[emergence]

okay...

ich hab mir da noch was gebastelt, das mir eine austellung über alle im /classes/contenido/ ordner enthaltenen objekte liefert...

vielleicht nützt es ja jemanden...

Code: Alles auswählen

genericdb child classes 
(
    [class.layout.php] => 
        (
            [0] => cApiLayoutCollection
            [1] => cApiLayout
        )

    [class.area.php] => 
        (
            [0] => cApiAreaCollection
            [1] => cApiArea
        )

    [class.articlelanguage.php] => 
        (
            [0] => cApiArticleLanguageCollection
            [1] => cApiArticleLanguage
        )

    [class.categoryarticle.php] => 
        (
            [0] => cApiCategoryArticleCollection
            [1] => cApiCategoryArticle
        )

    [class.user.php] => 
        (
            [0] => cApiUserCollection
            [1] => cApiUser
        )

    [class.categorylanguage.php] => 
        (
            [0] => cApiCategoryLanguageCollection
            [1] => cApiCategoryLanguage
        )

    [class.module.history.php] => 
        (
            [0] => cApiModuleHistoryCollection
            [1] => cApiModuleHistory
        )

    [class.module.php] => 
        (
            [0] => cApiModuleCollection
            [1] => cApiModule
            [2] => cApiModuleTranslationCollection
            [3] => cApiModuleTranslation
        )

    [class.action.php] => 
        (
            [0] => cApiActionCollection
            [1] => cApiAction
        )

    [class.template.php] => 
        (
            [0] => cApiTemplateCollection
            [1] => cApiTemplate
        )

    [class.article.php] => 
        (
            [0] => cApiArticleCollection
            [1] => cApiArticle
        )

    [class.templateconfig.php] => 
        (
            [0] => cApiTemplateConfigurationCollection
            [1] => cApiTemplateConfiguration
        )

    [class.category.php] => 
        (
            [0] => cApiCategoryCollection
            [1] => cApiCategory
        )

    [class.categorytree.php] => 
        (
            [0] => cApiCategoryTreeCollection
            [1] => cApiTree
        )

    [class.containerconfig.php] => 
        (
            [0] => cApiContainerConfigurationCollection
            [1] => cApiContainerConfiguration
        )

    [class.file.php] => 
        (
            [0] => cApiFileCollection
            [1] => cApiFile
        )

    [class.client.php] => 
        (
            [0] => cApiClientCollection
            [1] => cApiClient
        )

    [class.framefile.php] => 
        (
            [0] => cApiFrameFileCollection
            [1] => cApiFrameFile
        )

    [class.container.php] => 
        (
            [0] => cApiContainerCollection
            [1] => cApiContainer
        )

)

@timo
ähm hast du zu den anderen sachen weiter oben im thread auch noch ne meinung ?

[timo]

nein im Moment leider nicht (Zeitmangel), ich finds aber auch immer ein wenig schwierig zu allem im Thread etwas zu sagen

[timo]

wie gesagt ich sehe mir gerade die classes/contenido/*.php durch ...

Ich habe so ziemlich alles bereinigt. Daß die functions.str.php eingebunden wurden hängt wohl damit zusammen daß das eine Klasse immer per copy+paste kopiert wurde

Schaden tun die Includes nicht, ich habe sie dennoch mal rausgenommen.

Das mit dem setJoinPartner habe ich nicht ganz verstanden...sieht meiner Meinung nach richtig aus...