Die Rückkehr der IFrames ?

[Aiun]

hi,

ich habe mich in den letzten Wochen verstärkt mit Javascript-Frameworks beschäftigt, dabei tauchen immer wieder die schönen 'Lightbox'es für Bilder auf, aber mitlerweile auch Win/Gnome/KDE/OS ähnliche Fenster-Libs, die erlauben mehrere Elemente einer Webseite zu verschieben, resizen wie Betriebssystem-Fenster.

Bisher verwenden alle die ich gesehen habe IFrames um in diesen Fenstern alles darzustellen.

Lange zeit waren IFrames verpönt, aber in dem Sinne ist der einsatz gar nicht schlecht!

was haltet ihr von sowas ?, jemand Erfahrung mit der Browser-Kompatibilität gemacht ?

ich überlege eines dieser Systeme für den Administrationsbereich eines CMS einzusetzen. Somit erhält der Administrator die möglichkeit Inhalt zu pflegen, Dateien hochzuladen und z.B. Benutzer zu verwalten zugleich. Andererseits ist es im Prinzip nichts weiter als Tabs oder mehrere Browserfenster.

( obgleich ich mir vorstellen kann das diese IFrames im gleichen Fenster miteinander Kommunizieren können )

Meinungen auch hierzu ?

[geloescht_JesterDay]

... dabei tauchen immer wieder die schönen 'Lightbox'es für Bilder auf, aber mitlerweile auch Win/Gnome/KDE/OS ähnliche Fenster-Libs, die erlauben mehrere Elemente einer Webseite zu verschieben, resizen wie Betriebssystem-Fenster.

Bisher verwenden alle die ich gesehen habe IFrames um in diesen Fenstern alles darzustellen.

Ich hab mich nicht so ausführlich damit beschäftigt. Ich habe aber mal script.aculo.us verwendet, womit man auch Elemente per Maus im Browser verschieben kann. Ich habe damit selbst mal eine kleine Fensteroberfläche gebastelt für eine kleine Anwendung, das waren aber alles Divs.

Ok, vielleicht bieten die von dir getesteten das mitlerweile etwas ausgereifter an Aber zwingend notwendig ist das AFAIK nicht.

Was ich mir noch vorstellen könnte wäre, dass es durch einen IFrame unabhängiger von Rest des Dokuments ist, also praktisch wirklich über dem schwebt.

Vielleicht ist es dadurch auch einfacher verschiedene Elemente anzuzeigen, da ein (Inline)Frame ja eigentlich dafür da ist im Dokument andere Dokumente anzuzeigen. Dadurch ist es vielleicht unkomplizierter zu programmieren.

Ich bin, ohne mich jetzt groß damit beschäftigt zu haben, der Meinung, solange das sozusagen als Bonus funktioniert (wie z.B. im Adminbereich) ist dagegen nichts zu sagen.

[Aiun]

das, was ich im moment teste ist als Version 0.8 gekennzeichnet, aber schon sehr ausgereift. Ich hab es jetzt mal testweise eingebaut.

Verwendet JS-Canvas (mit IE unterstützung !) für die Fenster und Iframes für den Inhalt.

Mal schauen was aus dem Test wird.

[Toothrot]

was haltet ihr von sowas ?, jemand Erfahrung mit der Browser-Kompatibilität gemacht ?

Wie wär's denn mit ein paar Links?

[Aiun]

Mootools Mocha UI

Es gibt noch andere, aber das ist was ich derzeit teste.

[Guybrush Threepwood]

Wenns dir nur ums Verschieben geht brauchst du dazu keinen IFrame, das geht wunderbar ohne. Mit IFrame ist das Ganze glaub ich sogar komplizierter.

Wofür der IFrame aber praktisch ist, ist wenn deine Seite schon sehr groß ist und du Fenster bzw. Popups nicht schon direkt beim Seiten laden mitladen willst sondern erst wenn sie geöffnet werden um am Anfang Zeit zu sparen...

[Toothrot]

