0

Auf Felder mittels dynamisch erstellter Namen Zugreifen

Hallo Zusammen, ich habe hier folgenden Anwendungsfall:

Es soll eine Zeiterfassung erstellt werden. Aufgrund Übersicht, Ansicht, und sonstigem war die Lösung, eine Datenbank "Zeiterfassung" zu machen. Diese hat ein Feld für Jahr und Monat, ist mit einem Teilnehmer verknüpft,  und hat für die Tage Felder mit der Bezeichnung "1" bis "31".

In der Ansicht ist das beeindruckend; man kann sogar in der Tabellenansicht per Doppelklick direkt Daten eintragen. Abrechnung ist hiermit aber ein graus. Außerdem soll auch rudimentär eine Übersicht gemacht werden, wieviele Stunden pro KW das sind, da nicht mehr als 30 eingetragen sein dürfen.

Ich habe versucht, wie folgt auf die Felder zuzugreifen: 

for i in range(1, 32) do
    let myValue := eval("this." + i, this);
end

Das Problem: hiermit landet in myValue der Wert von i! Ich dachte, eval wäre dazu da, damit das gerade _nicht_ passiert. Oder habe ich hier einen Denkfehler?

5 Antworten

null
    • AWO Mönchengladbach
    • Sebastian_Urbanneck
    • vor 2 Jahren
    • Gemeldet - anzeigen

    Ich habe mal einen generischen Code genommen, ausgeführt aus einer anderen Tabelle mit Funktionen.

     

    let myString := "";
for monate in select Zeiterfassung where Jahr = this.Jahr do
    for day in range(1, 32) do
        let stringDay := string(day);
        myString := myString + " " + monate.eval(stringDay, this)
    end
end;
alert(myString)

    hier ist das gleiche Problem: eval löst StringDay auf; aber anstatt z.B. das Feld monate.1 oder monate.2 ausgelesen wird, kommt als Ergebnis 1 bzw. 2.

    Das Problem liegt bei meiner Benutzung von Eval. Wie kann man das sonst lösen?

      • rainless
      • vor 2 Jahren
      • Gemeldet - anzeigen

      Sebastian Urbanneck 

      Hallo Sebastian,

      grundsätzliche Frage: Wäre es nicht einfacher, die Tage als eigene Tabelle anzulegen? Dann könnte man auch noch mehr Info drin speichern (Datum, Arbeitstag/Feiertag, Stunden, ...). Dann kann man deutlich leichter über die entsprechenden Tag iterieren. Es gibt Summen-, Durchschnitts-, Filtermöglicheiten und vieles mehr, was mit 31 Feldern gar nicht so elegant geht. Außerdem kann für jeden Monat auch eine Obergrenze an Einträgen definiert werden (in Abhängigkeit von der echten Anzahl Tage pro Monat).

      Hast Du das schon mal bedacht?

      • Ninox-Professional
      • planoxpro
      • vor 2 Jahren
      • Gemeldet - anzeigen

      Sebastian Urbanneck 

      Man sollte Datenfelder und Variablen keine Namen vergeben, die nur aus Ziffern bestehen. Und wenn, dann muss man sie beim Referenzieren in einfache Anführungszeichen setzen. Ein Konstrukt wie folgendes könnte dann funktionieren (Beispiel für ein Funktionsfeld): 

      let myText := "";
for myDay from 1 to 32 do
   myText := myText + eval("'" + text(myDay) + "'", this)
end;
myText

      Ich schließe mich aber Lars an und würde ebenfalls dringend empfehlen, jeden Tag in einem eigenen Datensatz zu erfassen. Das wäre mit Sicherheit deutlich effizienter, flexibler und, obwohl es mehr Datensätze würden, wahrscheinlich auch performanter. 

      • AWO Mönchengladbach
      • Sebastian_Urbanneck
      • vor 2 Jahren
      • Gemeldet - anzeigen

      Hallo zusammen,

       

      ja, das wurde natürlich angedacht. Und verworfen. Das sind zwei Leute, welche für 80 Teilnehmer Wochenzeit-Zettel ins System übertragen müssen. Da kam es eher darauf an, dass das so einfach wie möglich ist. Tage als Felder zu nehmen war das einzige, was da Sinn machte. 
       

      das mit den einzelnen Anführungszeichen habe ich meine ich schon probiert, werde das aber auch noch mal so machen wie hier.

       

      und notfalls werde ich jedes Feld einzeln in einer Summe ansprechen. Wie gesagt: es ging um „einfach für Anwender“, nicht „eleganter Code“.

    • rainless
    • vor 2 Jahren
    • Gemeldet - anzeigen

    Die Tabellenstruktur sollte sich erst mal nicht der UI unterwerfen sondern der besten Strukturierung der Daten. Und die schönste UI bringt nichts, wenn deswegen eine Datenstruktur nicht mehr verwaltbar ist. Die Trennung von Daten und Code ist nicht elegant (blödes Wort von mir), sondern effizient und sinnvoll.

    Bei Verwendung einer separaten Tabelle lässt sich die Eingabe auch sehr schön darstellen. Eine Vor-Erzeugung der notwendigen Eintragsfelder ist auch bei einer Tabelle möglich (sogar viel besser mit der richtigen Anzahl von Tagen), so dass die Bearbeiter auch schon eine komplette Maske vorfinden. Ich denke da könnte es hier auch Tipps geben, wenn das nicht rund läuft.

Anmelden, um zu antworten

Content aside

Kategorien

Alle Themen anzeigen
  • vor 2 JahrenZuletzt aktiv
  • 5Antworten
  • 71Ansichten
  • 3 Folge bereits