daten übermittel per '&'

[JulianBaumueller]

Hallo,

ich hab mich schon immer gefragt wie man dass macht mit dem '&' nach dem ?location=blabla

Also sprich:
http://www.example.org/index.php?seite=start&id=1

Wie macht man sowas?
Also ich hab gehört, dass mit diesem & und dem darauf folgendem daten übermittelt werden.

Wie dass mit dem '?' am Anfang funzt dass weiß ich ja schon:

  
<?php  
  
$id = $_GET[seite];  
switch($id)  
{  
case start:  
include("start.htm");  
break;  
}  
  
?>  

Ich habe, wie ihr wahrscheinlih in meinem anderen thread schon mitbekommen habt vor, einen kleinen Online-Shop auf meiner Seite zu eröffnen.

Dar ich nicht für jedes einzelnes Produkt ein Extra 'case ..:' anfangen muss, will ich dass so machen:

http://www.baumueller-online.de/?location=webshop&article=headset

so ungefähr will ich dass dann angehen und da mir dazu nichts einfällt, wollte ich dass euch mal fragen.
Über Antworten wär ich sehr froh.

Mit freundliche Grüßen
JulianBaumueller.

[Dynamite]

ich hab mich schon immer gefragt wie man dass macht mit dem '&' nach dem ?location=blabla

hi,
was genau ist denn Dein Problem?
Das sind genauso GET-Daten wie die von Dir benutzten nach dem ?

Zur Zeit greifst Du ja auf $_GET['seite'] zu.

aus dem von Dir genannten Link (http://www.example.org/index.php?seite=start&id=1) bekommst Du also 'start' herraus. Wenn du nun $_GET['id'] "ansprichst" bekommst Du diese Daten.

Bitte erkläre Deine Frage nochmal, kann ihr zur Zeit nicht ganz folgen

Gruß
Dynamite

[Der Martin]

Hi,

ich hab mich schon immer gefragt wie man dass macht mit dem '&' nach dem ?location=blabla

ich verstehe nicht ganz, was du eigentlich willst, denn dein weiteres Posting zeigt mir, dass du bereits URL-Parameter benutzt.

http://www.example.org/index.php?seite=start&id=1
Wie macht man sowas?
Also ich hab gehört, dass mit diesem & und dem darauf folgendem daten übermittelt werden.
Wie dass mit dem '?' am Anfang funzt dass weiß ich ja schon:

Wenn wir schon bei PHP sind: Das Fragezeichen trennt den Query-String von der Basis-URL, also zum Beispiel dem Scriptnamen, und übergibt alles nach dem Fragezeichen an den PHP-Interpreter. Der trennt das an den '&' auf und stellt jedes name/value-Pärchen als Eintrag in $_GET[] oder $_POST[] zur Verfügung.

$id = $_GET[seite];

Das geht nur gut, wenn du eine Konstante namens seite definiert hast. Du meintest vermutlich $_GET['seite']. Und selbst das ist eigentlich sinnfrei - wozu Daten von einer Variablen in die andere umkopieren, wenn keine Verarbeitung oder Überprüfung erfolgt?

http://www.baumueller-online.de/?location=webshop&article=headset

Gut - dann hast du zwei URL-Parameter. Einen mit dem Namen 'location', und einen mit dem Namen 'article'. Was willst du nun eigentlich wissen?

Über Antworten wär ich sehr froh.

Und ich über konkrete, verständliche Fragen.

Ciao,
 Martin

[Kalle_B]

• wozu Daten von einer Variablen in die andere umkopieren, wenn keine Verarbeitung oder Überprüfung erfolgt?

Mache ich grundsätzlich am Programmanfang, um zu dokumentieren, welche Parameter dieses Programm erwartet.

Gut, meistens folgt dann eine Eingangsprüfung und das Setzen von fehlenden Parametern. Wenn etwa die Sprache nicht übermittelt wurde, wird "deutsch" gesetzt, bei Listen wird 25 Zeilen pro Seite angenommen usw.

Wenn ich das im PHP- Code verstreuen würde, würde schnell der Überblick über die Parameter verloren gehen.

Gruß,
Kalle

[dedlfix]

Hi!

• wozu Daten von einer Variablen in die andere umkopieren, wenn keine Verarbeitung oder Überprüfung erfolgt?
  Mache ich grundsätzlich am Programmanfang, um zu dokumentieren, welche Parameter dieses Programm erwartet.

Dazu gibt es Kommentare.

Gut, meistens folgt dann eine Eingangsprüfung und das Setzen von fehlenden Parametern. Wenn etwa die Sprache nicht übermittelt wurde, wird "deutsch" gesetzt, bei Listen wird 25 Zeilen pro Seite angenommen usw.
Wenn ich das im PHP- Code verstreuen würde, würde schnell der Überblick über die Parameter verloren gehen.

Dafür gibt es das EVA-Prinzip: Trennung des Codes nach Eingabe, Verarbeitung und Ausgabe.

Lo!

[Der Martin]

Hallo,

• wozu Daten von einer Variablen in die andere umkopieren, wenn keine Verarbeitung oder Überprüfung erfolgt?
  Mache ich grundsätzlich am Programmanfang, um zu dokumentieren, welche Parameter dieses Programm erwartet.

als reines Umkopieren halte ich es trotzdem für sinnlos. Wenn es Dokumentationszwecken dienen soll, würde ich diese Information eher in einen Kommentar oder in die Beschreibung setzen.

Gut, meistens folgt dann eine Eingangsprüfung und das Setzen von fehlenden Parametern. Wenn etwa die Sprache nicht übermittelt wurde, wird "deutsch" gesetzt, bei Listen wird 25 Zeilen pro Seite angenommen usw.

_DANN_ sieht die Sache ja schon ganz anders aus. Eine Eingabe-Validierung oder auch das Ergänzen fehlender Parameter mit Defaults ist ja unbedingt ratsam.

Wenn ich das im PHP- Code verstreuen würde, würde schnell der Überblick über die Parameter verloren gehen.

Auch darüber kann man wieder geteilter Meinung sein. Ich kann mir auch vorstellen, dass Daten grundsätzlich erst dort überprüft und bearbeitet werden, wo man sie braucht.

Ciao,
 Martin

[suit]

als reines Umkopieren halte ich es trotzdem für sinnlos. Wenn es Dokumentationszwecken dienen soll, würde ich diese Information eher in einen Kommentar oder in die Beschreibung setzen.

Ich mach das dennoch ab und zu, wenn es die Übersichtlichkeit erhöht :) da wird am anfang einfach mal alles was später an Konfiguration nötig ist üblichersichtlich von allen Stellen zusammenegsammelt und ein ein einheitliches Array geschrieben.