Nette Spielerei. Mir ist eine "schlichte" Seite aus (X)HTML und CSS persönlich lieber. Desktop-Simulation im Browser halte ich für vollkommen unnötig. Ich gucke mir sowas an, denke mir, "Wahnsinn, was man mit JS nicht alles machen kann!" und verlasse die Seite wieder. Bezüglich Browserkompatibilität kann ich dir nur sagen, dass es im IE6 zwar funktioniert, aber bescheiden aussieht.

Edit: Die IFrames werden dort nur genutzt, um externe Inhalte anzuzeigen. (Youtube, etc)

[Aiun]

ihr habt mich nicht verstanden ^^

es geht darum soetwas im Admin-Bereich von Anwendungen einzusetzen, nicht in einer Website an sich.

Desktop-Versuche als Website ist quatsch, aber deswegen frage ich ja euch eine 2. Meinung ob und wo soetwas sinn macht.

Die IFrames haben hier den Vorteil das einige Seiten auch Inhalte hochladen können (Full Site Form-Submit) während andere nicht neu geladen werden (Ajax, partial replace)

[.vash]

Hi,

ich halte persönlich von dem Thema nicht soo viel, auch wenn es cool ist, weil es irgendwie den Anwendungsbereich des Webs verfehlt (und man so tolle Sachen ja auch viel einfacher erstellen könnte als für Webbrowser), aber das ist einfach der Wandel der Zeit. Der Kunde will es so haben also kriegt er es auch. Gerade weil Deployment von FatClients oft wegen Sicherheitsbedenken oder umfangreichen Strukturen kompliziert ist, ist das Web sehr beliebt um alle möglichen Sachen auch mit Hilfe eines Browsers zu lösen.

Zum Thema Crossbrowser

Da kann ich nur für Mootools 1.1 sprechen. Ich sag mal so: 80% laufen problemlos, 19% laufen in diversen Browsern deshalb anders weil sie ihre interne Logik anders handeln, Standards missachten, oder Standards nutzen die aber noch nicht offiziell supported werden (Beispiel select, opacity, ...) das ist aber nicht das Problem von Mootools, 1% sind Bugs. Soweit denke ich es ist brauchbar - ich würde versuchen mit dem Kunden einen Browser als Zielplattform zu vereinbaren die dann verbindlich genutzt wird. Macht das Testen/Debuggen/entwickeln einfacher.

Zum Thema Iframes

Klar warum nicht. Der Grund für Iframes liegt meiner Vermutung an der Speicherverwaltung von Javascript und des Browsers. Habe ich einzelne Inhalte in Iframes verpackt dann werde ich den ganzen Overhead los wenn diese geunloadet werden. Ansonsten kommt es zu langen wartezeiten bei einem regulären Postback oder der Speicher wird zugemüllt, was wiederum langfristig für Bowserinstabilität sorgt.

[Aiun]

he he,

Stand der Dinge ist, das es sich in meinen tests nicht bewährt hat.

Für vollständige Dialoge (Listen, Formulare) ist zu wenig Platz in einem Fenster. Gebe ich dem Fenster eine Art "Vollbild", hat es seinen sinn verloren und ich bin eh im ganzen Browserfenster.

Eine lösung wäre, die Inhalte für 'kleine' Darstellungsbereiche zu optimieren, aber da tendiere ich lieber zu einer Widget-Lösung, die Ein Gitter vorgibt in dem Inhalte platziert werden können.

[.vash]

Damit bringst Du es auf den Punkt. Man kann im Prinzip jedes "Fenster" auch gleich in einem eigenen richtigem BrowserFenster darstellen. Dann hat man weniger Probleme mit Javascript, Crossbrowser und Darstellungsproblemen.

Hast Du im Rahmen Deiner Tests eigentlich auch mal http://qooxdoo.org/ ausprobiert?

[Lordwampe]

ich überlege eines dieser Systeme für den Administrationsbereich eines CMS einzusetzen. Somit erhält der Administrator die möglichkeit Inhalt zu pflegen, Dateien hochzuladen und z.B. Benutzer zu verwalten zugleich. Andererseits ist es im Prinzip nichts weiter als Tabs oder mehrere Browserfenster.

( obgleich ich mir vorstellen kann das diese IFrames im gleichen Fenster miteinander Kommunizieren können )

