Hello Matthias,
Warum sollte ich es dir übel nehmen, dass du Lehrer bist? Ich frage ja hier im Forum, WEIL ich etwas lernen will. Aber dazu sollte ich auch verstehen, was du mir mitteilen willst ... und das fällt mir bei diesem Satz sehr schwer:
Dass Du denkst, dass es einfacher ist, Deine Frames zu modernisieren, als beide Frames in ein HTML-Dokument zu stecken und dann nicht mehr normale Features von HTML mit JavaScript nachbauen zu müssen.
Wir können nur raten, wie es genau bei Dir aussieht. Manchmal hat man etwas aus vergangenen Threads im Hinterkopf:
Noch mal: das ist ein privates Bastelprojekt das auf einem Raspi läuft für das ich Frames brauche;
Die Arbeit mit den Mikrocontrollern ist spannend und wir haben da einige interne Baustellen und gleich neben dir sogar einen Jobauftrag:
Dein Problem scheinen ja aber wohl die Frames zu sein. Ich hatte in den letzten Jahren einigen Kontakt mit Leuten, deren Webseite zumindest auf Chrome irgendwann „nicht mehr ging“. @Rolf B hatte schon die Begriffe Same-Origin (im Wiki: Same-Origin-Policy) verwendet.
In den letzten Jahren haben die Browser die Sicherheitsstandards bei JavaScript, aber auch anderen Technologien so hochgeschraubt, dass die Browser es erschweren, andere Webseiten auszulesen. Deshalb ist das von Rolf erwähnte lokale Testen ohne Server z.B. bei eingebundenen Schriften gar nicht mehr möglich. Fazit: Man muss eigentlich immer gleich einen eigenen Server haben. (Wie das geht wird in Kap 2 und 3 in unserem Webserver-Bereich beschrieben. Ein Bereich zu Raspberry ist in Arbeit!)
Jetzt zu Deinem konkreten Problem:
mit welcher Art von Link / JavaScript-Anweisung / PHP-Code kann ich diesen frame[0] 'vergrößern' auf das (volle) Browser-Fenster ohne diese Seite (neu) zu laden (denn dann sind die eingetragenen Daten natürlich weg) .
parent.frames[0].resizeTo(screen.availWidth,screen.availHeight);
Antwort: Eine „normale“ Webseite nimmt eben „das (volle) Browser-Fenster“ ein und eine Änderung des Viewports (Handy wird um 90° gedreht; Seite wird gezoomt, Desktop-Monitor wird geteilt) sorgt für eine automatische Anpassung ohne weiteres CSS „ohne diese Seite (neu) zu laden (denn dann sind die eingetragenen Daten natürlich weg)“.
Mit CSS (wie dem von Rolf erwähnten grid) könnte man dann Tabellen und Diagramme nebeneinander anstatt untereinander anordnen.
In Deinem Ansatz musst Du erst einmal mit Javascript Breite und Höhe des Bildschirms auslesen um dann deinen Frame mit resize anzupassen. wenn Du das gelöst hast, wirst Du bald das nächste problem mit frames bekommen.
Was hier aber völlig fehlt ist die Frage, welche Daten von wo kommen. Das wäre noch interessant!
Ich möchte meine Frames nicht 'modernisieren' und auch nicht den LocalStorage von HTML5 oder Frameworks oder PHP nutzen, sondern ganz bewußt und absichtlich diese Uralt-Technik (Frameset) für ein Spiel- und Bastelprojekt nutzen, gerade weil ich es interessant finde, eben ohne Datenbank und oben genanntes, Daten zu 'verarbeiten'.
Ja, da stößt du aber immer wieder auf Probleme und Herausforderungen, die du sonst nicht hättest.
@TS und ich wollten den Raspberry-Bereich mit mehreren Tutorials irgendwann mal zur Veröffentlichung bringen. Evtl. ist dass der Anstoß, da mal wieder weiterzumachen![1]
Stimmt. Ich hadere schon seit Wochen, mich endlich wieder an den passenden Schreibtisch zu setzen und die gesammelten Toolboxen und Tutorials mal zu sortieren und auszuwerten.
Und dann gehe ich doch immer erst wieder raus, um meine Solar-Testanlagen vom Saharastaub zu säubern :-O
Aber nun kehrt ja der Winter so langsam ein (Nachts schon knapp über der Frostgrenze) und da lohnt sich das Putzen nicht mehr so sehr. Außerdem hat es die letzten 14 Tage hier oben immer wieder geregnet. Meine Wassertonne ist dauerhaft voll.
Die Himbeere kann sich also schon mal in Startposition bewegen.
Glück Auf
Tom vom Berg
Für alle Webdesign-Puristen: Es geht nicht drum im SELF-Wiki das Löten und Basteln neu einzuführen, sondern die Schnittstellen zwischen Webdesign, Server und Raspberry und Datenvisualsierung aufzuzeigen. ↩︎