 Schablonengesteuerte Datenbank |
|
|
| Schablonengesteuerte Datenbank |
Beitrag Nr.: 1      |
Ich habe mir mal einige Gedanken gemacht, wie die angessprochene Datenbank aussehen müßte.
Grundgedanke:
Eine „Datenbank“, ähnlich eines Wikis, zum erstellen von Inhalten mit Text und Bildern, nach Vorgaben (ACP-gesteuerte Schablonen). Durch die Erstellung und Steuerung der Grundschablonen wäre eine völlige Anpassung an die Aufgaben möglich, z.B. für meinen Fall eine Fisch– und Pflanzen sowie Niedere Tiere Datenbank, aber möglich wäre ebenso eine CD-DVD-LP Datenbank, eine Tutorialdatenbank, eine Rezeptdatenbank, Auto- & Herstellerdatenbank usw.
Ich beschreibe das ganze mal anhand einer Fisch & Pflanzendatenbank, um gleich auf die einzelnen Anwendungen eingehen zu können.
Frontend (Was der User sieht)
Beim betreten der Datenbank sieht der User Überkategorien, Kategorien, eine Suchfunktion, eine kleine Statistik und die Möglichkeit Einträge zu schreiben.
Eine Suchfunktion erscheint sinnvoll, da die Datenbank ja keine Beiträge ins Forum schreibt, und somit die Forensuche hier nicht greift.
Das ganze noch einmal in Html-Ansicht, (Mit Tabelle) um die Grundstruktur besser darstellen zu können
Beim betreten einer Kategorie werden die schon vorhandenen Einträge angezeigt. Außerdem ist zusätzlich eine A B C—Funktion oben, um bei größeren Datenbanken das auffinden eines bestimmten Beitrags zu erleichtern
Der bisherige Aufbau ist ein einfacher Templateaufbau, ohne Schablonenfunktion. Bei klick auf einen der schon veröffentlichten Einträge öffnet sich der entsprechende Eintrag. Hier würde der Aufbau als Schablone beginnen.
Die Schablone dazu zur Beitragserstellung
Diese Schablone muß durch Definition einzelner Felder und dem Anordnen und zusammenfassen dieser Felder im ACP erstellt werden.
__________________
Bis auf weiteres nur eingeschränkter Support
|
|
20.01.2011 00:53 |
 
|
|
|
|
Kategorien und Überkategorien erstellen
Wichtige Punkte sind: Kategorie oder Überkategorie, die Einordnung der Kategorie in einer Überkategorie und das auswählen eines speziellen Icons aus einer Liste, die speziell für diesen Hack geschaffen wurde.
Die Kategorien sollten danach wie eine Forenauflistung angezeigt werden, und eventuell dann auch wie bei Foren über Nummern verschoben werden können.
Probleme
Durch die Schablonisierung der erstellten Beiträge ergeben sich natürlich gewisse Probleme. So könnte man später einer Kategorie nicht einfach eine neue Schablone zuweisen, denn dann würden die vorher erstellten Beiträge nach altem Muster falsch ausgegeben werden, oder gar zu schweren Schäden führen.
Ich würde es so lösen, das man Schablonen nicht löschen kann, sondern nur Deaktivieren (Wenn Beiträge damit erstellt wurden, also vor dem löschen eine Abfrage ob Beiträge vorhanden sind, wenn ja eine Fehlermeldung/Warnung)
Wenn man eine (SQL) Tabelle benutzt für die angelegten Felder, eine weitere für die Schablonen, und eine dritte für die Kategorien, dann kann man in einer 4ten Tabelle wo die Beiträge gespeichert werden die benutzen Schablonen mit eintragen, und bei der Ausgabe eine Deaktivierung der Schablone unberücksichtigt lassen, so das alte Beiträge auch in der zur Erstellung genutzten Schablone ausgegeben werden. Das gleiche gilt wohl auch für die einzelnen Felder, denn auch ein löschen eines Feldes, was schon benutzt worden ist würde zu Fehlern führen.
__________________
Bis auf weiteres nur eingeschränkter Support
|
|
|
20.01.2011 01:16 |
|
|
John 
[meine Galerie]
Dabei seit: 20.02.2010
Beiträge: 691
Herkunft: südl. Münsterland
Postid: 6939
 |