Meinungen auch hierzu ?

IFrames sind so eine sache, jeder IFrame bekommt Systemweit eine interne ID (nicht den Fensternamen!) über den man ihn (zumindest unter windows) adressieren kann. Was wenn man z.B. weiß das sein Ziel Iframes in einer Seite hat die er häufig benutzt e.g. ein Admintool ideal als sicherheitslücke ausnutzen kann. Daher würde ich Iframes wenn überhaupt nur an stellen einsetzen an denen nicht durch den Selben Browser (Browser, nicht Browsertab oder INSTANZ sondern System weit Browser!) Zwangsläufig sicherheitskritische Informationen übertragen werden.

[Aiun]

was genau meinst du ?

Cross-Domain Sperren verhindern Manipulationen von Frames, oder sprichst du von lokalen anwendungen die den Browser beeinflussen ?

bei letzterem glaube ich nicht das es einen unterschied macht ob IFrames oder nicht.

@vash, nein. Aber gut zu wissen.

[.vash]

bei letzterem glaube ich nicht das es einen unterschied macht ob IFrames oder nicht.

Glaub ich auch, weil in dem Fall hat man wahrscheinlich einfachere Möglichkeiten sein Ziel zu erreichen. Darüberhinaus: Wenn ich die Speicheradresse kenne, ist grundsätzlich jede Information offen für mich.

[kills]

Ich kann nur Ext - A foundation you can build on empfehlen. Das ist schon ein mehr oder weniger "fertiges" Fenstersystem. Gibts viele "High-Level"-Widgets.

In Verbindung mit ADOBE AIR auch als offline App sehr nett.

[Aiun]

jop, aber hast du dir die Lizenz durchgelesen ? "GPL".

Heißt, (soweit ich weis) alle Erweiterungen die du dazu entwickelst müssen auch GPL sein. Verwendest du es in einer Anwendung, ist die große Frage wo in der Anwendung die GPL endet... - mir bisher ein zu großes Risiko.

[Guybrush Threepwood]

Das endet genau da wo du nichts an der ExtJs Library selber änderst

[Aiun]

habe gerade nochmal in die GPL geschaut, ich kann nicht klar ausmachen wo die Grenze zwischen "erweitern" und "verwenden" ist. Also wenn ich eine Webseite mit ExtJS gestalte (oder eine Web-Anwendung z.B. aus Extjs, anderem JS, php und html etc.)

Wenn ich andere JS-Bibliotheken mit Extjs verbinde, in dem ich funktionen habe die beide verwenden wirds noch heikler.

Oder hat jemand ein Beispiel-Urteil, FAQ o.ä. in dem das genauer erläutert wird ?

Die Anwendung ist ja später darauf angewiesen und extjs-Code wird aktiv in evtl. hunderten html-Dokumenten verwendet.

Mir fehlen da schlicht die Quellen, wie das zu interpretieren ist.

[geloescht_JesterDay]

habe gerade nochmal in die GPL geschaut, ich kann nicht klar ausmachen wo die Grenze zwischen "erweitern" und "verwenden" ist. Also wenn ich eine Webseite mit ExtJS gestalte (oder eine Web-Anwendung z.B. aus Extjs, anderem JS, php und html etc.)

Wenn du eine Webseite damit machst bedeutet die GPL für dich gar nichts. Typo3 ist auch unter der GPL veröffentlicht und deswegen wurde noch keiner verklagt der es für seine Seite nutzt

Außerdem wird auf deren HP doch "alles" geklärt:

Commercial License

This is the appropriate option if you are creating proprietary applications and you are not prepared to distribute and share the source code of your application under the GPL.

...

Open Source License

Ext JS is an avid supportor of open source software. This is the appropriate option if you are creating an open source application with a license compatible with the GNU GPL license v3.

...

OEM / Reseller License

This is the appropriate option if you are creating a product that is a software development library, toolkit or framework. There are many benefits to partnering with us:

Nachtrag:

Weiteres wird auch hier geklärt (allerdings nicht alles (alle Lnks) gelesen):

