Franz Holzinger

Verse of the day

Denn es ist ein Gott und ein Mittler zwischen Gott und den Menschen, nämlich der Mensch Christus Jesus, der sich selbst gegeben hat für alle zur Erlösung, daß solches zu seiner Zeit gepredigt würde;
1 Timotheus 2:5-6

© Bible Gateway's Verse of the Day


autor  
3-08-08 13:30:43 zusätzliche Benutzerdaten und Preis2
Michael Schlierbach
Ich möchte den Bestellvorgang erweitern, bin mir über den besten Weg aber nicht sicher.

Folgendes soll eingerichtet werden:

Voraussetzung: Der ganze Shop/Bestellvorgang soll ohne Benutzerregistrierung arbeiten.
Ziel: Die Benutzer sollen bei der Eingabe ihrer Daten drei zusätzliche Felder ausfüllen:
1. Auswahlfeld "ehrenamtlich/hauptamtlich"
2. Textfeld "Funktion"
3. Textfeld "Einrichtung"
Wichtig: Abhängig vom Auswahlfeld soll entweder der normale Preis oder Preis 2 gelten.
Zwischenziel: Die Auswahl "ehrenamtlich/hauptamtlich" soll bereits in der Listenansicht der Produkte möglich sein (z.B. vor der Liste, etwa als radio-Button mit ähnlicher Funktion wie die Auswahl der Versandmethode oder der Zahlweise), damit schon dort die richtigen Preise angezeigt werden.

Ich habe hier schon gelesen, wie ich zusätzliche Felder im Basket unterbringen kann, bin mir aber nicht sicher, ob die sich dann überhaupt und durchgängig mit der Funktion für die Preisauswahl verbinden lassen.
Und: zumindest das erste Feld müsste auch außerhalb (und bereits vor) der Eingabe der restlichen Bestelldaten als Marker in den Templates einstellbar sein - und die entsprechende Wirkung auf den Preis haben.
Müsste ich diese Felder dann nicht auch extra in die Datenbank bringen?

Ich habe im Manual leider auch nicht genau herausgefunden, wo ich hier ansetzen muss.
Für Tipps bin ich sehr dankbar!
13-08-08 09:21:05 TypoScript
Franz Holzinger
Das lässt sich alles einfach über TypoScript lösen.

priceNoReseller = 2

Damit wird der Preis 2 festgelegt.

Es muss nur eine Zusatz-Extension geschrieben werden (oder in tt_products eingebaut), die eine Auswahlbox ehrenamtlich/hauptamtlich anzeigt und einen neuen Parameter an die URL anhängt, ähnlich wie der L-Parameter für die Sprache. Die Standardfunktion von TYPO3 zum Aufbau eines Links pi_getPageLink sollte dann den Parameter erhalten, wenn man die Seite wechselt.

Über TypoScript kann man festlegen, dass ein Parameter als Bedingung gesetzt sein muss.

[globalVar = GP:tx_ttproductsselect_pi1[hauptamtlich] > 0]
priceNoReseller = 2
[global]

Neue Textfelder für Frontendbenutzer müssen in die fe_users Tabelle eingetragen werden. Und über den Hook getBasketView können auch neue Marker für die zusätzlichen Texteingabefelder übersetzt werden.
13-08-08 21:29:27 Neue Felder und Preiswahlfunktion
Michael Schlierbach
Vielen Dank für die Hinweise.

Aber als Neuling in der Extensionsprogrammierung habe ich da noch ein paar Fragen:

Zunächst: Ich habe die erforderlichen Textfelder und Marker in tt_products eingebaut und sie funktionieren (also zusätzliche Angaben beim Besteller).
Ich habe sie allerdings nicht in fe_user eingebaut, denn diese Funktion nutze ich gar nicht (fe_user ist bisher ganz leer) und es soll auch keine Logins usw. geben. Die Felder sind dafür mit in sys_products_orders integriert. Auch das funktioniert gut.

