[survey_ce] Umfragewerkzeug

[hschottm]

Noch eine Kleinigkeit: zumindest in offenen Fragen werden die runden Klammern '(' und ')' als ( und ) in tl_survey_result geschrieben und dann auch so ins Excel geschrieben.

Das habe ich jetzt geändert, allerdings auf DCA-Ebene, d.h. du müsstest die Fragen, bei denen es mit den Klammern nicht hinhaut, noch einmal neu speichern. Das geht natürlich nicht bei einer bestehenden Umfrage, aber bei allen späteren sollte es problemlos funktionieren:

'decodeEntities' => true 

in eval war das Geheimnis.

Außerdem habe ich das fehlerhafte "Array" Popup korrigiert, das über den Detail-Auswertungsschaltflächen war.

Gruß,
Helmut

[hschottm]

Noch eine Frage zum Sprachenfeld in Umfrage und Frage: hat das irgendwelche Auswirkung, ausser bei der Skalenauswahl? Falls nicht, hast Du damit Pläne?

also erst mal hab ich das Sprachen-Feld "nur" eingebaut, weil ich mir dachte, dass es eventuell zu einem späteren Zeitpunkt einen Bedarf geben könnte. Weitere Auswirkungen hat es aber noch nicht. Bis ich bei einer mehrsprachigen Umfrageunterstützung bin, geht wohl noch etwas Zeit ins Land. Ich weiß auch nicht, ob das dann noch so gut zu verwalten ist. Getrennte Umfragen sind hier evtl. Vorteilhaft. Man könnte aber die Spracheinträge dazu nutzen, evtl. Nutzer, die eine andere Sprache verwenden darauf hinzuweisen, dass die Umfrage nicht in Ihrer Sprache ist oder etwas ähnliches (evtl. auch das Ausführen verhindern, weil es nicht sinnvoll ist).

Gruß,
Helmut

[deerwood]

Moin Helmut, alle,

... Aufruf von "Statistik der Umfrage ID X anzeigen" ist SEHR langsam, dauert etwa so lange, wie der kumulierte Excel Export, selbst bei einer Umfrage ohne Teilnehmer/Antworten. Das fällt vor allem auf, wenn man sich die Details hat anzeigen lassen und dann mit "Zurück" wieder in die Liste geht. Hier wäre eine Optimierung wünschenswert.

Ich habe da mal hingeschaut und gesehen, dass die Ermittlung der absoluten Fragennummer [Objekt-Methoden getQuestionPosition()] nicht sonderlich optimiert war. Für jede Frage wurde die DB erneut bemüht. In den anhängenden Patches habe ich das DB Resultat zwischengespeichert und damit, für meinen Fall (124 Fragen auf 14 Seiten), eine deutliche Beschleunigung erzielen können, sowohl im Frontend beim Blättern durch die Seiten der Umfrage, wie auch im Backend. Ausgemessen habe ich den Zeit-Unterschied nicht, aber jedenfalls ist er in beiden Fällen deutlich spürbar.

Im Backend könnte man weiter optimieren, indem man in der zentralen Schleife einfach einen Zähler führt ... das liefere ich bei Gelegenheit nach, vor allem, weil ich im Backend zusätzlich zur absoluten Fragennummer auch noch die Seitennummer und die Fragennummer auf der Seite angezeigt hätte (ebenfalls machbar über PHP Zähler).

Noch eine Bemerkung zum Stil, besonders meiner SQL Statements: ich versuche schon, dem Stil vorhandenen Codes weitestgehend zu folgen. Ich KANN aber mit SQL Statements in einer einzigen langen Zeile nicht leben, weil ich dann nicht verstehe, was da erreicht werden soll und wie man das optimieren kann. Ich weiss, dass das in TL durchgängig so ist und weiche hier mit voller Absicht davon ab. Einzeiler, mal abgesehen von "SELECT * FROM tl_xyz", sind in meinen Augen NICHT wartbar! Ich nehme den zusätzlichen Whitespace gern in Kauf (die Database Klasse räumt den sowieso aus dem Weg) zugunsten der Lesbarkeit/Wartbarkeit.

Natürlich kann und will ich meinen Stil niemandem aufzwingen ... dennoch würde ich mich freuen, wenn sich ein solcher Stil nach und nach in TL verbreiten würde.

LG, HTH, Georg

PS/Edit: patches sind gegen Build 35. In languages/en fehlt das .htaccess (wie vorhanden in languages/de)

[deerwood]

Moin moin,

Im Backend könnte man weiter optimieren, indem man in der zentralen Schleife einfach einen Zähler führt ... das liefere ich bei Gelegenheit nach, vor allem, weil ich im Backend zusätzlich zur absoluten Fragennummer auch noch die Seitennummer und die Fragennummer auf der Seite angezeigt hätte (ebenfalls machbar über PHP Zähler)

