Ankündigung

Einklappen
Keine Ankündigung bisher.

Rückfrage an den Nutzer wie "Daten löschen"

Einklappen
X

Rückfrage an den Nutzer wie "Daten löschen"

Einklappen
  • Filter
  • Zeit
Alles löschen
neue Beiträge

  • Rückfrage an den Nutzer wie "Daten löschen"

    Tach in die Runde!

    ist es möglich die Rückfrage von IX wie sie z.B. beim Löschen von Datensätzen erscheint zu nutzen?

    Ich habe gerade folgendes im Einsatz, was natürlich nicht wirklich schön aussieht!

    Code:
    Check = confirm("Soll der aktuelle Ansprechpartner \nwirlich zur Schlüsselperson X gemacht werden?");
    if(Check)
    return true;
    else
    return false;
    Sicher gibt es doch das was?

    Danke!!!

  • #2
    Dafür gibt es die Klasse "ix.confirm", die ihre Eigenschaften vom jQuery confirm erbt, und diese um einige Intrexx- eigenen Dinge erweitert.

    ABER: ix.confirm läuft asynchron und Du kannst damit nicht direkt mittels return true oder false die Button- Aktion abbrechen. Hier musst Du Dir mit einem kleinen Trick behelfen:

    1. Du nimmst Deinen Button, den Du hinter einer Abfrage "verstecken" willst und tust genau das: Du versteckst ihn (Du schiebst ihn in den versteckten Bereich). Notiere Dir die GUID des Buttons (Beispiel: "1234.....ABCD" )
    2. Du erstellst einen weiteren Button an der Stelle wo der andere Button war und stellst die Aktion auf "keine Aktion" und hinterlegst nur folgendes Script:

    Code:
    ix.confirm.show({
      'title': 'ACHTUNG',
      'message': 'Soll der aktuelle Ansprechpartner...',
      'buttons': {
        'Yes': {
          'css': 'margin:0 5px 0 5px;',
          'action': function () {
            var clickBtn = getElement('1234.....ABCD');
            clickBtn.click();
            }
          }
        },
        'No': {
          'css': 'margin:0 5px 0 5px;',
          'action': function(){ alert("Schade")}
        }
      },
      'escAction': function () {}
    });
    return false;
    Was bewirkt dieser code: Er zeigt den Confirm- Dialog, den Du mittels CSS noch weiter verfeinern kannst, und startet einen "deferred", der dann im Hintergrund auf den User wartet, der einen Button klickt. Der "Hauptthread" kommt sofort mit "return false" zurück.

    Klickt der user "Yes", dann wird die action- function aufgerufen: die holt sich den (versteckten) ECHTEN Aktionsbutton und klickt ihn "virtuell".

    Hoffe das hilft Dir weiter.

    Die Anzahl der Buttons sowie deren Beschriftung sind beliebig, es geht also auch "ja, nein, weiss nicht" oder "ja, nein, vielleicht", oder "ja, nein, abbrechen" etc.

    Im verlinkten Beispiel wird mit einem deferred gearbeitet und dieses returned. In meinen Tests vor einiger Zeit wartete aber der Button selbst nicht bis das Deferred aufgelöst wurde, sondern ging direkt weiter. Vielleicht wurde das ja inzwischen gefixt.

    Ab hier "Bonus- Content" :

    Wir haben das Ganze dann in einem unserer Workflows noch ein Stückchen weiter getrieben: Die "sichtbaren" Buttons (1-n) stehen jeweils für eine Workflow- Verzweigung (Button1: genehmigen, Button2: ablehnen, Button3: Stornieren, Button4: Delegieren ....).

    Die Business- Logic dafür haben wir im Prozess hinterlegt, und der "Haupt"- Button übergibt einfach einen Request- Parameter, um dem Workflow zu sagen, wo's langgeht. Diesen Request- Parameter muss man ja zur Design- Zeit festlegen... oder man setzt ihn dynamisch. Das sieht dann so aus:

    Code:
     var clickBtn = getElement('1234.....ABCD');
    clickBtn.oUp.oTarget.addParam = Helper.setQsValueByParam("rq_statusID",rqStatus, clickBtn.oUp.oTarget.addParam )
    clickBtn.click();
    Die Variable rqStatus kann der "geklickte" Button dem "Hauptbutton" dann als Parameter übergeben. Also egal wie komplex der Workflow im Hintergrund wird: Im Frontend haben wir immer nur einen Button, der das anspricht...

    Kommentar


    • #3
      Super Antwort!

      Genau dort wollte ich hin, wobei ich ein Groovy—Skript aufrufen will. Ein Workflow hatte den Charme das das System administrierbarer wird ... mhhh ...das macht bei mir eigentlich richtig Sinn!

      Ich muss mich mal mit dem dynamischen Erstellen von Button (Control) beschäftigen. Wir haben sowas ähnliches wie eine Checkliste die verschiedene Objekteigenschaften abfragt. Ein Button erzeugt beim Klick dann einen Datensatz. Kommt eine Frage hinzu müsste ich lt. meiner aktuellen Umsetzzungsplanung hart einen Button hinzufügen.
      Folglich sollte ich das gleich richtig machen! Wäre nun Velocity richtig oder welchen Weg nehmt Ihr dazu? Hast du eine Empfehlung zu einem Tutorial?

      Danke!

      Kommentar


      • #4
        Also wenn Du pro Frage einen eigenen Button brauchst, dann würde ich mal prinzipiell über das Konzept nachdenken... dynamisch Maskenelemente zu erzeugen ist eigentlich nur selten nötig....

        Kommentar


        • #5
          Hallo Tode!

          würde ich meine Ausführung lesen, wäre das sicher auch meine erste Frage/Antwort! Ich habe lange mich gegen den nun eingeschlagenen Weg gesträubt und sehen den noch immer sehr als kritisch an, aber es gab nicht wirklich eine alternative.

          Grundsätzlich gibt es hier im Haus die Mentalität "Ich will alles auf EINEN Knopfdruck sehen!" und dazu gehört auch, dass bei vielen Daten der Ersteller, Bearbeiter, das Erstellungsdatum, Änderungsdatum und evtl. eine Historie sichtbar sein muss (soll).

          Weiterhin sind viele Daten nicht einfach ein Feld wo ich einen Datenfeld nehmen und einen Wert eintrage. In nicht wenigen Fällen sind diese auch mehrfach vorhanden.

          Beispiel:
          Für den Vertrieb benötige ich eine Schlüsselperson für die Finanzen und eine für die technische Belange, aber das kann z.B. beim Finanzer schon mal sein das es zwei sind. Einer normal bis 10 T€ und einer zusätzlich bei höheren Beträgen. Unsere Schulung benötigt aber die HR-Leute und die Konstrukteure, die Dienstleistungsabteilung die Instandhalter und Konstrukteure. Das Thema weitete sich dann noch darauf aus, dass in einem Unternehmen mehrere Werke vorhanden sein können und für jedes Werk die jeweiligen Personen unterschiedlich sind. Getoppt wird dieser eine Teilbereich dann noch, das diese jeweiligen Ansprechpartner nicht aus diesem Unternehmen sein müssen. Hier gibt es nicht selten Externe (Konzern oder Dienstleister) welche unserer Schlüsselpersonen sind.

          Letztendlich ist das nur eine Ausschnitt, von dem was als Liste erfasst, dargestellt und ausgewertet werden soll.

          Die Frage von mir zur dynamischen Erzeugung von Steuerelement ist hier schon berechtigt.

          Vielen Dank aber für das Reflektieren meines Vorhabens, aber das Normalisieren ist hier wahrscheinlich nicht zielführend (hoffentlich).

          Welchen Weg würdest du nun empfehlen?

          Danke!

          PS: Nur mal so eine Feldliste von der Haupttabelle:

          LID, LUSERID, LUSERIDINSERT, DTINSERT, DTEDIT, L_ADRESSID, L_ADRESSE_WERT, L_ANSPRECHPARTNER_WERT, L_ANSPRECHPARTNERID, L_AUSWAHL_WERT, STR_BEMERKUNGEN, B_WERT, L_FILEINFORMATION, DT_WERT, FLT_WERT, L_WERT, L_MITARBEITER_WERT, STR_WERT, TXT_WERT, L_BELID, REF_535F9B3C, REF_011CD842, REF_EBD69E1C, REF_C3A6D96F, L_BOOLEANLIKEWERT, L_VORLAGENGRUPPENID

          Aller Felder mit _WERT sind die eigentlichen Datenfelder, welche entsprechend des Datensatztyps REF_.... in der Anwendung sichtbar geschalten werden. UUUnd vielen Dank für Deinen Hinweis zu REF_-Felder! Das Feld L_VORLAGENGRUPPENID habe ich entsprechend Deiner Ausführung zu einem ordentlichen Namen zwingen können!



          Kommentar


          • #6
            Aber nur, weil sich die Ansprechpartner / Verantwortlichen ändern, brauchst Du doch nicht für jeden dieser Verantwortlichen einen eigenen Button, oder muss da immer drauf stehen "Weiter an MaLo", "Weiter an Tode" oder ähnliches?

            Prinzipiell reichen ja wenige Buttons im Stil "Genehmigen - weiter an nächste Stelle" und einer mit "Ablehnen - Zurück zur letzten Stelle"... und welche Stelle das dann wirklich ist, das regelt man dann im Workflow im Backend oder von mir aus auch mit Code im Frontend... Aber eine Zwangsweise "dynamische Generierung von Steuerelementen" kann ich daraus jetzt nicht ablesen...

            Aber gut: Ohne tiefe Einblicke ist es natürlich immer einfach, Design- Entscheidungen in Frage zu stellen... Tatsächlich haben auch wir eine Applikation mit einer Maske (Veranstaltungsanmeldungen), deren Elemente sich dynamisch aufgrund er Konfiguration der Veranstaltung berechnen, so kann eine Veranstaltung (Weihnachtsmarkt) nur zwei Fragen haben: "Wie viele Personen:" und "Möchten Sie einen Weihnachtsbaum", eine andere kann x Fragen haben (wie viele Personen, wie viele Kinder, Essenswunsch: Vegan, Vegetarisch, laktosefrei... u.s.w).

            Insofern: Wenn Du nach reiflicher Überlegung zum Schluss gekommen bist, dass es nicht anders geht will ich nicht einfach was anderes behaupten...

            Kommentar

            Lädt...
            X