Archiv des Intrexx Live! Forums

Hier sehen Sie die Foreneinträge aus dem Intrexx Live! Forum. Bis November 2016 war es das Forum für alle Fragen rund um die Software Intrexx von United Planet.
Seit November 2016 gibt es ein neues moderiertes Forum, das Intrexx Community Forum. Nutzen Sie bitte unbedingt dieses für aktuelle Fragen, Antworten und Informationen.

Wichtig: Dieses Forum dient als Archiv. Die Einträge beziehen sich oft auf ältere Versionen von Intrexx und entsprechen nicht mehr den aktuellen technischen Gegebenheiten.
Daher sollten alle Inhalte ausschließlich von Experten genutzt werden. Bei unsachgemäßer Anwendung kann es zu zeitaufwändigen Problemen oder Datenverlust kommen.
Übersicht > Intrexx Professional: Suggestions > Serverseitige Editseiten zur visuellen Modellierung von Prozessen

Serverseitige Editseiten zur visuellen Modellierung von Prozessen

Hallo UP,

Bei der Arbeit mit Intrexx wird ja viel mittels Seitensprüngen gearbeitet (nicht die in der Ehe), d.h. von einer Ansichtsseite auf eine Editseite und gleich per Autoklick weiter. An für sich eine gute Methode, auf visuellem Wege Prozesse zu gestalten. Bisher besteht eben der Nachteil, dass der Benutzer all diese Prozessschritte mitbekommt und möglicherweise sogar beeinflussen kann, ob nun aus Versehen oder aus böser Absicht.

Bestünde nicht die Möglichkeit, für eine Editseite zu definieren, dass sie nicht an den Benutzer zurückgeschickt wird, sondern gleich auf dem Server automatische Aktionen (per JavaScript) auf den Feldern durchgeführt werden und der Prozess sich so lange auf weiteren Server-Editseiten fortsetzt, bis eine kundenseitige Editseite oder eine Ansichtsseite erreicht wird?

Beispiel: automatische Erstellung eines neuen Kinddatensatzes, z.B. ein History-Eintrag.
[list=1]
  • die Editseite des Elterndatensatzes. Beim Speichern soll ein neuer History-Eintrag erzeugt werden. Dazu wird gesprungen auf...
  • eine Editseite auf der History-Unterdatengruppe mit ein paar Eingebefeldern und einem "Save"-Knopf, der automatisch per Javascript geklickt wird.
  • Weiter auf z.B. eine Ansichtsseite mit allen Elterndatensätzen.
    [/list]
    Der 2. Schritt könnte rein serverseitig erfolgen. Bei komplizierteren Datenstrukturen könnte auch eine Folge von mehreren Seiten rein auf dem Server bearbeitet werden.

    An für sich ist diese visuelle Methode der Prozessgestaltung ja gar nicht übel, es ist eben nur ein Krampf, wenn alle diese "Zwischeneditseiten" immer an den Benutzer geschickt werden, auf dessen Brauser dann JavaScript für automatische Aktionen sorgt und dann per autoklick wieder eine Anfrage an den Server gesendet werden muss. Wenn dieser Prozess gleich serverseitig ginge, dann wäre er auch viel schneller.

    Der Sicherheitsaspekt würde mit dieser Methode ebenfalls besser gewürdigt. Denn JavaScript, dass nur auf dem Server ausgeführt wird, kann nicht im Brauser manipuliert oder auch nur eingesehen werden. Der Entwickler muss sich also nicht ganz so viele Kopfschmerzen bereiten, und die Anwendungsentwicklung wäre viel "intrexxiger", weil man dadurch sicherlich auf so manchen Groovy-Prozess verzichten könnte.

    Was meint ihr?

    Grüßle,

    Raw
  • 11.01.2012 11:12 von Raw
    Hallo Raw,

    scheinbar werden für den Kind-Datensatz feste Standardwerte vergeben, oder Werte die sich aus dem Elterndatensatz ergeben. Dann würde doch ein Prozess sinn machen, der auf das Bearbeiten eines Datensatz reagiert und den Kind-Datensatz anlegt? Dann kann man sich den "Auto-Click" sparen und direkt von der Bearbeitung auf die eigentliche Zielseite springen (Der Prozess greift ja zwischen Bearbeitung und Weiterleitung des Benutzers. Es sind also schon alle Änderungen gemacht.)

    Wäre das evtl. schon eine Lösung?

    Grüße,
    CriBer
    11.01.2012 13:57 von CriBer
    Hallo CriBer,

    danke für die Antwort. Wär jetzt gar nicht nötig gewesen. Normalerweise mach ich das ja auch so wie du gesagt hast. Ich habe ja auch gar kein Problem. Dieser Post ist ein reiner Verbesserungsvorschlag für UP, um dem erklärten Ziel, mit so wenig Code wie möglich Webportale zu entwickeln, einen ordentlichen Schritt näher zu kommen.

    Viele Benutzer verwenden ja Eingabe- und Ansichtsfelder mit ein bisschen JavaScript, um Anwendungslogik abzubilden. Sobald aber Sicherheit eine Rolle spielt, ist dieser Weg ausgeschlossen, weil das eine gravierende Sicherheitslücke darstellt... wenn der Code auf Kundenseite ausgeführt wird und somit beliebig manipuliert werden kann. Daher meine Idee, Seiten, die der Benutzer gar nicht betrachten+bearbeiten muss, ihm gar nicht erst zu präsentieren, sondern auf dem Server abzuarbeiten.

    Übrigens: mein Beispiel lässt sich nicht unbedingt so einfach als Prozess abbilden:
    Wenn der Benutzer auf den Elterndatensatz Schreibrechte hat, dann kann er in der Tat eine Save-Aktion darauf durchführen mit einem Expert-Attribut, z.B. "rq_addHistory". Der Prozess kann dann einen neuen Kinddatensatz anlegen.
    Hat der Benutzer aber keine Schreibrechte auf den Eltern- sondern nur auf den Kinddatensatz hat, kann keine Datenbankaktion (Save oder Delete) ausgeführt werden, auf die der Prozess reagieren könnte. Ergo muss ein generelles Ereignis her. Dann geht nur noch Groovy, weil keine Datenbankaktionen im Prozess benutzt werden dürfen.

    Eine Lösung für dieses Problem habe ich auch schonmal in diesem Thread angesprochen.
    11.01.2012 14:28 von Raw
    Dann wäre wahrscheinlich eine Erweiterung der Prozesserstellung sehr hilfreich.

    z.B. eine Aktion "Kontextwechsel" in der man dann wie im DG-Ereignisbehandler eine Applikation und Datengruppe auswählen könnte, die wiederum über einen Filter einen Datensatz festlegen kann. Dann wären im Anschluss wieder alle gewohnten Aktionen nutzbar um einem das Leben leichter zu machen *BRAINSTORM* attention
    11.01.2012 14:54 von CriBer
    Zurück | Alles über Intrexx | Impressum | Datenschutzerklärung

    Über United Planet
    © 2019 United Planet GmbH
    Schnewlinstraße 2
    79098 Freiburg