Nun habe ich allerdings Probleme, die Preis-Abhängigkeit von der Auswahlbox (bei mir "dienst" mit den Werten "hauptamtlich" und "ehrenamtlich") vernünftig zu integrieren. Per condition und entsprechend kodierten input-radio-buttons ist mir gelungen, sie bei korrektem Ablauf vorwärts in den Bestellvorgang einzubauen. Aber sobald z.B. ein Feld fehlt und tt_products in das Bestellformular zurückverlinkt, sind die Einstellungen leider wieder weg - die condition greift nicht mehr.

Meine conditions:
[globalVar = GP:recs|personinfo|dienst = ehrenamtlich] OR [globalVar = GP:deliveryInfo|dienst = ehrenamtlich] OR [globalVar = GP:fieldsArray|dienst = ehrenamtlich]
plugin.tt_products.priceNoReseller = 2
[global]

für die Auswahlboxen ein Marker für "checked", um das zuvor eingestellte Feld auszuwählen:
[globalVar = GP:recs|personinfo|dienst = hauptamtlich] OR [globalVar = GP:deliveryInfo|dienst = hauptamtlich] OR [globalVar = GP:fieldsArray|dienst = hauptamtlich]
plugin.tt_products.marks.CHECK_HAUPTAMTLICH = checked="checked"
[else]
plugin.tt_products.marks.CHECK_HAUPTAMTLICH =
[global]

Im HTML-Template:
<p>Preise anzeigen für <input type="radio"
onClick="this.form.action='###FORM_URL###';this.form.submit();"
name="recs[personinfo][dienst]" value="hauptamtlich" ###CHECK_HAUPTAMTLICH###>
Hauptamtliche oder <input type="radio" onClick="this.form.action='###FORM_URL###';this.form.submit();" name="recs[personinfo][dienst]" value="ehrenamtlich" ###CHECK_EHRENAMTLICH###> Ehrenamtliche</p>


Die condition-Alternativen habe ich eingebaut, da ich vermute, dass die Felder in den verschiedenen Warenkorb-Seiten verschieden angesprochen werden (für die ersten beiden hat das funktioniert, die dritte war ein Versuch für die Korrektur bei fehlenden Pflichtfeldern).

Meine Fragen:
Mir ist kein Weg eingefallen, wie die Auswahl überall einheitlich abgefragt werden kann (wenn sie in die den Bestellerangaben integriert ist).
Wie kann die hautamtlich/ehrenamtlich-Auswahl vorwärts und Rückwärts im Bestellvorgang, inkl. aller Aktualisierungen erhalten werden? Sie müsste eigentlich ja ganz analog zu einem Produkt im Warenkorb behandelt werden.
Mir ist leider nicht klar, wie das Arbeiten mit URL-Parameter funktionieren soll. Auch da müsste ich ja die verschiedensten Aufrufe innerhalb des Bestellvorgangs abdecken. Aber wie geschieht das?
13-08-08 22:00:33 Daten erhalten
Franz Holzinger
Es gibt irgendeine Möglichkeit, über die man TYPO3 beibringen kann, dass ein anderer Paramter wie der L-Parameter für Sprache immer im Link erhalten bleibt.

Ansonsten kann man noch ###HIDDEN### Marker einführen, die in jeder Anzeige durch ein <input type="hidden" name="recs[personinfo][dienst]" value="x">
mit x als 0 oder 1, je nachdem, ersetzt werden.

13-08-08 23:18:16 variable Daten erhalten
Michael Schlierbach
Diese Lösung ist mir vom Prinzip her klar.
Das x ist allerdings gerade mein Problem: Es ist variabel, also von der letzten Benutzereingabe abhängig. Und auf die kann ich bisher nicht mehr erfolgreich zugreifen, wenn z.B. an bestimmten Stellen der Warenkorb aktualisiert wird (an anderen geht es) oder wenn wegen einer fehlenden Pflichtangabe aufs Eingabeformular zurückgesprungen wird.
Die Produkte im Warenkorb sind allerdings überall erreichbar, deshalb frage ich mich, ob ich die Variable da andocken kann (statt an recs[personinfo]). Ich will aber natürlich nicht einfach rumprobieren und z.B. die Warenkorbberechnung damit stören.
Mein Gedanke war, evtl. etwas wie basket[dienst] analog zu den Produkten selbst (basket[n]) einzuführen. Die Variable könnte dann abgefragt und in mein x eingesetzt werden. Aber sie müsste andererseits aus der Warenkorbliste und -berechnung herausgehalten werden.
Leider habe ich bisher nicht verstanden, wie die Produkte in basket[n] weiterbehandelt werden. Sind sie an jeder Stelle mit basket[n] abfragbar? Oder wechselt auch hier irgendwann der Name der Variablen?
Bzw. was muss ich tun, dass eine Variable durch alle tt_products-Seiten mit hindurchgeführt wird?
13-08-08 23:29:42 warenkorb
Franz Holzinger
Man könnte es ja auch im Warenkorb mitabspeichern.