Ein kurzes: $this->conf['ddmmyy'] = $GLOBALS['TYPO3_CONF_VARS']['SYS']['ddmmyy']; macht eine Klasse ggf. übersichtlicher wenn man die Konfigurationsvariable des Datumsformats im Script anschließend 20 mal benötigt. Da muss nicht unbedingt immer ein solches Monster stehen.

[dedlfix]

Hi!

als reines Umkopieren halte ich es trotzdem für sinnlos. Wenn es Dokumentationszwecken dienen soll, würde ich diese Information eher in einen Kommentar oder in die Beschreibung setzen.
Ich mach das dennoch ab und zu, wenn es die Übersichtlichkeit erhöht :) da wird am anfang einfach mal alles was später an Konfiguration nötig ist üblichersichtlich von allen Stellen zusammenegsammelt und ein ein einheitliches Array geschrieben.

Wenn du dabei gleich eine Vorhandensein-Prüfung mit Vergabe eines Default-Wertes einbaust, ist dagegen nichts zu sagen.

Ein kurzes: $this->conf['ddmmyy'] = $GLOBALS['TYPO3_CONF_VARS']['SYS']['ddmmyy']; macht eine Klasse ggf. übersichtlicher wenn man die Konfigurationsvariable des Datumsformats im Script anschließend 20 mal benötigt. Da muss nicht unbedingt immer ein solches Monster stehen.

Das kommt drauf an. Solange man selbst durchsieht, mag das gehen. Aber wenn jemand fremdes den Code liest, der sich auch noch mit Typo3 auskennt, wird erst einmal dein Prinzip durchschauen müssen, wenn nun Werte aus anderen Quellen kommen und doch haargenau die gleichen sind. Du vereinfachst, indem du die Komplexität erhöhst.

Lo!

[suit]

Wenn du dabei gleich eine Vorhandensein-Prüfung mit Vergabe eines Default-Wertes einbaust, ist dagegen nichts zu sagen.

Ja, so ist das gedacht - am anfang findet eine Datensammlung statt - die Daten werden auf Gültigkeit und vorhandensein geprüft und entsprechend in die Konfiguration geschrieben - somit ist sämliches Zeug diesbezüglich an einer Stelle zu finden.

Das kommt drauf an. Solange man selbst durchsieht, mag das gehen. Aber wenn jemand fremdes den Code liest, der sich auch noch mit Typo3 auskennt,

Leider ist es so, dass extrem viele TYPO3-Extensions sehr schlecht programmiert sind (vorbei an TYPO3-Schnittstellen), die Maintainer sich nicht melden wenn man ihnen Patches vorschlägt (oder gar schickt!) und man ohnehin selbst Extensions schreibt - jeder der vernünftig mit TYPO3 arbeitet, nimmt nur sehr wenige Extensions aus dem Repository.

Kundenwünsche zu erfüllen ist mit vielen fertigen Extensions einfach nicht möglich.

