nicht angemeldet
Aufgabe in PHP
Hello,
ich drehe mich irgendwie im Kreise...
Die Aufgabe besteht darin, ein Gästebuch/Artikelkatalog/... zu programmieren, ohne die Verwendung von Sessions und ohne Datenbank.
Da auch Bildupload möglich sein soll, die Speicherung als HTML-File vorgeschrieben ist, und die Bilder nicht einfach gegrabbed werden können dürfen, ist das ganze schon recht komplex.
Zum Eintrag eines "Datensatzes" muss es eine Vorschau geben.
Außerdem soll später eine Möglichkeit bestehen, weitere Informationen zum Datansatz hinzuzufügen, den Datensatz zu löschen, zu sperren und ggf. zu ändern.
Hinzufügen von Informationen muss von jedem (berechtigten) User möglich sein, löschen und ändern nur von jeweils einem Admin.
Die so beliebten Funktionen include() und eval() sind verboten.
Nun seid Ihr dran, Eure Wetten abzugeben.
Lässt sich das System programmieren?
Eines der Grundprobleme ist z.B. die zeitliche Divergenz zwischen dem Bildupload und den verifizierten Daten.
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
-
Hi,
Nun seid Ihr dran, Eure Wetten abzugeben.
Lässt sich das System programmieren?ja. Warum auch nicht? Sowas war schon immer möglich, auch vor den Zeiten von PHP, und lange bevor Sessions, Datenbanken und Include-Funktionen "beliebt" wurden.
Eines der Grundprobleme ist z.B. die zeitliche Divergenz zwischen dem Bildupload und den verifizierten Daten.
Wie beschreibt sich dieses Grundproblem Deiner Ansicht nach?
Cheatah
--
X-Self-Code: sh:( fo:} ch:~ rl:° br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes-
Hello,
Eines der Grundprobleme ist z.B. die zeitliche Divergenz zwischen dem Bildupload und den verifizierten Daten.
Wie beschreibt sich dieses Grundproblem Deiner Ansicht nach?
ich erzeuge eine Uniqe-ID für die Daten und das Bild. Es kann aber nun passieren, dass das Bild unter Unique-ID (und ggf. Zusatz) gespeichert wird, weil es ok war, die Daten aber noch nicht OK waren und per Affenformular nochmal an den Client gehen. Die Referenz für das Bild muss aber auch mit zurück an den Client...
Anders herum könnten auch die Daten OK sein, aber das Bild ist z.B. zu groß, zu klein ...
Es soll für das Eintragen der Daten kein Authenticate notwendig sein.
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
-
Wer stellt denn sowelche perversen aufgaben?
Aber möglich müsste es sein.
Bei manchen Sachen steh ich zwar schon beim drüber nachdenken wie Ochs vorm Berg aber es wäre machbar... wenn auch mit hammermässigem gefrickel.ciao
-
Hello,
Wer stellt denn sowelche perversen aufgaben?
Leute, die sich über die ständige Rückentwicklung von hochgepuschten Systemen Gedanken machen.
Mit Sessions und Datenbank usw. wäre das sicher alles möglich.
Das System soll (nachher) aber auf ein minimalistes System zurückgeführt werden.Das heißt z.B., dass alle PHP-Funktionen nacher hardcoded werden und dann bleibt nur noch ein Executable übrig, das alles regelt, inclusive de Webserver-Funktionen.
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
-
-
hi,
ich erzeuge eine Uniqe-ID für die Daten und das Bild. Es kann aber nun passieren, dass das Bild unter Unique-ID (und ggf. Zusatz) gespeichert wird, weil es ok war, die Daten aber noch nicht OK waren und per Affenformular nochmal an den Client gehen. Die Referenz für das Bild muss aber auch mit zurück an den Client...
<input type="hidden" ...> ist dir bekannt?
gruß,
wahsaga--
/voodoo.css:
#GeorgeWBush { position:absolute; bottom:-6ft; }-
Hello,
ich erzeuge eine Uniqe-ID für die Daten und das Bild. Es kann aber nun passieren, dass das Bild unter Unique-ID (und ggf. Zusatz) gespeichert wird, weil es ok war, die Daten aber noch nicht OK waren und per Affenformular nochmal an den Client gehen. Die Referenz für das Bild muss aber auch mit zurück an den Client...
<input type="hidden" ...> ist dir bekannt?
Nein, was ist das?
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
-
Hi,
<input type="hidden" ...> ist dir bekannt?
Nein, was ist das?falls das witzig sein sollte: Bedaure, es fehlt die Pointe. Witzig wäre beispielsweise gewesen:
Nein, das hat sich bisher vor mir verborgen gehalten.
Cheatah
--
X-Self-Code: sh:( fo:} ch:~ rl:° br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes-
Hello,
Nein, das hat sich bisher vor mir verborgen gehalten, wie man mittels hidden-Field einen Wert beim User "durchschleifen" kann, ohne dass er ihn manipulieren kann.
Aber wahrscheinlich liegt das Geheimnis darin, diesen Wert so zu verschlüsseln, dass jede Manipulation auffällt.
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
-
Hallo Tom,
Nein, das hat sich bisher vor mir verborgen gehalten, wie man mittels hidden-Field einen Wert beim User "durchschleifen" kann, ohne dass er ihn manipulieren kann.
Ich verstehe Dich nicht. Das sind doch die Eingaben des Users - eine "Manipulation" ist also identisch mit einer Eingabe. Prüfen muß man die Eingaben doch eh nach jedem Request.
Gruß aus Berlin!
eddi-
Hello,
Nein, das hat sich bisher vor mir verborgen gehalten, wie man mittels hidden-Field einen Wert beim User "durchschleifen" kann, ohne dass er ihn manipulieren kann.
Ich verstehe Dich nicht. Das sind doch die Eingaben des Users - eine "Manipulation" ist also identisch mit einer Eingabe. Prüfen muß man die Eingaben doch eh nach jedem Request.
Nein, der User lädt ein Bild hoch und einige Textfelder. Das Bild wird dann unter einem Zufallsnamen ausreichender Länge auf der Platte gespeichert, der Text zusammen mit dem Bildlink wieder zur Vorschau ausgegeben. Wenn der jetzt einen Fehler hat (fehlende Felder, zu kurz, Spam-emails statt einer einzigen, usw), gibt es auch eine entsprechende Fehlermeldung.
Der User kann seine Fehler beseitigen. Den Namen des Bildes auf der Platte des Servers muss er aber unmanipuliert wieder mitsenden. Ich kann zwar prüfen, ob er einen gültigen Bildnamen benutzt hat, aber ich kann nicht prüfen, ob er sich einen Bildnamen von einem siener Vorgänger geklaut hat. Dass er einen errät, ist sehr unwahrscheinlich, da der Name aus $_SERVER['UNIQUE_ID'] (bzw. später einem ähnlichen Schlüssel) gebildet wird.
Er kann sich aber ansehen, was andere schon hochgeladen haben, und daher auch den Bildnamen der vorhandenen Einträge ermitteln.
Ich wollte erst Siechfreds Weg gehen, aber da das File-Feld nicht vorbelegbar ist, müsste der User bei jeder Korrektur am Text auch das Bild neu heraussuchen.
Man wird es wohl nur zweistufig machen können. Erst den Text hochladen, den abgesegneten Text mit dem Platzhalter für das Bild dann anzeigen und dann das Bild Hinterherschicken. Dafür benötigt man dann aber wieder eine Userauthentifikation.
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
-
Hello,
Nein, der User lädt ein Bild hoch und einige Textfelder. Das Bild wird dann unter einem Zufallsnamen ausreichender Länge auf der Platte gespeichert, der Text zusammen mit dem Bildlink wieder zur Vorschau ausgegeben. Wenn der jetzt einen Fehler hat (fehlende Felder, zu kurz, Spam-emails statt einer einzigen, usw), gibt es auch eine entsprechende Fehlermeldung.
Dann wäre es doch zumindest eine Überlegung wert, erst die Text der einzelnen Formularfelder dem User so lange vorzukauen, bis das Programm grünes Licht gibt. Erst danach wird dem User ein Hochladen von Bildern ermöglicht. Wie Du den Text derweil verstaust; ob mit JavaScript im window.name, dann erst ersatzweise in einem Cookie, dann erst ersatzweise mit einer serverseitigen Logik, ist doch auch nicht viel schlimmer, als eine DB dafür zu nehmen.
Im schlimmsten Fall wird es also immer auf eine serverseitige Technik hinauslaufen, wenn andere angebotene Möglichkeiten nicht vorhanden/nuzbar sind. Datein haben in einem Dateisystem doch auch Eigenschaften, die man nutzen kann. Wie Siechfred bereits andeutete, kann man mit dem Aufruf des Scripts bei jedem mal auch alle vorgehaltenen Datensätze auf ihre Erstellzeit mit filectime() prüfen, werden beispielsweise 2 h überschritten, wird dieser glöscht. Aus die Maus. Das ist ein System, was ich bspw. einsetze und was sich ohne Mucken bewährt hat.
Der User kann seine Fehler beseitigen. Den Namen des Bildes auf der Platte des Servers muss er aber unmanipuliert wieder mitsenden. Ich kann zwar prüfen, ob er einen gültigen Bildnamen benutzt hat, aber ich kann nicht prüfen, ob er sich einen Bildnamen von einem siener Vorgänger geklaut hat. Dass er einen errät, ist sehr unwahrscheinlich, da der Name aus $_SERVER['UNIQUE_ID'] (bzw. später einem ähnlichen Schlüssel) gebildet wird.
Lege Dir doch pro Datensatz ein (tmp)-Verzeichnis oder auch eine Datei mit einem eindeutigen Namen zu. Selbst wenn Du Bilder gleich beim ersten Versuch hochladen läßt, wird das verweiste Verzeichnis/die Datei alsbald gelöscht...
Er kann sich aber ansehen, was andere schon hochgeladen haben, und daher auch den Bildnamen der vorhandenen Einträge ermitteln.
Soll er doch. Ich sehe Dein Problem immer noch nicht; oder willst Du programmverifizierte Userdaten aus dem "Zwischenspeicher" der Formularvalidirung sofort online stellen? Ich glaube wohl nicht. Also wird doch auch ein Verschieben der Dat(ei)en voran gehen.
Ich wollte erst Siechfreds Weg gehen, aber da das File-Feld nicht vorbelegbar ist, müsste der User bei jeder Korrektur am Text auch das Bild neu heraussuchen.
Was für ein Datenmüll. Speichere zwischen und organisiere den Upload erst zum Schluß.
Man wird es wohl nur zweistufig machen können. Erst den Text hochladen, den abgesegneten Text mit dem Platzhalter für das Bild dann anzeigen und dann das Bild Hinterherschicken. Dafür benötigt man dann aber wieder eine Userauthentifikation.
Ach jetzt verstehe ich, worum es so sein soll. Aber dem steht immer noch nicht im Wege, die Bilder erst später nachzuladen. Das habe ich auch mal gemacht. Es ging dabei um eine "Onlineredaktion" von Beiträgen. Erst wurde der Test hochgeladen, dann wurde der Text in Sätze unterteilt. Zu jedem Satz wurde jeweils rechts und links ein Formularfeld zum hochladen später in den Text mit float einzubettender Bilder angeboten. Das wurde damals von den Usern genauso angenommen und hat reibungslos funktioniert.
Zur Authentifizierung hast Du Möglichkeiten genug mit PHP. Allerdings verstehe ich nicht, warum ausgerechnet der Server mit dem mod_unique_id belasten willst. Du hast doch schon PHP. Was willst Du jetzt den Server unnötig vollpacken? Ich dachte, der soll nicht alles, was das Leben erleichtern und unnötig ist, einbinden.
Gruß aus Berlin!
eddi
-
-
-
-
-
-
-
-
-
Nabend,
Die Aufgabe besteht darin, ein Gästebuch/Artikelkatalog/... zu programmieren, ohne die Verwendung von Sessions und ohne Datenbank.
:)))))
Hinzufügen von Informationen muss von jedem (berechtigten) User möglich sein, löschen und ändern nur von jeweils einem Admin.
Da wäre mein Ansatz Datensatz == Verzeichnis. Den Verzeichnisnamen würde ich in $OPTION.'_'.$TITEL unterteilen.
Mit den beispielhaften Werten (0|1|2) für $OPTION könntest Du festlegen, ob der Artikel angezeigt werden darf, verändert werden darf, nichts darf.Die so beliebten Funktionen include() und eval() sind verboten.
:) Dann gibt es für jeden Bereich ein zentrales Script, was über $_SERVER["PATH_INFO"] seine auszulesenden Pfade bekommt (Quasi-mod_rewrite).
Nun seid Ihr dran, Eure Wetten abzugeben.
Lässt sich das System programmieren?Tjo - hättest Du mich bei http://forum.de.selfhtml.org/archiv/2005/2/t100415/ nicht gänzlich hängen gelassen, sodaß ich es aufgegeben hatte, den Selbstunterhalter zu spielen, wäre alles fast schon fertig gewesen (wohlgemerkt ohne Session und Klimbim); nur noch anpassen. Natürlich läßt sich sowas machen.
Eines der Grundprobleme ist z.B. die zeitliche Divergenz zwischen dem Bildupload und den verifizierten Daten.
Was auch immer Du damit meinst, welche Erweiterungen PHPs stehen Dir zur Verfügung? Welches SAPI? Welcher Server (apache? mit welchen Modulen)?
Gruß aus Berlin!
eddi-
Hi eddi,
leider ist mein Thread vom Freitag (https://forum.selfhtml.org/?t=102670&m=631891) schon im Archiv, darum füge ich folgendes hier an:
Das war genau der Trick, den ich gebraucht habe!
Der Yeti
--
Habe nun, ach! WInfo, BWL, und Mathe, Und leider auch Info!
Durchaus studiert, mit heißem Bemühn. Da steh' ich nun, ich armer Thor!
Und bin so klug als wie zuvor!
sh:( fo:| ch:? rl:? br:< n4:& ie:( mo:| va:| de:[ zu:) fl:| ss:) ls:< js:|
[Link:http://community.de.selfhtml.org/fanprojekte/selfcode.htm]
-
-
ohne Datenbank.
SQLite geht auch nicht?
-
Hello,
SQLite geht auch nicht?
Nein.
Es soll nacher zusammen mit den Grundfunktionen eines Webservers compiliert werden.
PHP dient auch nur zur als Krücke. Alle Files sind daher als txt oder html vorgeschrieben.Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
-
-
Tag Tom.
Die Aufgabe besteht darin, ein Gästebuch/Artikelkatalog/... zu programmieren, ohne die Verwendung von Sessions und ohne Datenbank.
Pfui Spinne ... ;)
Zum Eintrag eines "Datensatzes" muss es eine Vorschau geben.
Bis hierher sollte das doch eigentlich kein Problem sein. Du brauchst doch eigentlich nur ein Affenformular und ein Eingabefeld für die Grafiken, die du für die Vorschaufunktion noch nicht mal hochladen, sondern nur um das file://-Protokoll ergänzen musst. Freilich sollte ein regelmäßiger Abgleich zwischen Einträgen und Bildern statt finden, um Datenleichen zu entsorgen.
Außerdem soll später eine Möglichkeit bestehen, weitere Informationen zum Datansatz hinzuzufügen, den Datensatz zu löschen, zu sperren und ggf. zu ändern. Hinzufügen von Informationen muss von jedem (berechtigten) User möglich sein, löschen und ändern nur von jeweils einem Admin.
Dann soll jeder User sich für seinen Eintrag ein persönliches Passwort festlegen, das du einfach vor Ausführen der Aktion (Ändern etc.) abfragst. Im Übrigen gibt es ein Admin-Passwort, das nur dem jeweiligen Verantwortlichen bekannt ist, und das einem die gewünschten Operationen erst möglich macht. Ein Verzeichnisschutz mittels htaccess wäre da keine schlechte Variante.
Siechfred
--
«Ich liebe euch doch alle!»-
Hello,
Dann soll jeder User sich für seinen Eintrag ein persönliches Passwort festlegen, das du einfach vor Ausführen der Aktion (Ändern etc.) abfragst. Im Übrigen gibt es ein Admin-Passwort, das nur dem jeweiligen Verantwortlichen bekannt ist, und das einem die gewünschten Operationen erst möglich macht. Ein Verzeichnisschutz mittels htaccess wäre da keine schlechte Variante.
Der Sinn ist inzwischen auch klar geworden. Das Endprodukt, dass bei der "Zwischenaktion" entsteht, muss mit reinen HTML-Funktionen (bestenfalls dann noch JavaScript, aber das möchte ich möglichst draußen lassen) bedienbar sein zur _Abfrage_ der Daten.
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
-
-
Moin!
ich drehe mich irgendwie im Kreise...
...ohne dabei aber viel Informationsgehalt wegzuschleudern...
Die Aufgabe besteht darin, ein Gästebuch/Artikelkatalog/... zu programmieren, ohne die Verwendung von Sessions und ohne Datenbank.
Ohne Datenbank - ok, da hast du höchstselbst ja schon mal eine Datenhaltung in Flatfiles erstellt.
Ohne Sessions - Grund und Ausprägung dieser Spezifikation wäre interessant? Wenn aufgrund des nicht sonderlich beleuchteten Nachbehandlungsvorhabens die PHP-Sessionfunktionen nicht erreichbar sind, dann könnte man trotzdem Sessions einsetzen, indem man die fehlende Funktionalität in PHP nachbaut. Die PHPLIB existiert.
Da auch Bildupload möglich sein soll, die Speicherung als HTML-File vorgeschrieben ist, und die Bilder nicht einfach gegrabbed werden können dürfen, ist das ganze schon recht komplex.
Was heißt "Speicherung als HTML-File"?
Die so beliebten Funktionen include() und eval() sind verboten.
eval() braucht man ja sowieso nicht. Und include() erleichtert einem ja nur das Leben, indem man multiples Copy&Paste vermeidet und Code an zentraler Stelle lagert. Ist auch nicht lebensnotwendig - entweder baut man einen Precompiler ein, der die includes() noch vor der Laufzeit expandiert, oder man hat einen Editor, der seinerseits Includes verarbeiten kann.
Nun seid Ihr dran, Eure Wetten abzugeben.
Lässt sich das System programmieren?Sehe noch keine unüberwindliche Schwierigkeit.
- Sven Rautenberg
-
Hello,
Ohne Datenbank - ok, da hast du höchstselbst ja schon mal eine Datenhaltung in Flatfiles erstellt.
Die kommt hier nicht in Frage, da es später ohne aktives Backend funktionieren muss.
Die Auflösung der Datenbestände muss also so stattfinden, dass sich das Ganze später (passiv) ausschließlich mit Browsertechnik betrachten lässt.Ohne Sessions - Grund und Ausprägung dieser Spezifikation wäre interessant? Wenn aufgrund des nicht sonderlich beleuchteten Nachbehandlungsvorhabens die PHP-Sessionfunktionen nicht erreichbar sind, dann könnte man trotzdem Sessions einsetzen, indem man die fehlende Funktionalität in PHP nachbaut. Die PHPLIB existiert.
Ich werde wohl aus Sicherheitsgründen nicht um eine Art Sessionmechanismus herumkommen. Lösung wäre noch das Daisychain der Daten in verschlüssleter Form durch die Bedienungsschritte des Users.
Was heißt "Speicherung als HTML-File"?
Die Datensätze sollen tatschlich in echten HTML-Seiten gespeichert werden.
Sehe noch keine unüberwindliche Schwierigkeit.
Das macht mir doch Mut.
Das Grundsystem läuft auch schon, hat aber leider noch ein ganz schön aktives Backend für die reine Abfrage der Informationen. Und genau das muss ich beseitigen.Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
-
Moin!
Die kommt hier nicht in Frage, da es später ohne aktives Backend funktionieren muss.
Du meinst, du sollst ein System erstellen, mit dem Leute zuerst diverse Inhalte eingeben können und das dann zu einem Stichpunkt "eingefroren" und als HTML-Seite generiert wird?
Oder ist im Endprodukt PHP doch irgendwie erlaubt?
Erzähl mehr!
- Sven Rautenberg
-
Hello,
Du meinst, du sollst ein System erstellen, mit dem Leute zuerst diverse Inhalte eingeben können und das dann zu einem Stichpunkt "eingefroren" und als HTML-Seite generiert wird?
So ist das.
Oder ist im Endprodukt PHP doch irgendwie erlaubt?
PHP ist im Endprodukt nicht mehr erlaubt.
Das Zwischenprodukt, also das System zur Erstellung des statischen Webauftrittes, soll möglichst auch als Executable aufgebaut werden inclusive eines 0815-Webservers. Aber soweit bin ich noch nicht. Darum sind aber auch eval() und include() verboten, da die ja die Funktionalität des Parsers benötigen. Alle "normalen" PHP-Funktionen lassen sich aber später leicht ersetzen.Es geht darum, dass das ganze Sytstem später ohne Fachkenntnisse zu installieren ist. Einfach ein executable auf die Platte spielen, eine Config-Datei einstellen und los geht es.
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
-
Moin!
Das Zwischenprodukt, also das System zur Erstellung des statischen Webauftrittes, soll möglichst auch als Executable aufgebaut werden inclusive eines 0815-Webservers. Aber soweit bin ich noch nicht. Darum sind aber auch eval() und include() verboten, da die ja die Funktionalität des Parsers benötigen. Alle "normalen" PHP-Funktionen lassen sich aber später leicht ersetzen.
Meinst du nicht, dass sich der Apache zusammen mit einer vollwertigen PHP- und MYSQL-Installation zusammen mit dem System in eine EXE packen läßt und auf Mausklick installiert? Die XAMPP-Installateure können das doch auch.
Es geht darum, dass das ganze Sytstem später ohne Fachkenntnisse zu installieren ist. Einfach ein executable auf die Platte spielen, eine Config-Datei einstellen und los geht es.
Das verbietet ja schon prinzipiell, auf anderen Schnittstellen als 127.0.0.1 aktiv werden zu dürfen. Wozu dann noch den Webserver? Einfach ein Windows-Programm schreiben, und gut ist. Da hat man auch von der Benutzerführung und der Eingabe mehr Möglichkeiten.
- Sven Rautenberg
-
Hi,
Du meinst, du sollst ein System erstellen, mit dem Leute zuerst diverse Inhalte eingeben können und das dann zu einem Stichpunkt "eingefroren" und als HTML-Seite generiert wird?
So ist das.
Aber so ganz ist das auch nocht nicht klar. So wie ich das verstanden habe, soll das eine lokale "Knowledge Base" werden. Ob das jetzt Wissen gesammelt wird oder nicht ist egal, das Stichwort ist "lokal". Das heißt für mich, das es im Single User Betrieb läuft. Wofür brauchst Du also das Multiuserzeug im Backend? Wenn das nämlich ebenfalls im Single User Betrieb läuft, brauchst Du da gar nichts, dann reicht Javascript (Theoretisch. Zumindest so lange nur theoretisch bis ich mit meinem PoC fertig bin, aber das dauert wenn dauernd das Telephon geht ;-)
Es geht darum, dass das ganze Sytstem später ohne Fachkenntnisse zu installieren ist. Einfach ein executable auf die Platte spielen, eine Config-Datei einstellen und los geht es.
"Config Datei einstellen" ist schon hohe Kunst, das ist für den gemeinen User nicht mehr als "einfach" ansehbar. Mehr als Name und Anschrift kannst Du da nicht verlangen. Und selbst diese Maske würde ich noch dreimal gegen /dev/random auf Fehlertoleranz prüfen >;->
Aber wie Sven schon so treffend anmerkte: die Leute von WAMP sind wirklich gut, da brauchst Du nur noch den Installer auf Deine Zwecke hin anzupassen. Allerdings ist das natürlich auch 'ne Menge Holz, klar, aber am wichtigsten: Du hast einen Dienst laufen, der normalerweise nicht benötigt wird. Vor allem bei Windows ein nicht zu unterschätzendes Risiko! Aber Du woltest ja eh einen Webserver benutzen und da ist vor jedem Selberbasteln ein Apache vorzuziehen.
Also: nimm WAMP und steck die ganze Energie, die Du sonst in das Erstellen eines komplett eigenen Programmes stecken müßtest (was im Endeffekt dann auch wieder nur ein abgespecktes WAMP wäre) in die Absicherung, Installation und die paar Zeilen PHP, die Du für die Funktion noch benötigst (Dafür sollte es aber auch schon einige fertige Lösungen geben).
Außerdem hältst Du Dich so auch an die Devise:"Keep it simple, Dude!" ;-)so short
Christoph Zurnieden
-
Hallo Tom,
beiläufig habe ich mich mal mit GTK beschäftigt. Das soll auch plattformübergreifend laufen. Wäre es vielleicht eine Überlegung wert genau den anderen Weg zu gehen: Den Server entbehrlich zu machen und statt diesem nur mit PHP auszukommen? Somit wäre SQlite und andere Annhemlichkeiten PHPs wieder im Rennen.
Gruß aus Berlin!
eddi
-
-