$this->recs in tx_ttproducts_basket

Damit wäre das mit hidden gar nicht nötig, weil sich TYPO3 um den Erhalt der recs kümmert.
Einfach ein eigenes $this->recs['dienst'] verwenden.
14-08-08 09:21:05 Variable für Marker
Michael Schlierbach
vielen Dank!
Ein einziges kleines Mosaiksteinchen scheint mir noch zu fehlen:

Es ist alles soweit in Ordnung bis auf den letzten Bestellschritt.
Wenn ich von dort zurück (und nur von dort) in den Warenkorb springen muss,
geht die Preiseinstellung verloren (d.h. die condition greift nicht mehr).
Aber: Der von mir verwendete Marker ###PERSON_PREIS### funktioniert weiter korrekt!
D.h. ich bekomme im Warenkorb mit Marker angezeigt "Preisgruppe ehrenamtlich" (=price2, und wenn ich vorher hauptamtlich ausgewählt hatte, auch das korrekt) - die Preise sind aber immer "hauptamtlich"=price.

Wenn der Marker also stimmt, muss ich doch mit einer condition auch an die richtige Variable kommen.
Aber genau das scheint mir nicht zu gelingen. Die zuvor funktionierenden Variablen scheinen bei diesem Rücksprung gelöscht oder überschrieben zu werden, denn sie greifen offenbar nicht mehr in der condition. Ich habe schon fast alles an Variablennamen ausprobiert, was es da im Code gibt, aber noch keinen Treffer gelandet. Das Zauberwörtchen fehlt mir wohl.
An der Form der condition selbst kann es kaum liegen, denn wenn ich diese fest auf Preis2 stelle (z.B. mit dayofmonth), funktioniert es mit dem reduzierten Preis2.

Ich würde auch den marker selbst in der condition einsetzen, denn der liefert ja den gewünschten Wert - aber dazu fehlt mir nun die richtige Syntax, wenn das überhaupt geht?
Wie kann ich also entweder den Marker selbst in die condition einbringen - oder die richtige dahinter steckende Variable herausfinden?
14-08-08 11:40:24 Conditions
Franz Holzinger
Das Problem ist, dass
globalVar = GP:...
hier nicht greifen, wenn es keinen GET oder POST Parameter gegeben hat. Es greift nicht mehr auf in den recs gespeicherte Werte zurück.

[globalVar= var1=value, var2<value2, var3>value3, ...]

Vielleicht geht es hiermit:
[globalVar = TSFE:recs['dienst'] > 1]

Oder wenn nicht, dann sollte man TYPO3 entsprechend erweitern.
14-08-08 11:59:12 userFunc notwendig
Franz Holzinger
Nein, das ist doch falsch!
Es ist ja nicht unter TSFE->recs gespeichert, sondern wird über $recs = $TSFE->fe_user->getKey('ses','recs');
ermittelt.

Aber damit sollte es irgendwie möglich sein:

[userFunc = dienst_match(1)]
....
[global]


In die Datei localconf.php schreibt man:

function dienst_match($cmd) {
global $TSFE;

$recs = $TSFE->fe_user->getKey('ses','recs');

return ($recs['dienst'] == $cmd);
}

14-08-08 12:33:00 Problem gelöst - Vielen herzlichen Dank!
Michael Schlierbach
Super, wunderbar!
Das ist die Lösung: Es funktioniert jetzt mit dieser userFunc reibungslos.
Danke für alle Hilfe und das Mitdenken!
< Zurück zum Forum