Zulässiger Name für Key des Array-Elementes

[Tom]

Hello,

wahrscheinlich habe ich es nur überlesen auf
http://de.php.net/manual/de/language.types.array.php

Ich kann nirgends eine definitive Aussage finden, ob der Stern als Name für einen Array-Key erlaubt ist, also in dieser Art:

$_data = array();

$_data['*'] = 'Stern';
$_data['zwei'] = 'Zwei';
$_data['drei'] = 'Drei';
$_data['eins'] = 'Eins';

Funktionieren tuts, aber ich wüsste es gerne definitiv.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Vinzenz Mai]

Hallo Tom,

wahrscheinlich habe ich es nur überlesen auf
http://de.php.net/manual/de/language.types.array.php

sieht so aus. Ich zitiere:

"Ein Schlüssel kann entweder ein integer oder ein string sein."

Ich kann nirgends eine definitive Aussage finden, ob der Stern als Name für einen Array-Key erlaubt ist, also in dieser Art:

$_data['*'] = 'Stern';

'*' ist ein String. Ein String ist als Schlüssel zugelassen. Reicht Dir das aus?

Freundliche Grüße

Vinzenz

[Tom]

Hello,

'*' ist ein String. Ein String ist als Schlüssel zugelassen. Reicht Dir das aus?

_Das_ habe ich auch gelesen. Und was ein String ist, ist mir im Prinzip auch klar :-)

Aber etwas Bauchkneifen habe ich eben doch dabei. Es würde aber Vieles vereinfachen, da hier in einem Arrays die Spaltennamen einer DB-Tabelle übergeben werden, und wenn ein Stern dabei ist, werden eben alle Felder angezeigt, mit Ausnahme der extra gekennzeichneten und des Primary Keys (der hat einen extra-Schalter).

$_extra['fields']['*']
                   [<name>]['off']
                           ['caption']
                           ['listlen']
                           ['editlen']
                   [<name>]...

als Auszug aus meinem Modul

Wenn Stern vorhanden, zeige alle außer denen mit 'off' == true
zeige auf jeden Fall die aufgeführten ohne 'off' oder mit 'off' == false
und verwende, falls angegeben die 'caption'
usw.

Es könnte nun noch vorkommen, dass jemand für seine Tabelle den Spaltennamen \* verwendet, sollte das überhaupt erlaubt sein. Dann hat er eben Pech gehabt. Aber ich versuche, die Benutzbarkeit des Modules so wenig wie möglich einzuschränken.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Richard]

Hallo,

Funktionieren tuts

Reicht das nicht?

Viele Grüße

[Tom]

Hello,

Funktionieren tuts

Reicht das nicht?

Nein. Nicht, wenn ein ganzes Konzept darauf aufsetzen soll.
Da muss die Eigenschaft schon dauerbeständig sein.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Rouven]

Hi,

gerade fällt mir ein: Die älteren Versionen von Media-Wiki nutzen das für ihr Rechtemanagement (die haben nur halt in der aktuellen Version ihr Konzept umgeändert).

MfG
Rouven

[Thoralf Knuth]

Hallo,

assoziative Arrays nutzen Strings als Keys, mehr Beschränkung besteht dort nicht. Intern sind die Einzelnen Elemente ja auch nummeriert erreichbar. Du kannst "*" problemlos als Index/Key benutzen. "*" ist ein gültiger String, jeder gültige String darf ein Index sein, ergo ist "*" ein gültiger Index. ;)

Gruß, Thoralf

[Tom]

Hello,

assoziative Arrays nutzen Strings als Keys, mehr Beschränkung besteht dort nicht. Intern sind die Einzelnen Elemente ja auch nummeriert erreichbar. Du kannst "*" problemlos als Index/Key benutzen. "*" ist ein gültiger String, jeder gültige String darf ein Index sein, ergo ist "*" ein gültiger Index. ;)

Das klingt richtig gut. Liegt vielleicht an Deiner beruflichen Ausbildung, dass Du so überzeugend rüberkommst ;-))

Ich werde es also wagen.

Irgendwie war ja die Vorgabe auch, dass die API-Funktionen, die ich erstelle, mnemonisch und/oder logisch verständlich sein sollen. Mein bisheriger Baukasten war dann doch nur 'was für Insider, so wie es leider auch viele PEAR-Klassen sind.

Eine Grundfunktionalität wird es also durch Aufruf von

db_table_lister($con, $tablename)

geben. Und alle erweiterten Fähigkeiten sind dann über

db_table_lister($con, $tablename, $_extra)

erreichbar. Das Array $_extra enthält dann die Informationen, die für die Zusatzfunktionalitäten wichtig sind, oder auch nicht. Um das Array zu konstruieren, gibt es Hilfsfunktionen, die sind aber dann wiederum für Insider entbehrlich. Ich habe moch hier bewußt für eine "OOP-zu-Fuß" Lösung entschieden. Mal sehen, was dabei herauskommen wird ...

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Thoralf Knuth]

Guten Abend,

assoziative Arrays nutzen Strings als Keys, mehr Beschränkung besteht dort nicht. Intern sind die Einzelnen Elemente ja auch nummeriert erreichbar. Du kannst "*" problemlos als Index/Key benutzen. "*" ist ein gültiger String, jeder gültige String darf ein Index sein, ergo ist "*" ein gültiger Index. ;)
Das klingt richtig gut. Liegt vielleicht an Deiner beruflichen Ausbildung, dass Du so überzeugend rüberkommst ;-))

