Weiß nicht, ob ich jetzt hier richtig bin, aber wie setze ich ich zeitgemäß lange Formulare um?

Beim aktuellen Projekt, dass ich gerade mache, ist ein wirklich langes Registrierungsformular. Ich habe das jetzt erstmal in Bereiche (div) unterteilt mit Überschriften, die bei Klick auf Ihren Namen das entsprechende div einblenden und den Rest aus. Funzt ganz gut, aber wenn der User kein JavaScript aktiviert hat, geht es natürlich nicht mehr.

Gibt es noch einen anderen Ansatz, außer das Formular über mehrere Seiten zu verteilen und mit PHP die Parameter immer weiterzugeben?!? Danke.

mfg streuner

Hallo,

generell solltest du bei diesen JavaScript-Geschichten darauf achten, dass erstmal das gesamte Formular angezeigt wird, auch wenn es sehr lang ist. Mit einem onload-Handler kannst du dann die entsprechenden Teile ausblenden. Wenn das passiert, ist JS auch verfügbar und sichergestellt, dass der Benutzer sie auch wieder einblenden kann.

Für Gruppierungen empfiehlt sich das fieldset-Element.

Wenn du mit Sessions arbeitest, brauchst du zwar die bereits eingegebenen Daten nicht mehr als hidden-Felder über mehrere Seiten schleppen, aber auf mehrere Seiten verteilt ist das Formular an sich trotzdem.

Ich finde es in Ordnung, wenn Formulare auf mehrere Seiten verteilt sind, da fühlt man sich nicht gleich so erschlagen. Nach der 4. Seite sollte dann aber spätestens Schluss sein, sonst ist man genervt, dass es nie ein Ende zu nehmen scheint.

Das sind so meine Erfahrungen.

Gruß,

Amica

Hallo,

generell solltest du bei diesen JavaScript-Geschichten darauf achten, dass erstmal das gesamte Formular angezeigt wird, auch wenn es sehr lang ist. Mit einem onload-Handler kannst du dann die entsprechenden Teile ausblenden. Wenn das passiert, ist JS auch verfügbar und sichergestellt, dass der Benutzer sie auch wieder einblenden kann.

Ok, das ist sinnvoll.

Für Gruppierungen empfiehlt sich das fieldset-Element.

Hab ich.

Wenn du mit Sessions arbeitest, brauchst du zwar die bereits eingegebenen Daten nicht mehr als hidden-Felder über mehrere Seiten schleppen, aber auf mehrere Seiten verteilt ist das Formular an sich trotzdem.

Arbeite mit Sessions, war mir aber nicht sicher, ob es da nicht noch was "eleganteres" gibt!

Ich finde es in Ordnung, wenn Formulare auf mehrere Seiten verteilt sind, da fühlt man sich nicht gleich so erschlagen. Nach der 4. Seite sollte dann aber spätestens Schluss sein, sonst ist man genervt, dass es nie ein Ende zu nehmen scheint.

