svennickel
64588f71ac
Der STFV wertet jeden gewonnenen Satz mit 2 Spielpunkten und jedes
Satz-Unentschieden mit 1 Punkt je Seite. Das ist ein neuer Wert der
bestehenden Stellschraube spielpunkte_wertung_* (tinyint, Wert 4), keine
neue Spalte und keine Kombinatorik (#306-Konzept, Abschnitt 1). Nach aussen
bleibt der Modus punktetyp 1 + satzergebnisse 1 — die Punkte eines Spiels
SIND weiter die gewonnenen Saetze, punktetyp behaelt seine zwei Werte.
Die Regel sitzt in spielpunkteFuerSpiel(): 2·gewonnene + 1·unentschiedene
Saetze je Seite aus ergebnis_detailliert; ohne Detail (App-Meldung nur mit
Satzstand) deterministisch 2·punkte — Satzsiege sind bekannt, Remis nicht.
Beide PHP-Rechenwege bekommen dadurch denselben neuen Fall geschenkt.
Das Formular bietet die Option nur an, wo sie rechenbar ist: sichtbar
allein bei "Mehrere - mit Ergebnis je Satz" (data-satzdetails-Option,
zeilen_anzeigen() blendet sie sonst aus und stellt die Auswahl zurueck).
Der Server verlaesst sich darauf nicht: kommt Wertung 4 ohne punktetyp 1 +
satzergebnisse 1 an, faellt sie auf 0 zurueck (Sieg 2/Remis 1 je Spiel, die
naechstliegende Je-Spiel-Regel) — die Spielform dominiert, wie im
Bestandscode. Race schliesst 4 automatisch aus, weil Race Wertung 2
erzwingt. Gemessen an drei ueber das echte Formular geposteten Modi:
Einer+4 -> 0, Mehrere-ohne-Satzerfassung+4 -> 0, Race+4 -> 2. Und der
Warnhinweis beim Speichern mit Bestandsergebnissen nennt jetzt auch den
STFV-Altbestandsfall: wo unter "Mehrere" in Wahrheit Tore in den
Punkte-Feldern stehen, zaehlt nach dem Wechsel jedes Tor wie ein gewonnener
Satz doppelt — umgerechnet wird nichts.
Die DRITTE Rechenstelle rechnet mit — die Lehre aus dem Remis-Vorfall
(Formular 7:3, Server 6:2): das erzeugte Formular-JavaScript bekommt EINE
gemeinsame Satzsummen-Hilfsfunktion (satz_summen liest die
_punkte_detailliert-Felder und ueberspringt 0:0-Saetze wie die
Satz-Zaehlschleife des Servers), und BEIDE Verbraucher benutzen sie:
gesamtstand_aktualisieren() und spielpunkte_bedingung(). Aus den
spiel_N_*_punkte-Feldern duerfen beide im 4er-Modus nicht mehr rechnen —
dort stehen Saetze, eine Je-Spiel-Wertung waere falsch.
End-to-end gemessen an der neuen Prueflige G (Modus ueber das echte
Formular angelegt: 3 Spiele E/E/D, 4 feste Saetze, Wertung je Satz;
punkte_sieg wird -3 gespiegelt):
- Begegnung 117 mit Satz-Remis in allen drei Spielen ("6:4 4:4 2:6 6:3",
"1:6 2:6 6:6 0:6", "4:4 4:4 6:2 2:6"): gespeichert 5:3, 1:7, 4:4 —
Begegnung 10:14 Spielpunkte, 3:5 Saetze, 43:57 Tore. Handrechnung
identisch.
- JS-Paritaet nicht nur gelesen, sondern gerechnet: das vom PHP erzeugte
JavaScript aus der gerenderten Seite in node gegen dieselben Feldwerte
laufen lassen — gesamtstand_aktualisieren liefert 10:14,
spielpunkte_bedingung summiert 10/14, satz_summen je Spiel
[2,1,1] [0,1,3] [1,2,1]; die Datenbank derselben Begegnung sagt 10:14.
- Fallback gemessen (Begegnung 119, Meldung wie ein Altclient nur mit
Satzstand 2:1 und 1:1): Spielpunkte 4:2 und 2:2 (= 2·punkte),
ergebnis_detailliert bleibt leer, Tore bleiben NULL.
- Bestandsmodi unveraendert: dieselbe Messlatte wie bei den beiden
Schritten zuvor (10 Modi + 10 Begegnungen unveraendert gespeichert,
756 Zeilen Datenbank-Dump, 30995 Zeilen Frontend-HTML): VOLLSTAENDIG
identisch.
Neue Sprachschluessel DE/EN: die Option ("Sieg: 2 Punkte, Unentschieden:
1 Punkt - je Satz") und der erweiterte Warnhinweis.
SportsManager
DEV/STAGE environments
| LV | HOSTER | DOMAIN | BRANCH |
|---|---|---|---|
| DTFB | Kicktemp | stage.dtfb.de | dev |
| TFVHH | Kicktemp | stage.kickern-hamburg.de | dev |
| STFVH | DTFB | stage.stfv.de | sportsmanager2-stage |
| MTFV | DTFB | stage.mtfv.de | ? |
| TFVSH | DTFB | relaunch.tfvsh.de | ? |
PROD environments
| LV | HOSTER | DOMAIN | BRANCH |
|---|---|---|---|
| DTFB | Kicktemp | dtfb.de | production |
| TFVHH | Kicktemp | kickern-hamburg.de | production |
| MTFV | DTFB | mtfv.de | sportsmanager2-prod |
| TFVSH | DTFB | tfvsh.de | sportsmanager2-prod |
| STFVH | DTFB | stfv.de | sportsmanager2-prod |
Test setup
Installation
To start joomla and the database, run
docker-compose up -d
Release creation
To create a release execute
npm run release
Deployment
Deployment can only be done manually right now (sad)
To do this go to
Testserver Extension Installer Site
and upload the zip file found in ./package/packages
Development Tools
If you are using Intellij, there is a plugin named Joomla! which helps with resolving
joomla specific database prefixes like #__
To set it up, insert into the configuration popup which follows after you enable the framework support:
Joomla install path: ./data/joomla_data
JConfig: ./data/joomla_data/configuration.php
This works only with mounted volumes. However, mounted volumes will slow down the joomla instance significantly.
The current setup does not use mounted volumes. An alternative would be to download joomla and use that installation
Debugging (with Docker/Intellij)
-
Start Docker Container (see above)
-
Create a terminal for that container
docker exec -it <container_name> bash -
install xdebug within the container since joomla does not come with xdebug preinstalled
pecl install xdebug -
restart the container
-
In Intellij Go to File | Settings | Languages & Frameworks | PHP | Servers and setup your server
name anything host localhost port 8080 debugger xdebug use the path mapping and map the repo structure to the container content
File/Directory path on server <path>/com_sportsmanager/src/structure/administrator/components /var/www/html/administrator/components <path>/com_sportsmanager/src/structure/components /var/www/html/components -
Click on "Start Listening for PHP Debug Connections" in the top row of intellij
-
(Not sure if optional) Install a browser extension by Jetbrains
https://chromewebstore.google.com/detail/xdebug-helper-by-jetbrain/aoelhdemabeimdhedkidlnbkfhnhgnhm
How to release
Hint: for technical details regarding the release process have a look into .github/...
To create a release these steps need to be followed
- make sure all needed code changes are merged from dev -> stage -> prod, since releases may only be build on prod branch
- give pull requests meaningful names and label them enhancement/bug/chore since labels and names are used for release note generation Hint: if a specific pull request should be ignored, add the label changelog-ignore
- tag a commit (recommended is the latest merge on prod). The pipeline is listening for any tag fitting
v[0-9]+.[0-9]+.[0-9]+git tag -a v1.2.3 1a2b3c4 -m "Release version 1.2.3" - push the tag
git push origin --tags - the tag push will trigger the pipeline, and it will create the release and store in GitHub
A release can be created again anytime by deleting the release from GitHub, deleting the tag (from GitHub and additionally from git) and repeating step 3 and 4
Further: merges from dev to stage and from stage to prod can only be done by creating pull requests. These pull requests will be automatically labeled as changelog-ignore