DOMParser und Progressive Enhancement

[Rolf B]

Hallo pl,

Nachdem ein ganzes <fieldset> oder <form> ausgetauscht wurde, muss der Cursor neu positioniert werden, schön ist das nicht.

Das stimmt, schön ist was anderes. Aber eine Rekonstruktion des Fokus lässt sich in ajaxForms.js integrieren, so dass man das Problem einmal löst und danach automatisiert behandelt. Voraussetzung dafür (in meiner unveröffentlichten Implementierung):

• das fokussierte Element hat ein id Attribut, dann kann ich mit getElementById repositionieren
• das fokussierte Element hat ein name Attribut. Dann ist noch zu ermitteln, das wievielte Vorkommen des Name das ist (radio-buttons!) und ich kann nach Rückkehr vom Server auf das i-te Vorkommen des Name repositionieren. Damit bleibt der Cursor im gleichen Feld stehen. Er springt lediglich an den Anfang des Feldes zurück. Mit window.getSelection und inputelement.setSelectionRange könnte man auch das rekonstruieren. Vermutlich muss man auch noch was bezüglich der Scrollposition des Fensters unternehmen; wenn ein großes Form ersetzt wird, könnte es im Browser zucken.

Unter diesem Gesichtspunkt ist es eleganter, viele kleine Updatepanels vorzusehen. Dann zuckt weniger. Nachteil ist, dass die Struktur des Forms dann nicht variieren darf (z.B. je nach Auswahl in Drop-Down 1 kommen Eingabefelder hinzu). Solche Bereiche müssen komplett in einem Updatepanel stehen.

Ohne id oder name könnte man noch weiteren Aufwand treiben, um einen Locator für das Element zu konstruieren, das ist aber eine riskante Sache weil die POST-Rückgabe die Formstruktur verändern kann. Darum habe ich das erstmal weggelassen. Id oder name sollten fokussierbare Form-Elemente in 99% der Fälle aufweisen.

Was bei einem grobschlächtigen Replace auch verloren gehen kann sind Tuningmaßnahmen am DOM, die von JavaScript gemacht wurden (z.B. eine ergänzte class). Die Frage ist nur, wieweit solche Änderungen nach einem Server-Durchlauf noch sinnvoll sind. Bei einer Ajaxifizierung einer Seite muss man clientseitig vermutlich Hirnschmalz investieren, wenn man per JS ins DOM eingreift. Der Ablauf bei einem vollen Postback ist anders als bei einem per Ajax gekapselten partiellen Postback. Vielleicht muss man den Ajaxifizierer zu einer EventSource ausbauen, damit sich Client-code auf das Ende des Postback registrieren kann (analog zum DOMContentLoaded Event). Diesen Aspekt hast Du bei deiner Lösung genauso vergessen wie ich :)

Was auch noch fehlt, ist eine Opt-In Möglichkeit für den Server, seine Arbeit bei einem partiellen Postback zu optimieren. ASP.NET macht das mit einem speziellen Header, der vom Postback des UpdatePanel gesetzt wird, und auf den das ASP.NET Framework mit einem optimierten Rendering der Response reagiert. Ist ja Quatsch, eine riesige Seite neu auszuliefern wenn man nur 500 Zeichen davon haben will; der Server kann dann auf das Rendering des Restes verzichten. Für den Einstieg kann man es seinlassen, für eine Optimierung kann man es einbauen.

Auto-Ajax hat eine Menge Potenzial, aber macht auch potenziell viel Arbeit

Rolf