Im Anhang die versprochene Optimierung mit Zählern (immer noch gegen Build 35, enthält auch noch die optimierte Methode getQuestionPosition(), obwohl sie im Patch nicht mehr benutzt wird). Wie Ihr seht, habe ich auch das Backend Template angepasst, damit sieht meine Liste der kumulierten Resultate (ohne langsamer geworden zu sein) jetzt so aus, wie im Bild unten gezeigt (mit Seiten#.Fragen#).

LG, Georg

[hschottm]

Hallo Georg,

danke schon mal von meiner Seite aus. Ich habe heute eine OP und bin dann wegen Hand-Gips wahrscheinlich länger nicht einsatzfähig, werde aber sehen, dass ich deine Änderungen irgendwie noch einbringe.

Was deinen SQL-Stil angeht: Kein Problem. Ich bin da nur meist zu faul für die Umbrüche und mit meinem 28" Bildschirm geht bei hoher Auflösung auch viel in eine Zeile rein... Bei TYPOlight ist es bei mir nun auch so, dass ich die meisten Erweiterungen "mal eben schnell" rausgehauen habe, weil ich das auch nur nebenbei mache. Das soll natürlich keine Entschuldigung sein, trifft aber leider den Kern. Es fehlen auch viele Kommentare.

Ich hoffe, dass ich zum WE mit einer Hand dann dazu komme, mich um deine Patches zu kümmern. Vielen vielen Dank auf jeden Fall schon einmal!

Gruß,
Helmut

[deerwood]

Lieber Helmut,

alles Gute für Dich! Mach Dir bloß keinen Stress wegen der Patches, sieh lieber zu, dass Du in Ruhe wieder gesund wirst, das ist viel wichtiger. Meine letzten Änderungen sind ja reine Optimierungen, keine Bugfixes, das kann warten. Survey_ce funktioniert auch ohne sie.

Edit: meine Patches sind auch noch nicht komplett, weil ich die Nummerierung von Seiten und Fragen, sowohl absolut bezüglich der Umfrage, wie auch relativ zur Seite, gern überall durchziehen würde (es fehlt noch die Nummerierung im kumulativen Export (parallel zur ID der Frage) und im Backend, wenn man Seiten/Fragen bearbeitet. Ich arbeite daran und werde meine Änderungen in den nächsten Tagen hoffentlich vollständig machen können. Erhole Dich also in Ruhe, meine Kleinigkeiten sind nicht für die Allgemeinheit wichtig (und für mich funktionieren die Patches).

Die Nummerierung (sowohl die absolute, wie auch die relative) ist wichtig für meinen Fall, weil die Kommunikation mit den Testern/Verantwortlichen darüber läuft. IDs allein sind nicht ausreichend, weil z.B. der Übersetzer einer Umfrage (der an einer Kopie der Original-Umfrage arbeitet) mir via ID nicht mitteilen kann, wo er hängt ... über die Nummerierung aber schon.

Kurzer Erfolgs-Bericht:
meine mehrseitige/komplexe Umfrage läuft in DE und EN und in einer dritten Variante mit einer anderen Währung ... mit SEHR guten Teilnehmerzahlen. Mein Kunde ist sehr zufrieden.

Edit2: noch keine Patches (vor allem, damit Helmut nicht auf dumme Gedanken kommt und einhändig tippt, sondern sich schont), nur ein Bild des kumulativen Excel-Exports, damit Ihr seht, dass ich weiter mache.

LG, Georg

[deerwood]

Hallo alle,

ich schrieb ja schon, dass meine Umfrage dank Helmuts survey_ce mit sehr gutem Erfolg läuft ... mit so gutem Erfolg, dass Excel (97 vermutlich) inzwischen überfordert ist:

mehr als 255 Menschen haben teilgenommen und da es einige Pflichtfelder vom Typ offene Frage gibt (z.B. die eMail) hat der Excel Export mehr als 256 Spalten. Kein Problem für das Plugin "xls_export", aber ältere Excel-Versionen haben ein Limit von 256 Spalten und schneiden die überzähligen einfach ab (+ Fehlermeldung).

Mein Workaround: OpenOffice.org 3.x Calc benutzen, dort ist das Limit deutlich größer (1024 Spalten).

Aber ich denke auch gerade darüber nach, ob es es nicht besser wäre, wenn der Export so viele Teilnehmerdaten über mehrere Arbeitsblätter verteilt. Mal schauen, wie aufwendig das ist.

LG, Georg

[hschottm]

Hallo Georg,

ja, die 255 Spalten sind im alten Excel ein Problem. In anderem Zusammenhang stoße ich auch mit den maximalen 32767 Zeilen auf ein Problem.
Mit OpenOffice kann man das umgehen und wir sollten wirklich sehen, dass wir evtl. PHPExcel mit ins Spiel bringen, das kann Excel XML erzeugen. Allerdings eben nur mit php_zip-Erweiterung und die hat nicht jeder.

LG,
Helmut

[Huber]

Liebe alle

Ich habe mit survey_ce eine personalisierte Umfrage erstellt und in die Website erfolgreich einbinden können...

In der Zwischenzeit ist die Umfrage abgeschlossen. Ich bin gerade daran, die Rückmeldungen auszuwerten. Mit Hilfe der Datei <typolight_survey_ce.pdf> hat das eigentlich bestens geklappt...

Was mir noch fehlt, sind Rückschlüsse, was ein einzelner Teilnehmer auf die Fragen geantwortet hat. Ist das möglich?

Ich hoffe, in der Community eine Antwort darauf zu erhalten.

Grüsse, Sandra

[deerwood]

Liebe Sandra,

Was mir noch fehlt, sind Rückschlüsse, was ein einzelner Teilnehmer auf die Fragen geantwortet hat. Ist das möglich?

ich arbeite gerade an dem detaillierten Export. Gegenwärtiger Stand: die Typen "Offene Frage" und "Multiple Choice Frage" jeweils mit allen Untertypen werden ausgegeben; "Matrixfrage" und "Konstante Summe" fehlen noch, einige Kleinigkeiten im Code sind auch noch zu bereinigen.Wenn mein Export fertig ist, werde ich ihn hier veröffentlichen (LGPL).

LG, Georg

[Huber]

Hallo Georg

Dann freue ich mich, wieder von dir zu lesen...

LG Sandra

[deerwood]

Moin Sandra, alle,

ich könnte eine pre-Alpha-Version meines detaillierten Exports für 'surevy_ce' zur Verfügung stellen und würde mich über Besichtigung / Test / Kritik freuen.

PRE-alpha, weil:

• der Fragentyp "Konstante Summe" noch garnicht behandelt/ignoriert wird
• bei Matrixfragen der Untertyp "Mehrfachauswahl" ebenfalls noch nicht behandelt wird
• manche Strings noch hart kodiert sind, statt TL_LANGUAGE zu benutzen
• noch reichlich Optimierungen im Code möglich sind

Wer mit den genannten Einschränkungen leben kann (zumindest für eine erste Besichtigung bzw. einen ersten Test) ist herzlich eingeladen.

Der Export ist im Moment als Erweiterung zu 'survey_ce' implementiert. Er ändert weder Datenbank noch Dateien (abgesehen von einer temporären Datei, die das Plugin "xls_export" vor dem Download erfordert).

Der detaillierte Export gibt sämtliche Fragen/Unterfragen/Auswahlen in Excel/OOCalc-Spalten aus.

Teilnehmer werden in den Zeilen ausgegeben, die Antworten der Teilnehmer dann im Kreuzungspunkt von Frage/Unterfrage und Teilnehmer (eine große Matrix)..Damit kann jede Antwort einem Teilnehmer zugeordnet werden. Die Antworten können auch leicht nach verschiedenen Kriterien sortiert werden (in Calc/Excel).

Allerdings kann die Excel/OOCalc-Tabelle recht groß werden (siehe anliegendes Bild). In meinem Fall (14 Seiten, 124 Fragen, viele davon Multiple-Choice/Matrix) habe ich knapp unter 500 Spalten im Arbeitsblatt und etwa 400 Zeilen für die bisherigen Teilnehmer. Damit ist Excel 95 jedenfalls überfordert, ich benutze OpenOffice Calc 3.1 (und mein Kunde auch). Auch das ist ein Hinweis auf den ALPHA Status ... in einer BETA Version könnte ich Optionen für die Umfrage einführen, die erlauben, den Export auf verschiedene Arbeitsblätter zu verteilen (z.B. nach Umfrage-Seite oder Fragen-Typ).

Bei Hilfbereitschaft/Bedarf bitte kurz melden; dann stelle ich meine Erweiterung vorläufig hier (zur manuellen Installation, mit Hinweisen, wie man das macht und was zu beachten ist) zur Verfügung.

LG, Georg

[lucina]

Hallo Georg,

ja, das interessiert mich - kannst ja den Link per PN schicken, wenn Du TesterInnen brauchst.

Carolina.

[deerwood]

Moin Carolina, Sandra, alle,

entschuldigt bitte die Verzögerung, ich habe noch einen Fehler korrigiert und die "Matrix - Mehrfachauswahl" nachgerüstet (letztere nicht intensiv getestet, weil sie in meiner Umfrage nicht vorkommt ... und auch eher ungewöhnlich ist?). Ausserdem habe ich endlich auch die versprochenen hart kodierten Texte eingebaut (Methode für Top Left).

Edit: Was hat man davon:
Siehe Bilder in der Anlage.

Voraussetzungen für die Installation:

• [survey_ce] natürlich, möglichst in der aktuellen Version 1.0.2 stable. Aber der Export sollte auch mit etwas älteren Versionen funktionieren.
• [xls_export] UNBEDINGT in mindestens der aktuellen Version 1.0.1. Dort hat Helmut eine Fehler-Korrektur und zwei Methoden eingebaut, die in dem Export benötigt werden!

Installation:
zur Zeit nur manuell: das survey_ce_ex.zip aus der Anlage lokal entpacken und dann die ausgepackten Dateien sinngemäß auf den Server hochladen. Nach dieser Aktion muss das Verzeichnis ....../system/modules/survey_ce_ex/ existieren und darin alle im zip befindlichen Dateien/Unterverzeichnisse. Edit: Die DB Struktur wird nicht geändert, deshalb braucht auch das Installtool nicht aufgerufen werden.

Bekannte Probleme:
Wie bereits erwähnt hat MS Excel in älteren Versionen diverse Einschränkungen, z.B. maximal 256 Spalten ... dieser Export kann aber leicht auch deutlich mehr Spalten erzeugen. Heute musste ich erfahren, dass Excel offenbar auch noch eine 256 Zeichen Grenze in den Zellen hat ... darauf nimmt der Export keine Rücksicht (ich wüsste auch nicht wie ich das handhaben sollte). Das Problem ist dabei nicht im Plugin "xls_export" zu suchen, sondern in der alten Version von Excel auf Eurem System.

Ich benutze OpenOffice.org Calc und habe den Export nur damit getestet. Ich bin auch nicht bereit, viel Geld für veraltete Software auszugeben. Falls ein Tester eine aktuelle Version von Excel zur Verfügung hat, würden mich die Ergebnisse sehr interessieren, vor allem verglichen mit dem OO Calc Ergebnis.

Edit: noch einige kleine Fehler korrigiert und den Fragentyp "Feste Summe" implementiert, neue Version hochgeladen. Falls Ihr Euch fragt, wie man den Export aufruft, siehe Bild.

LG, Georg

[deerwood]

Hallo alle,

was mich interessiert: funktioniert der Export für Euch, falls nicht, welche Probleme / Fehlermeldungen tauchen auf? Läßt sich die XLS Datei in aktuellen Excel-Versionen problemlos anzeigen, auch bei mehr als 256 Spalten bzw. offenen Fragen mit langen Antworten (mehr als 256 Zeichen)? Sollte mehr Formatierung eingesetzt werden (xls_export hat limitierte Möglichkeiten, aber verschiedenen Hintergrund/Text-Farben wären möglich und farbige Ränder, z.B. zwischen zwei Matrix-Fragen). Ist das Zentrieren der Antworten OK, oder sollten die Antworten zu offenen Fragen linksbündig sein? Wünscht Ihr Euch die Ausgabe auf mehrere Arbeitsblätter verteilt?

LG, Georg

[lucina]

Ich brauche da noch ein paar Tage zum Testen, muss erstmal ein System klonen & hab grad Arbeit bis über beide Ohren.

MfG, Carolina.

[deerwood]

Moin alle,

ich habe mich mal im Netz informiert, welche Excel Grenzen dem Export im Wege stehen können und gebe das hier mal weiter (Edit: OO Calc nachgetragen):

Siehe: http://www.xlam.ch/xlimits/

                       Zeilen  Spalten  Zeichen/Zelle
                    ---------  -------  -------------
Excel 95 & älter       16,384      256            255
Excel 97               65,536      256         32,767 *
Excel 98 (Mac)         65,536      256         32,767 **
Excel 2000             65,536      256         32,767 *
Excel 2001 (Mac)       65,536      256         32,767 **
Excel 2002             65,536      256         32,767 *
Excel X (Mac)          65,536      256         32,767 **
Excel 2003             65,536      256         32,767 *
Excel 2004 (Mac)       65,536      256         32,767 ***
Excel 2007          1,048,576   16,384         32,767
OO Calc 3.1            65,536    1,024        >32,767 (1)

*   nur ~1,024 Zeichen werden in der Zelle gezeigt/gedruckt, im Bearbeitungsbereich werden alle Zeichen gezeigt
**  nur ~1,085 Zeichen werden in der Zelle gezeigt/gedruckt, im Bearbeitungsbereich werden alle Zeichen gezeigt
*** nur ~1,054 Zeichen werden in der Zelle gezeigt/gedruckt, im Bearbeitungsbereich werden alle Zeichen gezeigt
(1) selbst getestet

Es scheint weitere (z.T. merkwürdige) Limitationen zu geben, auch in Excel 2007, siehe:
http://www.xlam.ch/xlimits/xllimit3.htm#Limitationen bei Bearbeiten von Zelltexten

Ich muss dann wohl doch ernsthaft über eine Verteilung der Detail-Antworten über mehrere Arbeitsblätter nachdenken, um das 256 Spalten Limit der gängigen Excel-Versionen zu umgehen.

Als Workaraund ist immer noch Calc 3.1 angesagt (hat auch Grenzen, die liefere ich nach); das tut aber für uns den Job gut genug.

Wie ich das Excel-Problem 256 bzw. ~1024 Zeichen pro Zelle angehen soll, ist mir bisher nicht klar, hier bitte ich um Vorschläge. In meinen Umfragen habe ich jedenfalls diverse Antworten zu "offenen Fragen", die deutlich länger sind als 1024 Zeichen. Und mein Kunde legt größten Wert darauf, sämtlichen Text lesen zu können; sinngemäßes Zitat: "Solche Informationen können wir auf keinem anderen Weg erhalten". Und er meint sowohl Kritik (einschließlich 1/2 A4 Seite Schilderung eines Problems) wie auch Lob und Vorschläge (auch hier oft seitenfüllend).

Bei einem Treffen heute hat mein Kunde in etwa gesagt: "Meldet mal weiter, unsere letzte Umfrage auf Papier/FAX hat Antworten von 30% der Zielgruppe geliefert, die Online-Umfrage etwa 70%".

Damit war ich nicht ganz unzufrieden.

Danke Helmut für Deine tolle Erweiterung!

LG, Georg

[hschottm]

Es ist wirklich schade, dass die PHPExcel-Erweiterung dieses blöde php_zip Modul verwendet, was sie leider nicht universell einsetzbar macht.
Mit dem Excel-XML-Format würden wir natürlich sämtliche Einschränkungen umgehen.

Evtl. schaue ich mal, ob man php_zip nicht durch einen geeigneten Code ersetzen kann...

LG,
Helmut

[deerwood]

Hallo Helmut, alle,

erstmal: ich habe oben die OO Calc 3.1 Grenzen nachgetragen.

Es ist wirklich schade, dass die PHPExcel-Erweiterung dieses blöde php_zip Modul verwendet, was sie leider nicht universell einsetzbar macht.
Mit dem Excel-XML-Format würden wir natürlich sämtliche Einschränkungen umgehen.

Das war nicht mein Anliegen. Das Problem wird ja nicht durch das Plugin "xls_export" hervorgerufen: das erzeugt ohne weiteres mehrere tausend Spalten (siehe Anlage und unten) und kann auch problemlos Zellinhalte mit deutlich mehr als 1024 Zeichen erzeugen. Auch das verwendete BIFF5 Format scheint das herzugeben, sonst würde ich in OO Calc die vielen Spalten/Zeichen ja nicht sehen können.

Das Problem liegt bei den Excel Versionen älter als 2007 und die sind bei den Nutzern sehr häufig noch vorhanden. Und es gibt Gründe nicht auf Excel 2007 bzw. OO Calc zu wechseln, z.B. Lizenzkosten, existierende umfangreiche Excel-"Anwedungen" (mit Makros/VBA Programmierung), Installations-Aufwand und Schulungs-Aufwand im Firmenumfeld, Resistenz von Nutzern gegen Neuerungen.

Deshalb werde ich den detaillierten Export, sobald ich Zeit habe, so erweitern, dass er die Antworten auf mehrere Arbeitsblätter verteilen kann. Sollte nicht so schwierig sein.

In der Anlage ein ZIP mit *.xls Dateien, die jeweils 2 Zeilen und verschieden viele Spalten haben (255-2049, Zellen enthalten Zahlen), alle mit "xls_export" erzeugt. Bis 1024 Spalten lassen sich alle ohne Meldung/Probleme in Calc öffnen, die anderen erzeugen einen Hinweis und werden nach Spalte 1024 abgeschnitten.

Meine Bitte: könnte jemand mit Excel 2007 diese Dateien öffnen und hier berichten, ob das ohne Probleme/Warnungen funktioniert?

Falls Excel 2007 die Testdateien öffnen kann, sehe ich keinen echten Bedarf, auf PHPExcel umzustellen. Es fehlen mir auch nur Kleinigkeiten, die "PHPExcel" kann, aber "xls_export" nicht:

• Erzeugung von Notizen zu Feldern.
• Formatierung von Zahlen als Datum oder mit Tausender-Trenner.
• Ausgabe von Formeln als Zellinhalt.

Ist aber alles nur "nett zu haben", nicht lebenswichtig.

LG, Georg

[lucina]

Mit Excel 2007 (12.0.6514.5000) SP2 ist bei mir leider nach 256 Spalten Schluß.

Sorry ...

Carolina.

[Coduck]

Hallo Georg,

unter Excel 2007 gaben sich nur die ersten beiden Dateien "test_255_cols.xls" und "test_256_cols.xls". Bei den Restlichen wurde die Meldung "unlesbarer Inhalt" / "Dateifehler: Die Daten sind möglicherweise verloren gegangen" ausgegeben.

[deerwood]

Moin Carolina, Manfred,

vielen Dank für das umgehende Testen! Hmm, ich weiß schon, warum ich Open Source so mag und von kommerzieller Software mehr als einmal enttäuscht worden bin .

Dann bleibt wohl nichts anderes: neben der Option zur Aufteilung auf mehrere Arbeitsblätter für die Unterstützung älterer Excel-Versionen auch noch die Nutzung von PHPExcel, sofern installiert. Denn der nicht aufgeteilte Export hat den unschätzbaren Vorteil, dass man nach beliebigen Antworten sortieren/filtern kann und das Arbeitsblatt dann z.B. als Datenbasis für selbst erstellte Arbeitsblätter mit Teil-Informationen verwenden kann. Aber die optionale Verwendung von PHPExcel ist reichlich Aufwand, das kann ich nicht kurzfristig hinkriegen.

Nachtrag: wie peinlich das Verhalten von Excel 2007 für MS sein sollte: seht doch mal das anliegende Bild. Das ist ein Plugin für den TotalCommander (beide allerdings nicht Open Source, TC kostet was, das Plugin ist kostenlos). Zeigt jedenfalls, dass weder das BIFF5 Dateiformat noch xls_export die Anzahl von Spalten unnötig limitieren. Und OO Calc sollte auch endlich mal, bezüglich Anzahl von Spalten/Zeilen, zu Excel 2007 aufschließen.

LG, Georg

[deerwood]

Moin Helmut, alle,

ich denke, "survey_ce 1.0.2 stable" kann für TL 2.8.0 freigegeben werden (dito "textwizard 1.1.0"). Ich habe auf einer frischen 2.8.0 Test-Installation eine neue Umfrage mit sämtlichen Fragen-Typen und Untertypen im Backend erstellt und im Frontend durchgespielt. Keinerlei Problem. Siehe auch diesen weiteren unabhängigen Test.

Außerdem arbeitet "survey_ce" auch ohne Probleme mit "xls_export 1.0.1" zusammen .

LG, Georg

[hschottm]

Moin Georg,

ich bin gerade am Umstellen und am sorgfältigen Prüfen meiner Erweiterungen. Da ich bei survey_ce eigentlich keinerlei Routinen von Core-Klassen überschreibe, dürfte das wohl so sein, dass man es einfach benutzen kann. Ich möchte trotzdem noch mal drüberschauen.
Wie sieht es eigentlich mit deinem Export aus? Sollen wir den in die neue Version schon mit reinnehmen?

LG,
Helmut

[deerwood]

Hi Helmut,

Wie sieht es eigentlich mit deinem Export aus? Sollen wir den in die neue Version schon mit reinnehmen?

Nein, bitte noch nicht, er hat immer noch hart codierte Texte und ich schaue auch gerade noch mal über Code und Kommentare um da etwas aufzuräumen. Zudem habe ich noch keinerlei Feedback von Anderen und würde ungern Deinen "stable" Code mit meinem "aplha" verschandeln .

Und der Export läuft ja als eigenständige Erweiterung zu survey_ce in 2.7.6 und 2.8.0. Bei einer Voll-Integration könnte ich noch zwei Methoden in die Superklasse SurveyQuestion refaktorieren, die in allen 4 Fragentypen gebraucht werden, aber bis dahin kann ich mit Copy/Paste gut leben.

Und schließlich würde ich sehr gern noch die Erweiterungen, die Leslie Olah auf meinen Wunsch hin in seinen php-excel-export eingebaut hat (Notizen, Formatierung von Zahlen/Datum/Zeit und einige Excel-Funktionen wie SUM und AVG) intensiv testen und dann in meinem Export verwenden.

LG, Georg

[sunshone2010]

Das Umtragetool funktioniert grundsätzlich klasse. Wir haben nur das Problem, dass die Ergegbnisse der Umfrage nicht vollständig erfasst werden.

Wir haben eine Umfrage mit ca. 6-7 Fragen.


In der Statistik taucht nach einer Bewertung jedoch nur Frage 1 auf!

In der Excelstatistik tauschen hingegen die Bewertungen aller Fragen auf!

[deerwood]

Moin sunshone,

In der Statistik taucht nach einer Bewertung jedoch nur Frage 1 auf!

Ich konnte das mit survey_ce V 1.0.2 stable Build 36 und TYPOlight 2.8.0 reproduzieren.

In der Anlage eine gepatchte Version von SurveyResultDetails.php, die das beheben sollte (nebenher vermeidet sie auch eine Reihe unnötiger DB-Zugriffe und macht die Statistikseite dadurch schneller).

Bitte packe das ZIP aus, tausche die Original-Datei auf Deinem Server gegen diese Version der Datei, teste, ob dann alle Fragen ausgegeben werden und berichte hier. Für mich jedenfalls funktioniert die modifizierte Version.

@Helmut: ich habe noch nicht ganz geschnallt, warum SurveyResultDetails::getQuestionPosition(), das in der gepatchten Version nicht mehr benötigt/aufgerufen wird, in TL 2.8.0 nicht mehr funktioniert. Das hat vermutlich mit dem neu eingeführten Cachen von Queries in Klasse Database zu tun. Aber es ist ja immer das gleiche Query mit immer der gleichen survey_id, das sollte doch einfach nur schneller laufen? Kannst Du, oder jemand anderes, mir das erklären? Ich werde auch noch mal ein wenig weiter forschen.

Edit: executeUnchached() statt execute() in getQuestionPosition() geht jedenfalls auch (ist dann jedoch weniger effizient). Was ich gar nicht verstehe, ist, dass dann die while-Schleife in showCumulated() offenbar nur noch die erste Resultat-Zeile liefert. Hat sicher damit zu tun, dass die Queries in showCumulated() und getQuestionPosition() identisch sind. Irgendwie werde ich das Gefühl nicht los, dass das Cachen der Queries in 2.8.0 unausgegoren ist: Dein Originalcode ist zwar nicht gerade besonders effizient, aber er ist ja nicht falsch!

Es gibt noch eine weitere Methode getQuestionPosition() in Klasse ContentSurvey, die sollte dann sicherheitshalber auch executeUncached() benutzen. Diese kann man auch nicht ohne weiteres durch ein $number++ ersetzen, aber, für die Effizienz, kann man das Resultat-Id-Array in einer Member-Variablen speichern und bei dem 2., 3. usw. Zugriff das array_search() darauf ausführen. Ich habe das ja alles für mich schon eingebaut und werde das demnächst mal komplett zur Verfügung stellen. Ist allerdings auch eine kleine Template-Anpassung dabei (für Seiten-Nummer und Nummer der Frage auf der Seite).

LG, Georg

[hschottm]

Boah Georg,

bei deinen Zeiten wird's mir immer anders... :-)
Ich denke schon immer, dass ich extrem viel mache, aber wenn ich mir das bei dir so ansehe.
Danke für's nachforschen. Ich werde sehen, dass ich das möglichst schnell übernehme. Dass ich an der Effizienz der Abfragen noch arbeiten muss, das war mir klar. Das ich die Umfrage rausgebracht habe, war "leider" ein ziemlicher Schnellschuss, da Nina das Tool gerne einsetzen wollte und so habe ich ehrlich gesagt einfach nur drauf los gecodet und keinerlei Zeit in Konzeption gesteckt.

Ich werde mir die Cache-Geschichten mal anschauen und schauen, ob ich vielleicht noch das eine oder andere optimieren kann.

Ich schau mal in deinen Patch rein.

LG,
Helmut

[hschottm]

Hallo Georg,

also im Fall der Ergebnisse ist es wohl vollkommen unkritisch, getQuestionPosition überhaupt nicht mehr zu benutzen. Die gleiche Sortierung wird ja bereits in der übergeordneten Schleife verwendet, die alle Fragen auflistet. Hier reicht es also wirklich, einfach die Nummer hochzuzählen.

In ContentSurvey werde ich dann mal executeUncached einsetzen. Prinzipiell weiß ich ohnehin nicht, ob die Cache-Funktionen so viel bringen, da der MySQL-Server doch gleiche Abfragen intern auch cached und nicht noch mal komplett ausführt.

Gruß,
Helmut

[hschottm]

So,

eine aktualisierte Version steht im Extension Repository bereit. Ich hoffe, es gibt keine weiteren Cache-Probleme, ich konnte jedenfalls keine weiteren feststellen.

LG,
Helmut

[deerwood]

Hallo Helmut,

In ContentSurvey werde ich dann mal executeUncached einsetzen.

eine aktualisierte Version steht im Extension Repository bereit.

Vielen Dank, habe bisher nur das diff angesehen, aber es ist praktisch genau so, wie ich vorgeschlagen hatte ... allerdings war in meinem Vorschlag executeUncached() zu benutzen der Wurm: nun ist Build 47 nur noch 2.8.x kompatibel, weil es diese Methode in 2.7.x ja noch nicht gibt!

Lösungsidee: Verwendung von method_exists()? Andererseits hast Du das Statement dort geändert, so dass es nur noch die id holt, damit ist das Statement wahrscheinlich einzigartig und das Statement-Cache-Problem taucht dann auch mit execute() nicht auf. Aber irgendwie ist das blöd, mit dem Caching: jetzt muss man bei jedem Hinschreiben eines Statements erstmal prüfen, ob ein gleichlautendes mit den gleichen Parametern irgendwo schon verwendet wird und ähnliche Probleme hervorrufen könnte.

LG, Georg

[hschottm]

Hallo Georg,

oooh, stimmt. Ich hab ja ganz vergessen, dass die Version auch noch 2.7-kompatibel ist. Ich hab eine Abfrage eingeführt, damit sollte es jetzt auch unter 2.7 laufen.
Was den Cache angeht, so muss man das wirklich mal beobachten. Wenn das wirklich solche Seiteneffekte gibt, dann finde ich das gar nicht gut.

Liebe Grüße,
Helmut

[deerwood]

Moin Helmut,

danke für Deine Korrektur, funktioniert für mich wunderbar.

Und Du musst Dich sicher nicht für survey_ce entschuldigen! Im Gegenteil, ich habs ja bereits mehrfach gesagt: Deine Extension hat mir sehr geholfen. Und ich füge hinzu: sie war der Anlass, mich mit TYPOlight zu beschäftigen. Zum Thema Caching siehe auch hier. Und was meine/n Zeiten/Fleiss betrifft: ich lebe nur etwas "zeitverschoben" .

LG, Georg

[Sahel]

Hallo,
ich bastele gerade an einer Umfrage. Wie kann man denn alle Werte wieder auf Null setzen, nachdem eine Umfrage mal durchgelaufen ist? Also wie eine Umfrage von neuem starten?

Gruß,
Matthias

[deerwood]

Moin Sahel,

ich nehme an, dass Du nach einem Test im Frontend die Umfrage erneut im Backend bearbeiten möchtest? Ohne das ECHTE Teilnehmerdaten vorhanden sind? Nur Deine Testdaten?

Dann kannst Du einfach im Backend das "Männchen" Symbol (Teilnehmer der Umfrage ID 4711 bearbeiten) klicken und Du findest dann oben einen Link "Alle Teilnehmerdaten löschen". Nach Klick darauf ist die Umfrage wieder bearbeitbar.

Und, bevor Du eventuell weiterfragst, warum das so ist: "it is by intention", lies bitte die Doku zu survey_ce und alle Nachrichten in diesem Zweig des Forums von Beginn an.

LG, Georg

[Sahel]

Ok, vielen Dank für den Tip, Georg!
Ich habe schon alle Seiten hier quergelesen, aber übersehen, dass eine Doku gibt. Das alte Problem - lesen muss man können.

[Sahel]

Hallo,

gibt es irgendwo für survey_ce eine französische Dokumentation oder Anleitung? Auf typolight.fr und im dortigen Forum ist nichts zu finden.

Gruß,
Matthias

[flexx]

Hallo,

ich habe die Erweiterun Quickpoll installiert. Diese trifft aber nicht ganz meine Vorstellung.

Ich möchte Umfragen auf meiner Homepage durchführen, allerdings - und hier ist der entscheidende Punkt - soll nur dem Admin im Backend das Ergebnis präsentiert werden können.
Bei Quickpoll erscheint nach dem Abstimmen jedoch direkt eine Übersicht über die bereits abgegebenen Stimmen.
Hintergrund ist, dass zwar öffnetlich abgestimmt werden soll, jedoch die Konkurrenz das Ergebnis der Abstimmung nicht mitbekommen soll.

Ist soetwas über diese Erweiterung machbar oder gibt es eine andere Möglichkeit?

[deerwood]

Moin flexx,

... Quickpoll ... Umfragen ... soll nur dem Admin im Backend das Ergebnis präsentiert werden

Ich kenne Quickpoll nicht, aber [survey_ce] zeigt definitiv keinerlei Auswertung im Frontend (das wurde oben im Thread schon mal als fehlendes Feature erwähnt).

Die Auswertung von [survey_ce] ist nur im Backend zu sehen, dort hat man auch eine Excel-Export-Möglichkeit als Summary (und mit meiner alpha [surve_ce_ex], siehe weiter oben, auch einen detaillierten Export). Die Auswertungen sind allerdings nicht grafisch, das müsste man sich dann via Excel/OpenOffice selbst machen.

Da ich [survey_ce] bisher nur für eine richtig große, mehrseitige Umfrage (125 Fragen) benutzt habe, kann ich Dir nicht sagen, ob sie sich so "nahtlos" in die Seiten einbauen läßt, wie das bei Quickpoll zu sein scheint. Das müsstest Du selbst probieren ... und dann hier vielleicht auch berichten, ob und wie das geht?

LG, Georg

[hschottm]

Ich habe bewusst bislang nicht versucht, Quickpoll in das Umfragetool zu integrieren. Beides hat seine Berechtigung. Quickpoll ist mehr etwas, um mal schnell eine Meinung abzufragen und zu veröffentlichen, die Auswertung des Umfragewerkzeugs sehe ich persönlich halt eher im Backend angesiedelt. Im Normalfall exportiere ich mir die Daten und verarbeite sie in SPSS oder anderen Statistikwerkzeugen weiter, um die interessanten Kenngrößen zu errechnen.

Wenn du also etwas brauchst, das lediglich im Backend eine Auswertung zur Verfügung stellt, dann solltest du survey_ce mal ausprobieren.

LG,
Helmut