wie gesagt, mehr als code-fetzen kann ich selten liefern bei deinem code :/ der is aus meiner sicht halt durcheinander und für mich schwer zu lesen. auch das konzept mit den vielen seiten. eine seite zum eingeben, eine zum ausgeben, eine zum speichern, eine zum editieren... da fehlt mir schon das grundverständnis, wie das funktionieren soll.
eingabeseite
-> speichernseite
-> wie komm ich wieder zurück? bzw zur ausgabeseite...
für mein verständnis is das halt alles eins und gehört nicht getrennt (gesplittet (auch wenns übersetzt das selbe bedeuted ^^) gern, also dass man einzelne teillösungen in andere dateien auslagert - aber dennoch alle zusammengefügt in einer seite). ich kanns ja mal versuchen zu erklären:
hab jetzt 3 js-funktionen: addline, delline und switchselect. letztere kümmert sich um die anzeige der richtigigen produkt select. wie gesagt, grundidee mit den selects war, dass ich für jede tätigkeit ein komplettes select baue und in ein (mit id versehenes) div packe, welches ich mittels display:none verstecken oder mit ...block anzeigen kann. besagte id lautet "produkt"+tätigkeits-id. also haben wir die tätigkeit gießen mit der id2 (um bei meinem dürftigen bsp db-eintrag zu bleiben ^^), dann werden alle produkte, die man gießen kann in ein div mit der id "produkt2" gepackt. gut, die tätigkeits-selectoptionen bekommen als value genau diese id (die muss später ja auch in die db gespeichert werden, 2 fliegen mit einer klappe szs). als javascript event bekommt das select nun onchange und dabei wird switch_select() aufgerufen. diese funke schaut sich nun bei dem tätigkeiten select an (hat auch ne id bekommen, damit ichs easy find ^^), welche option ausgewählt wurde (selectedIndex...) und kann hierraus die tätigkeiten id ermitteln. joa, und mit dieser fällt die entscheidung leicht, welches div ich nun anzeigen muss und welche versteckt werden müssen. ist im ende eine forschleife durch alle optionen des tätigkeits selects und wenn eben der aktuelle index i dem selectedindex entspricht, wirds angezeigt, sonst nicht.
gut, damit funzte das also schonmal für eine zeile. achja: ich hatte mich entschieden, eine "default input zeile" anzubieten. eben bei jener funzt das auch. ich hatte da aber noch nen denkfehler drin: der einfachheithalber wollte ich dieses default-tätigkeits-select immer hernehmen, um diese forschleife durch die tätigkeiten zu bauen anstatt des wirklich genutzten (die zeigen ja alle die selben options). aber dann funzt es nicht, wenn ich zeilen geadded hatte. is ja klar - wenn ich das 3. select änder und beim default den selectedindex abfrag... ^^ also mussten die alle ne id bekommen und durchgezählt werden... das war ne schau :/ hatte ja schon die zählvariable im hiddenfeld rausgeschmissen >< hab ich also nen anderen versuch gewagt. dazu eine kleine zwischengeschichte: meine buttons (die bisher ausserhalb der tabelle darunter waren) hatte ich nun als finale zeile mit in die tabelle gepackt. so, nun drückte ich delete-zeile und schwupps war sie weg xD schlau gelöst! ^^ also gab ich dem ding auch ne id und verhinderte, dass dieses tr mit der id gelöscht werden kann. die default-zeile bekam soeine id ja auch schon - szs als stopper. gut, nun hatten also die "umschließenden" tr's jeweils ne id - also hab ichs ganz simpel gelöst: geh alle tr's der tabelle durch und merke dir, die wievielte die default-zeile ist und die wievielte die letzte zeile ist - die differenz entspricht der anzahl meiner geaddeten zeilen. war auch nich ganz richtig *seuftz* scheinbar zählt er wirklich ALLE tr-tags innerhalb der tabelle - auch wenn die garnich zur tabelle selbst gehören, sondern zu einer tabelle in der tabelle. wir erinnern uns: meine buttons hatte ich analog zur ersten zeile mit der kalanderwoche auch wieder in eine innere tabelle gepackt, die eine zeile besaß. also wird die zang! mitgezählt ><
aber gut, ich hatte es hinbekommen die anzahl mit rauszubekommen und konnte demnach beim adden die id's anpassen. hatte am ende einfach die anzahl (var count) mit nem _ getrennt hinten an die id's angehängt. schon konnte ich das entsprechende tätigkeits-select zum rausfinden des selectedindex ansteuern (taetSel_2 zum bsp) und damit die richtigen divs steuern (produkt 1_2...). dazu muss man der onchange funke natürlich noch den richtigen index mit übergeben, wird also aus switch_select() ein switch_select(count).
joa. beim adden einer zeile hatte ich das ganze dann ja mal ausgebaut von meinem ein-zellen-zeilchen auf ne ordentliche und da eben das gefummel mit den selects gehabt. zuerst hatte ichs so gemacht, dass ich ans innerhtml der table einfach ne als string geschriebene tabellenzeile angehängt hatte, aber damit hatte er schon gemacht eingaben wieder resettet. also musste ich wirklich was anhängen, und das war zumindest spannend rauszufinden, wie das so klappt ^^ document.createElement(tag-name); da kann man inputs und selects und options bauen. so hab ich bspw die tätigkeiten umgesetzt (das array hatte ich mir vorher zurechtgebaut, mit der mysql abfrage...):
PHP:
// ...
echo ' cell = row.insertCell(0);';
echo ' select = document.createElement("select");';
echo ' select.name = "taetigkeit[]";';
echo ' select.id = "taetSel_" + count;';
echo ' select.onchange = function(){switch_select(count);};';
foreach($selTaetigkeit['data'] as $id => $text) {
echo ' option = document.createElement("option");';
echo ' option.value = "'.$id.'";';
echo ' option.innerHTML = "'.$text.'";';
echo ' select.appendChild(option);';
}
echo ' cell.appendChild(select);';
// ...
da kann mans schon erahnen. die produkt selects sind nochma ne ecke schärfer (divs noch drum herum und auch nich nur eines - also halt 2 schleifen statt nur einer, die eigentliche anzahl is ja bumms) und da kommt einiges an code zusammen ><
ich kanns bei bedarf mal zur verfügung stellen. fehlt halt die speicherei momentan und um den login hab ich mich bisher auch ned gekommert (standard-werte für user und login ^^ 1 und true
). machen kann man noch viel. ne eingabemaske um produkte und tätigkeiten zu verwalten bspw - das wäre dann wirklich mal ne zweite seite wert
das wäre nämlich ein neuer in sich abgeschlossener themenkomplex.
. Der Kann ja nicht kompliziert sein 
Sollte das mal produktiv gehen, würde ich das doch vorher 
Selbst wenn das nur ein Lernprojekt ist, solltest du den sicheren Umgang mit parametrisierten Datenbankqueries lernen. Auch XSS bzw. XSRF könnte ein Problem sein, dafür habe ich jetzt aber nicht tief genug gewühlt 