Bestimmt. ;) "Aussichtslose Sache" klingt irgendwie deutlich weniger spannend als "Selbstverständlich setzen wir uns gern für Ihr Anliegen ein. Ich muss allerdings anmerken, dass nach Ihrer umfangreichen Vorarbeit ich fürchte, Sie liegen mit Ihrer Skepsis richtig." ;)
Im Ernst, ich versuche bei solchen Zweifeln zu normalisieren, also die Frage soweit wie möglich reduzieren.

Ich werde es also wagen.

Ich nutze solche Indizes genau wegen der Freiheit, mir keine Gedanken machen zu müssen. Zur Sicherheit lohnt sich bei sowas immer das altbekannte error_reporting( E_ALL );

Irgendwie war ja die Vorgabe auch, dass die API-Funktionen, die ich erstelle, mnemonisch und/oder logisch verständlich sein sollen. Mein bisheriger Baukasten war dann doch nur 'was für Insider, so wie es leider auch viele PEAR-Klassen sind.

DAS ist ein he(h?)res Ziel! Viel Erfolg! *bg*

erreichbar. Das Array $_extra enthält dann die Informationen, die für die Zusatzfunktionalitäten wichtig sind, oder auch nicht. Um das Array zu konstruieren, gibt es Hilfsfunktionen, die sind aber dann wiederum für Insider entbehrlich. Ich habe moch hier bewußt für eine "OOP-zu-Fuß" Lösung entschieden. Mal sehen, was dabei herauskommen wird ...

Pass auf, dass Du nicht die verwirrende Insider-Logik nur das Extra-Array verlagerst.

Gruß, Thoralf

[Tom]

Hello,

erreichbar. Das Array $_extra enthält dann die Informationen, die für die Zusatzfunktionalitäten wichtig sind, oder auch nicht. Um das Array zu konstruieren, gibt es Hilfsfunktionen, die sind aber dann wiederum für Insider entbehrlich. Ich habe moch hier bewußt für eine "OOP-zu-Fuß" Lösung entschieden. Mal sehen, was dabei herauskommen wird ...

Pass auf, dass Du nicht die verwirrende Insider-Logik nur in das Extra-Array verlagerst.

Solange man das noch alles leicht verständlich grafisch darstellen kann, habe ich keine Angst davor. PHP selbst ist ja eigentlich ein gutes Beispiel für "läuft erstmal"... Umkonfigurieren kann man dann immer noch.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Thoralf Knuth]

Hallo,

Umkonfigurieren kann man dann immer noch.

das ist aber eins der Dinge, die ich immer vor mir herschiebe, weil sie furchtbar undankbar, umständlich und auch fehleranfällig sind. ;)

Gruß, Thoralf

[Tom]

Hello,

Umkonfigurieren kann man dann immer noch.
das ist aber eins der Dinge, die ich immer vor mir herschiebe, weil sie furchtbar undankbar, umständlich und auch fehleranfällig sind. ;)

Wie würdest Du denn so ein Lister-Tool aufbauen, dass entfernt so ähnlich wie eine phpMyAdmin-Toolbox ist?

Es ermöglicht aber nicht die Änderung der Tabellen, sondern nur die angepasste Anzeige, inclusive "Relations", Spaltenausblendung, Spaltenreihenfolge, Spaltenbreite, Spaltenformatierung, Primary-Berücksichtigung, Funktionen wie "Download", Edit, Append, Vertikale Rechte, usw.

Ich habe sowas mal vor ca. 15 Jahren in Pascal auf DOS für bTrieve geschrieben, und als die Tools fast fertig waren, hatte sich Windows schon einigermaßen durchgesetzt, und ich hörte an jeder Ecke "das lohnt sich doch nicht mehr, die DOS-Tools (mit DPMI 16MB) fertigzustellen".

Heute weiß ich, dass es sich gelohnt hätte.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Thoralf Knuth]

N'Abend,

Wie würdest Du denn so ein Lister-Tool aufbauen, dass entfernt so ähnlich wie eine phpMyAdmin-Toolbox ist?

das kann ich Dir aus dem Stehgreif gar nicht beantworten, weil ich wahrscheinlich probieren und hin und her schieben würde. Ich hab nur die Erfahrung gemacht, Scripte, die "erstmal laufen", werden sehr spät aufgeräumt. Hat bei mir bei den kleinen privaten Projekten eh meistens zu einem kompletten Code Audit bzw. neu geschriebenem Code geführt.

Es ermöglicht aber nicht die Änderung der Tabellen, sondern nur die angepasste Anzeige, inclusive "Relations", Spaltenausblendung, Spaltenreihenfolge, Spaltenbreite, Spaltenformatierung, Primary-Berücksichtigung, Funktionen wie "Download", Edit, Append, Vertikale Rechte, usw.

Musst Du noch ein kleines bisschen warten, PHP5 soll irgendwann benannte Parameter (ich find den Link zu der Diskussion nicht mehr) einführen, dann reicht dafür eine Funktion bzw. Methode, die aber dann auch nur das Listing macht und das ganze DB-Handling im Hintergrund machen lässt.

Ich habe sowas mal vor ca. 15 Jahren in Pascal auf DOS für bTrieve geschrieben, und als die Tools fast fertig waren, hatte sich Windows schon einigermaßen durchgesetzt, und ich hörte an jeder Ecke "das lohnt sich doch nicht mehr, die DOS-Tools (mit DPMI 16MB) fertigzustellen".
Heute weiß ich, dass es sich gelohnt hätte.

O-Ton Arbeitsamt vor 15 Jahren zu mir in der Berufsberatung: Mache Sie nichts mit Computern, da finden Sie später nie einen Job. Sic!

Gruß, Thoralf