|
Was ist den mit der Datenbank vom JGJ-DB, ist das nicht so etwas in der Art? Und von Alfie gibt es eine Rezept DB.
__________________
LG... Johann
|
|
|
20.01.2011 03:30 |
|
|
|
|
Es geht nicht um eine Filebase, sondern um eine individuell anpassbare "Daten-Bank".... im direkten Sinne des Wortes. Quasi ein Wikiersatz mit speziellem Zuschnitt auf ein Forum. (Ein Fachwiki). Die Rezeptdatenbank als solches benutzt zwar auch schon eine Schablone, allerdings ist diese statisch. In meinem Fall z.B. als Fisch und Pflanzendatenbank würde ich schon über 20 einzelne Felder benötigen, soetwas ist mit der Rezeptdatenbank einfach nicht zu realisieren. Wenn man dann das ganze auch für andere Foren einsetzen will, muß die Felderstellung sowie die Schablonenerstellung schon flexibel möglich sein.
Siehe z.B. den Tread von World-of-Xtreme
Suche Charakter profil Hack
Man könnte diese Datenbank so als Charakter-Profil einsetzen, indem man Felder dafür definiert, wie man eine Spielfigur darstellt.
Ganz davon abgesehen wird der Ersteller der Rezeptdatenbank meines wissens keine Erlaubniss dazu geben, seinen Hack umzucoden.
Falls nun der Tip kommt ein Wiki selbst in das Forum ein zu binden... das ist ebenfalls nicht Sinn der Sache, kaum ein User wird in ein normales Wiki schreiben, ganz einfach schon auf Grund mangelnder Kenntnisse in html. Sinn und Zweck soll es sein, dem User eine einfache Lösung zu bieten, einen Datensatz anzulegen, ohne dafür spezielle Kenntnisse zu benötigen. Die mitarbeit in Foren bzw. die nicht mitarbeit scheitert meißt schon daran, das die User zwar etwas schreiben wollen, aber eben nicht können. BBCode ist noch recht simpel, aber ich weiß, das schon viele daran scheitern, einen Tread auch übersichtlich darzustellen, und es dann lassen. Bei html ist es nun einmal so, das die allerwenigsten dieses beherrschen. 
__________________
Bis auf weiteres nur eingeschränkter Support
|
|
|
20.01.2011 05:21 |
|
|
|
|
Ich gehe davon aus, das wir ca. 5 Datenbanktabellen anlegen müßten.
Nennen wir diese mal BBx_wiki_????
(Ich denke mal, es gibt diesen Namen bisher nicht für das WBB 2.3.x)
1. BBx_wiki_allgemein <------- Definition von Feldern, also Feldart 1 = Pulldown usw, also eine Tabelle, die aussagt, um was für eine Art von Feld es sich später handelt.
2. BBx_wiki_feld <----- Hier müßten die einzelnen Felder die angelegt werden abgespeichert werden. Als Beispiel wieder die Zierfischdatenbank.
Feldid :1 (Fortlaufend) ... Name: Name (Weil hier der Fischname definiert wird) ... Art des Feldes :3 (Textfeld klein) Muß gefüllt werden Variable 1/0 : 1 (Pflichtfeld) usw. Diese Tabelle würde ausgelesen werden im ACP z.B.
3. BBx_wiki_schablone <------- Hier werden die einzelnen Schablonen abgespeichert, also SchablonenID: 1 .... Zugeordnete Felder in Reihenfolge wie sie aufgerufen werden sollen ausgelesen aus der BBx_wiki_feld. 1,3,7,8,9, usw.
4. BBx_wiki_kat <------- Anlegen der Kategorien und Unterkategorien, sowie zuordnung, welche Schablone in welcher Kategorien benutzt werden soll
5. BBx_wiki_treads <---- Speicherung der Beiträge. Zusätzlich MUß im Beitrag die SchablonenID gespeichert werden, um im Falle des auslesens bei einer nicht mehr aktiven Schablone den Tread noch in der früheren Schablone anzuzeigen
Über den genauen Inhalt der Tabellen kann ich noch nichts aussagen, wir müßten erst einmal besprechen, was für Felder erstellt werden können. Es müßte auf jedem Fall etwas umfangreichere Eingabemöglichkeiten geben als die Grundfunktion des wbb 2.3.6 für z.B. Profilfelder bietet.
Ich denke, wir sollten anfangen erst mal mit 2 Tabellen. BBx_wiki_allgemein & BBx_wiki_feld. Damit sollten wir erst einmal die Grundfunktion erstellen, wie man Felder anlegt, und wieder ausliest. Außerdem die möglichkeit das Feld zu löschen (Vorherige Abfrage, ob es schon benutzt wurde, dann Fehlermeldung) und das Feld zu deaktivieren (Möglichkeit, um das Feld nicht weiter zu benutzen, falls schon benutzt, um nur noch eine Ausgabe zu ermöglichen)
__________________
Bis auf weiteres nur eingeschränkter Support
|
|
|
24.01.2011 16:28 |
|
|
|
|
Ich denke, wir reden noch etwas aneinander vorbei.
Der Grundgedanke ist bei mir der, eben vorher Nicht zu wissen, was ich benötige. Sprich, ich lege die benötigten Tabellenfelder erst im ACP fest.
Bei dem Charakter-Hack sind ja die benötigten Felder vorgegeben. Deswegen war es im Prinzip recht simpel, dazu eine Ein- und Ausgabe zu basteln.
Ich wollte hier einen Schritt weiter gehen. Ich erstelle quasi im ACP als ersten Schritt erst mal einzelne Felder. Erst wenn ich diese einzelnen Felder zusammen habe, als Liste, erstelle ich mir überhaupt die Eingabe (Quasi ist die Schablone dann die Eingabe, wie sie beim Charakter-Addon verwendet wird, allerdings nicht im ACP, sondern für den User)
Würden wir hier jetzt wie beim Charakter-Addon vorgehen, würde es wieder eine starre Struktur werden, das ist aber nicht gewollt
(Natürlich ist noch nicht alles genau durchdacht, zumindest nicht in Bezug auf mögliche Fehlerquellen)
Was also als erster Schritt gemacht werden soll ist: Eine Möglichkeit, Felder zu definieren. Will ich ein Textfeld... wenn ja, wie viele Zeichen...
Will ich ein Pulldown... wenn ja, welche Auswahlmöglichkeiten, und wie viele
usw.
Der zweite Schritt wäre dann, selbstdefinierte Felder zu einer Schablone zusammen zu fassen. Also Feld Name an Position 1, Feld Synonym an Position 2.
Benötigte Felder:
Textfeld klein (Mit Angabe der maximalen Zeichen)
Textfeld groß (Mit Angabe der maximalen Zeichen)
Pulldown einfach
Pulldown mehrfachauswahl
Datumsfeld
Textfeld mit überprüfung ob nur Zahlen eingegeben wurden (Und Punkte)
Linkfeld (Zum eintragen eines Bildlinks)
Checkboxen
Diese Felder sollen per ACP erst erstellt werden. Jedes erstellte Feld soll eine eigene ID und einen Namen bekommen. Die definition, was in diesem Feld darf, und was nicht, sollte in einer eigenen Tabelle stattfinden. Erst wenn ich die von mir benötigten einzelnen Felder zusammen habe, erstelle ich mir per Auswahl die Schablone daraus.
__________________
Bis auf weiteres nur eingeschränkter Support
|
|
|
24.01.2011 17:59 |
|
|
haumi
Boardbetreiber
[meine Galerie]
Dabei seit: 06.06.2009
Beiträge: 3.442
Herkunft: NRW
Postid: 7043
|
|
Wirtelefonieren mal.
So wie du es dir vorstellst, muss man aus einigen Angaben AUTOMATISCH vollständige php-scripte zur erstellung bearbeitung und löschung von Tabellen Datenfeldern und Datensätzen generieren.
Das ist meiner Meinung nach nicht machbar.
selbst google und wicki habe feste Datenbankstrukturen, ohne die geht es nicht.
wenn ich ein neues Tabellenfeld erstellen möchte, so wie es dir vorschwebt, dann ist die Frage muss ich eine neue Tabelle erstellen eine bestehende Tabelle erweitern, Verknüpfungen zwischen Tabellen ab oder aufbauen und vieles mehr.
Das würde bedeuten dass ich für JEDE beliebige IDEE 1000ende von vorgefertigten php-scripten bereithalten muss und dann die Entscheidung automatisch treffen lassen welches script gerade für meine Vorgabe geeignet ist, das ist meiner Meinung nach unmöglich.
Ich muss schon im Vorfeld eine Datenbankstruktur haben , die auch sehr viele Dinge ab kann.
Da kann ich benutzerdefiniert Ein- und Ausgabeformulare generieren, was aber auch nicht automatisch gehen wird.
Die Programmierer würden arbeitslos wen es sowas gäbe.
Ich melde mich morgen mal per 
bei dir.
LG
haumi
__________________
Gelassen das hinnehmen, was nicht zu ändern ist,
engagiert angehen was man gestalten kann.
|
|
|
24.01.2011 18:23 |
|
|
|
|
Also, innerhalb des wbb 2.3.6 gibt es den Bereich
Profilfeld erstellen
Profilfeld bearbeiten
Dort findet das gleiche statt. Man erstellt egene Felder. Diese ordnet man in der Reihenfolge an, wie man es möchte. Das ganze wird dann ja im Frontend ausgegeben beim Profile bearbeiten und dann im Profil. ($Profilefilds)
Genau das gleiche ist die Grundlage für die Schablone. Die selbsterstellten Felder mit der Zuordnung wie sie angeordnet werden sollen stellen ja eine Schablone dar.
Diese Funktion muß nachdem sie noch einmal neu aufgebaut wurde ja nur erweitert werden, mehrere Schablonen zu erstellen. Diese selbst erstellten Schablonen erhalten dann eine ID, die wiederrum einer Kategorie zugeordnet werden soll.
Also ist eigendlich nur die Funktion Profilfelder erstellen und bearbeiten zu isolieren, und eventuell um einige weitere Feldvarianten zu erweitern. Damit wäre die Grundlage geschaffen, um erst einmal eigene Schablonen zu generieren.
Was das löschen anbegeht hatte ich eh einen Denkfehler. Löscht man ein Feld, bleibt dieses später bei der Ausgabe ja nur leer. (Da der Variablen kein Wert zugeordnet werden kann). Somit dürfte man Felder später natürlich auch löschen.
Edit:
Ich habe eben noch mal nachgesehen. Die Profilfelder werden ja in der Tabelle bbx_profilefields gespeichert. Dort ist definiert, um was für ein Feld es sich handelt, wie lange (Zeichenmenge) das Feld ist usw.
Also genau der Aufbau, der mir vorschwebte
Wenn man also eine Tabelle bbx_wiki_felder benutzen würde, und eine Tabelle bbx_wiki_schablonen, dann könnte man durchaus genau das realisieren, einzelne Schablonen zu schaffen.
__________________
Bis auf weiteres nur eingeschränkter Support
|
|
|
24.01.2011 18:36 |
|
|
haumi
Boardbetreiber
[meine Galerie]
Dabei seit: 06.06.2009
Beiträge: 3.442
Herkunft: NRW
Postid: 7046
|
|
Da kommen wir der Sache schon näher.
Profilfelder haben eine eigene Tabelle
| code: |
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
|
CREATE TABLE IF NOT EXISTS `bb1_profilefields` (
`profilefieldid` int(11) unsigned NOT NULL auto_increment,
`title` varchar(100) NOT NULL default '',
`description` text NOT NULL,
`required` tinyint(1) NOT NULL default '0',
`showinthread` tinyint(1) NOT NULL default '0',
`hidden` tinyint(1) NOT NULL default '0',
`fieldtype` varchar(40) NOT NULL default 'text',
`fieldoptions` text NOT NULL,
`maxlength` smallint(5) unsigned NOT NULL default '250',
`fieldsize` tinyint(3) unsigned NOT NULL default '25',
`choicecount` tinyint(1) NOT NULL default '0',
`fieldorder` mediumint(7) unsigned NOT NULL default '0',
PRIMARY KEY (`profilefieldid`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=4 ;
|
|
Und auf Grund dieser Tabelle werden im ACP NUR neue Datensätze erstellt mehr nicht.
Das ist ja auch mein Reden das ich erst mal eine Tabellenstruktur haben muss um damit arbeiten zu können.
Es bleibt dabei wir
morgen mal
LG
haumi
__________________
Gelassen das hinnehmen, was nicht zu ändern ist,
engagiert angehen was man gestalten kann.
|
|
|
24.01.2011 18:53 |
|
|
|