wird erst einmal dein Prinzip durchschauen müssen, wenn nun Werte aus anderen Quellen kommen und doch haargenau die gleichen sind.

Das ist richtig - aber in anbetracht der oben genannten Tatsache ist diese Praxis schon mal weit besser als als der wirre Code mancher Extensions :)

[Steel]

Hi!

Leider ist es so, dass extrem viele TYPO3-Extensions sehr schlecht programmiert sind (vorbei an TYPO3-Schnittstellen), die Maintainer sich nicht melden wenn man ihnen Patches vorschlägt (oder gar schickt!) und man ohnehin selbst Extensions schreibt - jeder der vernünftig mit TYPO3 arbeitet, nimmt nur sehr wenige Extensions aus dem Repository.

Ist das nicht immer so? Ich arbeite fuer einen Freund gerade mit Xoops. Allein ein Template finden ist Horror, weil die fast alle auf Tabellen basieren. Also ein eigenes schreiben.

Kundenwünsche zu erfüllen ist mit vielen fertigen Extensions einfach nicht möglich.

Richtig. Die koennen zwar alles moegliche, aber nicht das was man will, wie man es will oder sind schlicht veraltet.

wird erst einmal dein Prinzip durchschauen müssen, wenn nun Werte aus anderen Quellen kommen und doch haargenau die gleichen sind.

Das ist richtig - aber in anbetracht der oben genannten Tatsache ist diese Praxis schon mal weit besser als als der wirre Code mancher Extensions :)

Korrekt.

[suit]

Ist das nicht immer so?

Nein :) Wenn man sich z.B. Wordpress-Templates ansieht, die sind großteils überaschend gut gemacht.

Und es gibt auch TYPO3-Extensions die wirklich gut geschrieben sind, auch TYPO3 selbst ist ordentlich und übersichtlich (wenn man vom gigantischen Umfang absieht) geschrieben.

Richtig. Die koennen zwar alles moegliche, aber nicht das was man will, wie man es will oder sind schlicht veraltet.

Das beschreibt die Sachlage sehr gut, ja :)

Und wenn man eben jemanden bittet, seine veraltete Extension auf obsolet mit dem Verweis auf eine mittlerweile integrierte Core-Funktion zu setzen, fühlen sich alle gleich in ihrem Stolz verletzt.

[Steel]

Ist das nicht immer so?

Nein :) Wenn man sich z.B. Wordpress-Templates ansieht, die sind großteils überaschend gut gemacht.

Es war ja auch nicht so gemeint, dass alle Repositories mies sind. Aber es gibt immer Material, das man eigentlich gebrauchen koennte, wenn es was taugen wuerde. Also muss man es weglassen, dran rumbasteln oder selbst neu erstellen.

Bei Typo3 hat man das Problem nicht, aber: Ich suche haeufig ein CMS mit ordentlichem Forum. Das ist eine Lebensaufgabe, wies scheint. Schlank, flexibel, Forum, leicht administrierbare Mulitdomainfaehigkeit und Mehrsprachigkeit. Damit losziehen und ein CMS suchen, finde ich anstrengend.

Und wenn man eben jemanden bittet, seine veraltete Extension auf obsolet mit dem Verweis auf eine mittlerweile integrierte Core-Funktion zu setzen, fühlen sich alle gleich in ihrem Stolz verletzt.

Interessant. Das habe ich noch nie gemacht. Meist schraube ich aber auch lieber ganz neu. Das kann dann oft weniger, aber eben das, was es soll.

[Sven Rautenberg]

Moin!

• wozu Daten von einer Variablen in die andere umkopieren, wenn keine Verarbeitung oder Überprüfung erfolgt?

Mache ich grundsätzlich am Programmanfang, um zu dokumentieren, welche Parameter dieses Programm erwartet.

Gut, meistens folgt dann eine Eingangsprüfung und das Setzen von fehlenden Parametern. Wenn etwa die Sprache nicht übermittelt wurde, wird "deutsch" gesetzt, bei Listen wird 25 Zeilen pro Seite angenommen usw.

Gegen vernünftige Parameter-Validierung und Default-Wert-Setzung ist ja nichts einzuwenden.

Sowas organisiert mans ich aber in der Regel dadurch, dass man sich für sowas Funktionen oder Klassen schreibt, bzw. sich entsprechend aus seinem Framework der Wahl einbindet.

Damit ist dann lokal direkt zu Beginn klar, was Sache ist, der Aspekt "Vollständigkeitsprüfung" und "Validierung" ist zentral und mit sehr wenig Codezeilen abgehandelt, danach kann man dann die Werte in einem anderen Array oder Objekt nutzen.

- Sven Rautenberg

[suit]

Das geht nur gut, wenn du eine Konstante namens seite definiert hast.

Weil keine Konstante namens Seite definiert ist ;)