Tja, leider hat ich auf den Formularinhalt keinen Einfluss:(. Mal sehen, wie viele Seiten es werden.

Das sind so meine Erfahrungen.

Danke Dir.

mfg streuner

Arbeite mit Sessions, war mir aber nicht sicher, ob es da nicht noch was "eleganteres" gibt!

Ok, weil das hier nicht so nach Sessions klang:
das Formular über mehrere Seiten zu verteilen und mit PHP die Parameter immer weiterzugeben

Naja, eleganter geht immer. Mit AJAX gibt es da auch noch ein paar Möglichkeiten. Die sind aber wieder nur für aktiviertes JS zugänglich, weswegen du sowieso erstmal ne solide Fallback-Basis brauchst.

Tja, leider hat ich auf den Formularinhalt keinen Einfluss:(. Mal sehen, wie viele Seiten es werden.

Wieso nicht? Kannst du es nicht trotzdem einfach in 4 Seiten einteilen?

Ok, weil das hier nicht so nach Sessions klang:

Doch, ist ja mit den üblichen Verdächtigen, wie Login, Registrierung usw.! Da taucht 2x ein wirklich langes Formular auf.


Naja, eleganter geht immer. Mit AJAX gibt es da auch noch ein paar Möglichkeiten. Die sind aber wieder nur für aktiviertes JS zugänglich, weswegen du sowieso erstmal ne solide Fallback-Basis brauchst.

Jep, zuverlässiges funktionieren ist erstmal wichtig.


Wieso nicht? Kannst du es nicht trotzdem einfach in 4 Seiten einteilen?

Ja, werde ich schon aus dem von Dir genannten Grund alleine machen. Kann aber gut sein, dass man dennoch scrollen muss. Mal sehen.

mfg streuner

Ich weiß ja jetzt nicht, was für Daten du dort abfragst und wofür, aber trotzdem wundert es mich, dass das für eine Registrierung so viel ist. Falls du dort schon Dinge abfragst, die sich z. B. auf das Benutzerprofil beziehen (Interessen, Lieblings-Irgendwas, Profildesign, ...) würde ich davon abraten. Lieber die User erstmal mit Minimalaccount und Nullprofil anfangen und sich umsehen lassen, als durch eine umfangreiche Registrierung abschrecken. Nach einer Woche kannst du sie dann immer noch "zwingen", irgendwas auszufüllen ;)

Erzähl doch mal, was du genau vorhast, vielleicht findet sich dann noch der eine oder andere Verbesserungsvorschlag.

Hm...ist umfangreicher und für einen Kunden. Ich kann ja ein bißchen davon erzählen: bei der Registrierung sollen (nach Wunsch des Kunden), personenbezogene, bürokratische und persönliche (Adresse, Aussehen usw.) Daten abgefragt werden. Registriert er sich, bekommt er eine Aktivierungsmail zur Bestätigung. Nach dem Login ist ein vorerst nur Teil des Systems zugänglich. Erst wenn er dort ein weiteres, längeres Formular mit zusätzlichen Daten ausfüllt, wird das System (Menüpunkte etc.) komplett zugänglich für ihn sein.
Zudem Soll es mehrere Berechtigungen geben: User, eine Art Moderator/Autor und sowas wie der Administrator. Jeder hat unterschiedliche Berechtigungen. Zusätzlichen können sich unterschiedliche Institutionen registrieren & einloggen. Der Administrator einer Institution vergibt/schalter Rechte/Rollen frei. Institutionen sind unabhängig voneinander, somit kann "jeder" auch in diesem System unterschiedliche Rollen einnehmen, je nach Situation.
Na ja, und sonst halt CMS ähnliche Geschichten, wie Terminkalender, SMS Versand, Grafische Auswertung, Buchhaltungsgeschichten, Workflows...usw. Arbeite mit mit MSSQL & PHP 5. Zusätzlich setze ich Stored Procedures ein.

so, denke jetzt hast Du einen kleinen Überblick:)!

mfg streuner

Achso, also eher für einen spezialisierteren Nutzerkreis und eher geschäftlich als privat? Ich dachte zuerst eher an eine Art Community-Portal oder sowas. Dann finde ich deine Herangehensweise völlig in Ordnung.

Bei Institutionen hab ich die Erfahrung gemacht, dass manche eine sehr restriktive Sicherheitspolitik fahren und z. B. nur bestimmte (uralte) Browser benutzen. Für dich heißt das, eventuell auf abwärtskompatiblen Code zu achten und unbedingt ein Höchstmaß an Sicherheit zu gewährleisten. Schutz vor SQL Injections und XSS sollte selbstverständlich sein. HTTP Basic Authentication ist da vielleicht auch nicht so angebracht, da dürfte es dann schon Digest Authentication sein oder gleich alles auf SSL auslegen. Hast du dir in der Richtung schon Gedanken gemacht?

Achso, also eher für einen spezialisierteren Nutzerkreis und eher geschäftlich als privat? Ich dachte zuerst eher an eine Art Community-Portal oder sowas. Dann finde ich deine Herangehensweise völlig in Ordnung.

Ok, dann bin ich beruhigt:).

Bei Institutionen hab ich die Erfahrung gemacht, dass manche eine sehr restriktive Sicherheitspolitik fahren und z. B. nur bestimmte (uralte) Browser benutzen. Für dich heißt das, eventuell auf abwärtskompatiblen Code zu achten und unbedingt ein Höchstmaß an Sicherheit zu gewährleisten. Schutz vor SQL Injections und XSS sollte selbstverständlich sein. HTTP Basic Authentication ist da vielleicht auch nicht so angebracht, da dürfte es dann schon Digest Authentication sein oder gleich alles auf SSL auslegen. Hast du dir in der Richtung schon Gedanken gemacht?

Ja, Vorgaben sind sogar eher "Spielereien & optischer Schnickschnack" mit AJAX uns CSS. Wollte in die Richtung ssl sowieso gehen und für SQL-Injection & XSS habe ich eine Klasse geschrieben, der ich Variablen etc. übergebe. Zudem werden Ordner mit htaccess geschützt und mode-rewrite angepasst. Denke, damit dürfte ich alles abdecken, oder?
Vieles, was im Pflichten- und Lastenheft steht, ist umsetzbar, aber nicht unbedingt erforderlich und kann zu Problemen gerade durch JavaScript Deaktivierung etc. führen.

