"Classic" Webentwicklung: Close und Save feuern beide das onSubmit Event...

[Tode]

Ich habe hier eine Datenbank, bei der es zu viel Aufwand wäre, die ganze App in XPages neu zu machen, trotzdem haben wir Änderungswünsche...

Einer war eine "modernere" Feld- Validierung... Das haben wir über das onSubmit- Event gelöst... Dummerweise wird dieses Event gefeuert bei:

- Action buttons mit @Command([FileSave]) -> Ja, genau da soll es hin
- Action buttons mit @Command([FileCloseWindow]) -> Was soll das denn?
- Jeder Feld- änderung, die ein Reload der Maske auslöst (weil die Feld- Eigenschaft entsprechend gesetzt ist) -> technisch Verständlich, aber trotzdem unlogisch...

Gibt es ne Möglichkeit

a) zu verhindern, dass das onSubmit fälschlicherweise aufgerufen wird
oder
b) im onSubmit rauszufinden, welches Event den Submit ausgelöst hat


Alle sind ja auf dem XPage- Zug, aber wie geschrieben ist das hier keine Alternative, und ich muss mich hier mit dem "alten Kram" rumschlagen...

[Glombi]

Was mir so spontan einfällt:

im onSubmit rauszufinden, welches Event den Submit ausgelöst hat

Das ginge, wenn Du ein Feld in der Action mit FileSave schreibst, das dann im OnSubmit ausgewertet wird. Das müsste dann wieder resettet werden.

Andreas

[Tode]

Nope... ich habe es probiert mit
FIELD xxx := "1"
und mit
@SetField( "xxx" ; "1" )

und beides sowohl mit Vorhandenem Feld in der Maske, nicht vorhandenem Feld, berechnet, bearbeitbar, versteckt und sichtbar...

Egal was ich tue: Im onSubmit ist der Wert, den ich im Button setze noch nicht vorhanden.
Und das obwohl er bei erfolgreichem submit nachher definitiv im Dokument steht...

Ich habe versucht den Wert abzufragen über die Form:
document.forms[0].xxx.value

und auch über document.getElementsByName und document.getElementById (was natürlich schief geht, wenn das Feld nicht wirklich im Design vorhanden ist)


Wenns so einfach wäre, hätte ich ja nicht gefragt ;-)

[Glombi]

Du hast HTML für alle Felder generieren aktiv, gell? Nur mal so vorsichtig gefragt...

[umi]

Moin
Evtl. den Actions button umschreiben?
Anstatt ein @Command([FileCloseWindow]) ein @Urlopen() ? Dann würde auch kein Submit ausgelöst..

[Tode]

*g* genau die Fragen, die ich auch stellen würde... Sorry: Ich hätte all diese Dinge natürlich gleich im ersten Post erwähnen sollen.
Auch die Datenbank- Option "Use javaScript when generating Pages" ist natürlich eingeschaltet...

@Umi: Den @Command( FileClose ) habe ich schon genau so umgeschrieben... Da kommt natürlich wieder die Herausforderung dazu, genau dahin zurückzugehen, wo man herkommt (HTTP_REFERER und PATH_NAME ändern sich ja bei jedem Reload der Maske, genau wie berechnet zur Anzeige- Felder, weshalb ich mir hier mit einem Cookie behelfen musste... Aber das ist eben nur die halbe Miete: Jedes Reload der maske schlägt ja auch fehl, weil die Feldvalidierung False zurückliefert... und das ist dumm, wenn man beim ausfüllen noch gar nicht so weit gekommen ist, die Pflichtfelder auszufüllen...

[pram]

Du musst dir Buttons machen, die die gewünschten @Aktion auslösen und jeweils dazu einen weiteren, der den dann per Javascript anklickt.

Ersterenmusst du per Style unsichtbar machen (aber nicht den Haken setzen, dass er im Web verborgen ist)
Mit den anderen setzt du eine entsprechende Javascript-Variable

Grob skizziert schaut das im Designer dann so aus

<script type = "text/javascript">
var action = ""
</script>

<div style="display:none">

*Hier dein @FileCommandSave, id="save_button" *

*Hier dein @FileCloseWindow, id="close_button" *

</div>

Dann machst du 2 weitere Buttos, stellst diese auf Web-javascript um und schreibst folgenden Code rein:

1. Button:
action = "save"
document.forms[0].["save_button"].click() // bin mir jetzt nicht 100%ig sicher, ob dies click oder onclick heisst

2. Button:
action = "close"
document.forms[0].["close_button"].click()


Im onSubmit kannst du nun fest stellen, welchen Button du geklickt hast, in dem du "action" ausliest.

Gruß
Roland

[Tode]

Danke Roland, genau diesen Lösungsansatz hatte ich auch noch irgendwo im Kopf, kam mir aber so "umständlich" vor...

Also es gab wohl doch den ein oder anderen Grund, das ganze Web- Gedöns mit Hilfe der XPages mal von Grund auf neu zu machen...