http://extjs.com/products/license-faq.php

Bearbeitet 18. Juni 2008 von JesterDay

[geloescht_JesterDay]

Verwendest du es in einer Anwendung, ist die große Frage wo in der Anwendung die GPL endet... - mir bisher ein zu großes Risiko.

Frag mich woher da die große Angst kommt?

Solange es GPL ist, endet die in deiner Anwendung gar nicht. Dafür gibt es die LPGL.

Aber daß heißt ja nicht, dass du deine Anwendung verschenken musst. Allerdings darf derjenige der sie dir abkauft sie dann auch weitergeben, auch umsonst.

[Aiun]

Wenn du eine Webseite damit machst bedeutet die GPL für dich gar nichts. Typo3 ist auch unter der GPL veröffentlicht und deswegen wurde noch keiner verklagt der es für seine Seite nutzt

he he darum gehts mir auch nicht. Aber wenn ich eigenen JS Code einbinde, der nunmal nicht unter GPL stehen soll, die gesamte Webanwendung auch nicht, obwohl ExtJS letztlich ein unverzichtbarer Teil würde. Und da ist mir die Abgrenzung der GPL nicht klar (und das nicht nur bezogen auf extjs ^^)

Meine Webseite macht mir keine Sorgen, es geht um Anwendungen die lizenziert/verkauft werden und Extjs evtl. nutzen würden.

einige andere Leute/Kollegen haben sich schon gewundert wie typo-Plugins nicht GPL sein müssen, obwohl typo GPL ist - mir scheint ich bin nicht der einzige mit dem Problem ^^

This is the appropriate option if you are creating proprietary applications and you are not prepared to distribute and share the source code of your application under the GPL.

...

Open Source License

Ext JS is an avid supportor of open source software. This is the appropriate option if you are creating an open source application with a license compatible with the GNU GPL license v3.

genau das meine ich ich verstehe es so das wenn extjs in die Anwendung einfließt, es auch GPL sein muss. Und das würde dann auch für Plugins der Anwendung gelten. Dann binde ich eine MIT oder BSD-Lizenz Bibliothek ein und niemand weis mehr was nu gilt.

[geloescht_JesterDay]

he he darum gehts mir auch nicht. Aber wenn ich eigenen JS Code einbinde, der nunmal nicht unter GPL stehen soll, die gesamte Webanwendung auch nicht, obwohl ExtJS letztlich ein unverzichtbarer Teil würde. Und da ist mir die Abgrenzung der GPL nicht klar (und das nicht nur bezogen auf extjs ^^)

Meine Webseite macht mir keine Sorgen, es geht um Anwendungen die lizenziert/verkauft werden und Extjs evtl. nutzen würden.

einige andere Leute/Kollegen haben sich schon gewundert wie typo-Plugins nicht GPL sein müssen, obwohl typo GPL ist - mir scheint ich bin nicht der einzige mit dem Problem ^^

Müssen sie das nicht?

Bearbeitet 18. Juni 2008 von JesterDay

[Aiun]

jop ^^ und somit die Begründung warum ich extjs nicht so prickelnd finde

(nicht falsch verstehen, ich gebe auch sourcen zum Download frei)

Nachtrag:

hab gerade nochmal nachgesehen, es gibt typo-Extensions mit dem Verweis "unter creative commons CC-BY-SA, bei kommerzieller nutzung den Autor kontaktieren" die laut deiner liste oben definitiv nicht GPL kompatibel ist.

Was für ein Chaos ^^

Bearbeitet 18. Juni 2008 von Aiun

[geloescht_JesterDay]

(nicht falsch verstehen, ich gebe auch sourcen zum Download frei)

Jeder wie er will, sollte ja kein Vorwurf sein.

[Aiun]

kennt einer von euch ein JS-script (optimaler weise auf mootools basis)

das die Einteilung in Spalten oder Zeilen erlaubt, die ich in Breite/höhe verschieben kann (wie mann das von Datei-Explorern kennt) ?

Ich bin dabei selbst eins zu schreiben, aber will ja nicht 'schon wieder' das rad neu erfinden

p.S. ein 'nicht GPL' script ^^