Ich finde es schwierig "Laien" die Problematik zu erklären, warum man Spielereien weg lassen will und dagegen eher auf stabilen Code setzt. Argumente wie "AJAX ist die Zukunft und soll bei uns auch durchgehend eingesetzt werden" und "Warum soll AJAX ein Problem sein? Die technologie gibt es und wird auf vielen Webseiten eingesetzt?". tja:teach:! Zudem stand ursprünglich im Fplichtenheft "Frames", aber das habe ich denen ausgeredet:grin:.

Anbei: Digest Authentication habe ich schon gehört, aber noch nicht speziell mich damit auseinander gesetzt. Habe dazu diese Website gefunden: 3.3. Digest Authentication (http://zf-blog.de/dokumentation/zend.auth.adapter.digest.html)! Ist dieser zusätzliche Schritt noch notwendig?

mfg streuner

Anbei: Digest Authentication habe ich schon gehört, aber noch nicht speziell mich damit auseinander gesetzt. Habe dazu diese Website gefunden: 3.3. Digest Authentication (http://zf-blog.de/dokumentation/zend.auth.adapter.digest.html)! Ist dieser zusätzliche Schritt noch notwendig?

Wenn du alles mit SSL machst und speziell auch das Login schon auf einer https-Seite erfolgt, brauchst du keine Digest Auth zusätzlich, da die Anmeldedaten dann durch SSL sowieso sicher übertragen werden. Digest Auth macht nur Sinn, wenn man sich ohne SSL sicher Einloggen und Replay-Attacken vermeiden will.

Spielt der Server bei SSL überhaupt mit? Man kann auf einem namensbasierten Virtual-Host-System nicht so ohne weiteres SSL verwenden.

BTW: Soll ich den Thread vielleicht doch lieber in die Brainstroming-Rubrik schieben?

Wenn du alles mit SSL machst und speziell auch das Login schon auf einer https-Seite erfolgt, brauchst du keine Digest Auth zusätzlich, da die Anmeldedaten dann durch SSL sowieso sicher übertragen werden. Digest Auth macht nur Sinn, wenn man sich ohne SSL sicher Einloggen und Replay-Attacken vermeiden will.

Ok, gut.

Spielt der Server bei SSL überhaupt mit? Man kann auf einem namensbasierten Virtual-Host-System nicht so ohne weiteres SSL verwenden.

Hm, die stellen einen eigenen Server mit eigenem Mail System, Apache PHP 4 & 5 zur Verfügung, auf den ich per Remote zugreifen kann. Momentan arbeite ich lokal. Ursprünglich ist die Absprache, dass die die notwendigen technischen Anforderungen, die abgesprochen sind, zur Verfügung stellen?!

BTW: Soll ich den Thread vielleicht doch lieber in die Brainstroming-Rubrik schieben?

Kannst Du auch gerne machen.

mfg streuner

Kannst Du auch gerne machen.

Ich bin blöd, wir sind doch schon im Brainstorming. Ich hatte nur HTML/JS/CSS gelesen :D

OK, ansonsten fällt mir grad nichts mehr ein, was ich dir noch mit auf den Weg geben könnte ;)

Viel Erfolg!

Ich bin blöd, wir sind doch schon im Brainstorming. Ich hatte nur HTML/JS/CSS gelesen :D

...ich hatte mich gerade auch schon gewundert:rofl:!

OK, ansonsten fällt mir grad nichts mehr ein, was ich dir noch mit auf den Weg geben könnte ;)

Viel Erfolg!

Vielleicht noch eine Kleinigkeit: ist es sinnvoll den Quellcode bei Abgabe z.B. mit Zend zu verschlüsseln, oder haben die Anspruch auf lesbaren Quellcode? Geht um weitere Verwendbarkeit...etc.! Und noch was: es gibt bei denen anscheinend schon irgendwelche kleinen JSF Geschichten. Die Frage war jetzt, ob ich mit PHP auf Klassen/Funktionen und Variablen von JSF zugreifen kann. Geht sowas/gibt es Schnittstellen? Das wäre es erstmal:)!

Danke Dir.

mfg streuner

ist es sinnvoll den Quellcode bei Abgabe z.B. mit Zend zu verschlüsseln, oder haben die Anspruch auf lesbaren Quellcode?

Wenn du nur eine (oder mehrere) Lizenz(en) für das fertige Produkt verkaufst, kannst du den Quellcode verschlüsseln, denn du willst ihn ja auch an andere weiterverkaufen.

Wenn du für die Entwicklung bezahlt wirst, haben die imho auch Anspruch darauf, den Quelltext zu sehen.

es gibt bei denen anscheinend schon irgendwelche kleinen JSF Geschichten. Die Frage war jetzt, ob ich mit PHP auf Klassen/Funktionen und Variablen von JSF zugreifen kann. Geht sowas/gibt es Schnittstellen?

PHP: Java - Manual (http://php.net/java)

Thanx, sieht ja gar nicht so wild aus mit PHP darauf zuzugreifen.

mfg streuner