DIV poistion Verschieben

Ich möchte den Usern ermöglichen auf der Benutzeroberfläche DIV-Layer zu verschieben. Allerdings soll bei einem neu Besuch diese Layers auf der gleichen Position sein. Nunja an sich kein Problem per Javascript & Cookies
Aber wie mach Ich das verschieben?
Hab da so ne Blockade in der hinsicht.

SO nach ein bissl rumsuchen bei google (ja ich weiss gidf.de)
bin ich hierrauf gestoßen

var objDrag = null; // Element, über dem Maus bewegt wurde
var mouseX = 0; // X-Koordinate der Maus
var mouseY = 0; // Y-Koordinate der Maus
var offX = 0; // X-Offset der Maus zur linken oberen Ecke des Elements
var offY = 0; // Y-Offset der Maus zur linken oberen Ecke des Elements
// Browserweiche
IE = document.all&&!window.opera;
DOM = document.getElementById&&!IE;
// Initialisierungs-Funktion
function init(){
// Initialisierung der Überwachung der Events
document.onmousemove = doDrag; // Bei Mausbewegung die Fkt. doDrag aufrufen
document.onmouseup = stopDrag; // Bei Loslassen der Maustaste die Fkt. stopDrag aufrufen
}
// Wird aufgerufen, wenn die Maus über einer Box gedrückt wird
function startDrag(objElem) {
// Objekt der globalen Variabel zuweisen -> hierdurch wird Bewegung möglich
objDrag = objElem;
// Offsets im zu bewegenden Element ermitteln
offX = mouseX - objDrag.offsetLeft;
offY = mouseY - objDrag.offsetTop;
}
// Wird ausgeführt, wenn die Maus bewegt wird
function doDrag(ereignis) {
// Aktuelle Mauskoordinaten bei Mausbewegung ermitteln
mouseX = (IE) ? window.event.clientX : ereignis.pageX;
mouseY = (IE) ? window.event.clientY : ereignis.pageY;
// Wurde die Maus über einem Element gedrück, erfolgt eine Bewegung
if (objDrag != null) {
// Element neue Koordinaten zuweisen
objDrag.style.left = (mouseX - offX) + "px";
objDrag.style.top = (mouseY - offY) + "px";
// Position in Statusleiste ausgeben
window.status = "Box-Position: " + objDrag.style.left + ", " + objDrag.style.top;
}
}
// Wird ausgeführt, wenn die Maustaste losgelassen wird
function stopDrag(ereignis) {
// Objekt löschen -> beim Bewegen der Maus wird Element nicht mehr verschoben
objDrag = null;
}
Quelle: www.quaese.de/HTML-Design/texte/js/scripts/drag_and_drop/drag_and_drop.html
Falls jemand ebenfalls sowas sucht.

mootools, Prototype/script.aculo.us, jquery, dojo - such dir was aus, geht ueberall mit minimalem Aufwand und steht ausfuehrlich und detailliert in der jeweiligen Dokumentation...

Ich würde script.aculo.us/ nehmen. Ist ein Super Framework in meinen Augen. Basiert auf prototypejs.org/ - habe mit beidem schon selbst viel und gute Erfahrungen gemacht.
Viel Spaß!
Marc

Naja, generell ist es eher so, dass die meisten erfahrenen Entwickler Prototype ziemlich verteufeln, weil es wohl so geschrieben ist, dass es zu Inkompatiblitaeten zu anderen Javascript Toolkits / Anwendungen kommen kann, es bloated / zu gross ist und die Doku recht mies sein soll.
Aber das ist auch nur, was ich so nebenbei mitbekommen habe, selbst noch keine wirklichen Erfahrungen in der Richtung gemacht.

prototype ist super dokumentiert. .. nur bei scriptaculous darf man sich durch die wiki wühlen .. irgendwo steht es, ja. aber man findet es nicht gut/schnell.

Ich selber benutze mootools. Wenn du noch etwas wartest, ist die Version 1.2 fertig
Dann ist auch eine neue verbesserte Dokumentation online, und natürlich neue Beispiele.

Keine Ahnung, zu welchen Tools prototype alles inkompatibel sein soll. Ich denke dass die meinsten Anforderungen, die man an solch ein low-level Framework haben kann erfüllt werden. Wer da irgendwelche Scripte benutzt, die das Rad neben Prototype nochmal neu erfinden ist selbst schuld.
Die netten Features kommen eh durch die zahlreichen darauf basierenden Scripts, wobei ich da JQuery im Vorteil sehe, denn die Anzahl an Scripten ist riesig. Leider kann ich nichts über deren Qualität sagen, da ich noch nicht damit gearbeitet habe. Ich sehe da immer nur die Zahlen in der TagWolke von ajaxrain.com (mooTools ist da etwas abgeschlagen, aber Quantität sagt ja nix über Qualität aus).
Ok, bevor ichs vergesse... JQuery funktionert sehr gut mit Prototype zusammen. Einzig der $ Operator muss in JQuery per Konfiguration getauscht werden (und dann auch successive in den auf JQUery basierenden Scripten, was nun nicht grade aufwendig ist).
Falls euch die Grösse eurer Seiten egal ist (und das sollte in BGs eigentlich der Fall sein) und ihr aus einer möglichst grossen Anzahl an Scripten auswählen wollt, dann versuchts doch mal.
So long...
Mr.Maxx

Original von Kallisti
Naja, generell ist es eher so, dass die meisten erfahrenen Entwickler Prototype ziemlich verteufeln, weil es wohl so geschrieben ist, dass es zu Inkompatiblitaeten zu anderen Javascript Toolkits / Anwendungen kommen kann

Wer mehr als ein JS-Framework nutzt gehört sowieso geschlagen.

Original von Drezil

prototype ist super dokumentiert. .. nur bei scriptaculous darf man sich durch die wiki wühlen .. irgendwo steht es, ja. aber man findet es nicht gut/schnell.
Hehe. Mir geht's genau umgekehrt. Bei Scriptaculous find ich im Wiki alles im recht schnell, aber an der Doku von Prototype bin ich teilweise ewig am suchen.

War klar, dass die, die Prototype nutzen, nun gegensprechen. ;-)
Es gibt viele Gruende fuer mehr Javascript, muss ja nicht unbedingt ein komplettes zweites Framework sein, das ist natuerlich recht sinnfrei, aber wenn ich mir Dinge wie ExtJs (fuer mootools oder dojo gibt es keinen Adapter), Jemplate oder Apis wie google maps ansehe, kommt es auch bei so was gern zu Kollisionen.
Aber klar, ist nur mein subjektiver Eindruck, den ich durch das idlen in div. Channels auf irc.perl.org aufgeschnappt habe. ;-) Gibt da ne Menge Web Developer, die Prototype ziemlich verfluchen.
Die Sache mit der Doku ruehrt wahrscheinlich primaer daher, dass es erst seit 1.5 ueberhaupt eine Form von offizieller Doku gibt und diese vorher gar nicht existent war. Die Leute, die das kritisieren sind wahrscheinlich vorher schon abgesprungen und zu jQuery gewechselt, was wohl derzeit die vielversprechendste Alternative zu sein scheint - sowohl in Sachen Performance, als auch Erweiterungen.
PS: <3 Safari dafuer, dass er trotz "ungueltigen Verweises" meinen Text nach Betaetigen des zurueck Buttons behalten hat.

Drag&Drop ist wirklich mit paar Zeilen schnell selbst geschrieben.
Ich versteh nicht, warum man für jeden Pups gleich ein ganzes Framework nehmen muss.

Naja sauberes Drag&Drop mit Crossbrowser-Kompatiblitaet ist nicht in 2 Zeilen selbst geschrieben. Vor allem nicht, wenn es komplexer werden soll (und zumeist soll es das ^^), z.B. mit dropables, clipping und dergleichen.

Original von Kallisti
(fuer mootools [...] gibt es keinen Adapter)

Das ist mein Stichwort: og5.net/christoph/?cat=articles
Ich habe ihn vor ein paar Tagen veröffentlicht, er wird in einiger Zeit auch offiziell in Ext aufgenommen.

Original von Kallisti
Naja sauberes Drag&Drop mit Crossbrowser-Kompatiblitaet ist nicht in 2 Zeilen selbst geschrieben. Vor allem nicht, wenn es komplexer werden soll (und zumeist soll es das ^^), z.B. mit dropables, clipping und dergleichen.

keine 2 zeilen
aber man braucht trotzdem nicht mehrere frameworks
ich habe mir da etwas schönes mit scriptaculous gebaut und es ging echt wunderschön

Ich habe auch nirgends behauptet man braeuchte mehrere Frameworks fuer das drag&drop?! Aber vielleicht irgendwann fuer eine andere Funktion auf der webseite.
Einfaches Beispiel:
aquaphobia.de/frontend/map.html
Man verzeihe mir die uebelst haesslichen Grafiken und den haesslichen Code, hab ich vor zig Monaten nebenbei hingeklatscht, mehr als proof of concept, damals auch auf die schnelle mit script.aculo.us (weil ich mir nicht sonderlich Gedanken darueber gemacht habe und die Alternativen teils gar nicht kannte). Klappt auch wunderbar (es laggt wegen der SVG routen, die muesste man beim dragstart invisible setzen und beim dragend erst wieder anzeigen).
Allerdings soll da noch google maps Funktionalitaet also scrolling mit background tiles Nachladen und zooming dazu und vielleicht eine elegantere Implementation der SVG routen... Und je mehr features man eben noch braucht, umso riskanter wird es, dass es Kollisionen gibt. ;-)
Btw, wenn jemand Infos ueber google maps artige Maps mit scrolling und zooming hat (abseits von OpenLayers), bitte raus damit, kann ich sicher verwerten.
Zum Glueck ist mir javascript fuer die naechsten 1-2 Jahre erst einmal relativ egal und ich muss zunaechst nur Informationen sammeln, falls ich mich nicht doch zu ner grundlegenden Designaenderung zu Gunsten von Extjs durchringe.

Ufert das hier nicht wieder aus wie damals? Diejenigen, die ein JavaScript-Framework a la Prototype, jQuery oder mooTools bevorzugen, und die jengigen, die lieber alles seber alleine neu bauen. Keiner lässt sich beirren.
Mein Senf dazu: Würde jeder Programmierer wirklich immer alles neu und effizienter machen, säß heute noch jeder an der Ausgabe seiner Zeichen, anstatt an der eigentlichen Logik.. will heißen: Man kann sich das Leben unnötig schwer machen. Und das Thema Browserkompatibilität und -unterschiede bei JavaScript ist (zusammen mit CSS) nun wahrlich kein Zuckerschlecken, egal wie gut man ist. Da ist jede (gute) Hilfe willkommen.
jQuery kann ich bedingt durch einen Job derzeit gut (da Stand die Wahl fest), das Verschieben oder Deaktivieren des $-Namens gibt einen weiteren Pluspunkt. Zusätzlich wird nicht alles im globalen DOM-Baum abgelegt, d.h. es wirkt alles etwas aufgeräumter (und wenn man den neuen "urchin" hat, auch in der produktiven....). Ich sehe keinen Sinn mehr, die Ajax-Call-Abhandlung in 100 Zeilen schreiben zu müssen, damit sie einigermaßen allgemeingültig in allen Browsern funktioniert (+100 Zeilen, wenn es 4 Varianten wären)... aber nur 5 Zeilen (weil schön formatierter Ein-Zeiler), und ich hab mehr Möglichkeiten in jQuery. Warum soll ich mir einen Abbrechen? Nur ein Beispiel von vielen.

Ich glaub es ist schon die allgemeine Meinung, dass Frameworks sinnvoll sind, ich wollte nur ein paar Zweifel an Prototype einstreuen, die mir so in IRC und Web begegnet sind, damit sich jeder zumindest Gedanken macht und bei der optimalen Loesung landet.
Javascript komplett haendisch zu basteln steht dann doch in keiner Relation vom Aufwand her.

Original von Kallisti
Ich glaub es ist schon die allgemeine Meinung, dass Frameworks sinnvoll sind, ich wollte nur ein paar Zweifel an Prototype einstreuen, die mir so in IRC und Web begegnet sind, damit sich jeder zumindest Gedanken macht und bei der optimalen Loesung landet.
Javascript komplett haendisch zu basteln steht dann doch in keiner Relation vom Aufwand her.

Och.. es gibt einige (bis viele?), die machen das so: "Kenne ich nicht, nutze ich nicht" oder "Ich kann das sehr viel effektiver, ohne soviel Drumherum.. natürlich ist das zu kurz gedacht, aber wie willst du da ernsthaft entgegensetzen? Wie Eisschränke an Eskimo verkaufen..

Ehrlich gesagt hab ich auch mal so gedacht, aber irgendwann wächst einem dann doch alles über den Kopf. Nicht einmal unbedingt bei der Entwicklung (wenngleich sich auch da mit Frameworks weit komplexere Resultate erzielen lassen), sondern vor allem bei der späteren Wartung des Codes.
Mein aktuelles Spiel verwendet überhaupt keine Frameworks. Gut, ich habe es so wie es ist übernommen und lediglich funktional erweitert, ohne technische Revolutionen, aber ich hätte vor 5 Jahren auch nicht das Know-how gehabt das Ganze ordentlich zu planen. Man wächst ja selbst mit seinem Projekt.
Die Hürde liegt aber relativ hoch, denn zum einen erfordern die meisten Frameworks viel Grundwissen, um richtig benutzt zu werden (oft mehr als die Leute vorweisen können), zum anderen braucht man ein nicht zu geringes Maß an abstraktem Denken und eine weitläufigere Sicht auf das ganze Projekt, um die Schnittstellen und Verbindungen überblicken und planen zu können.
Vor allem aber erfordert jedes Framework die Bereitschaft und Zeit sich erst einmal einzuarbeiten, bevor man wirklich loslegen kann. Das kann durchaus einige Wochen an Arbeit bedeuten, die keinerlei produktive Resultate bringen und ich denke das ist leicht frustrierend für Einsteiger.
Wenn man mit etwas einfachem anfängt und beobachten kann, wie es wächst und wächst, ist das für viele ein besserer Einstieg, als wenn da erst einmal eine sehr hohe Hürde ist nach der man schließlich viel weniger Arbeit hat und alles angenehmer läuft.
Zudem besteht die Möglichkeit, dass man mit einem Framework bereits scheitert, bevor irgendetwas produktives herum kam und so die Motivation verliert, während das mit der eigenen, inkrementellen Entwicklung nicht so leicht passiert.
In anderen Worten: Ich kann gut verstehen und nachvollziehen, wieso viele auf Frameworks verzichten wollen und je nachdem welchen Part das Framework im Projekt einnimmt (ein Javascript Aufsatz ist etwas anders als Catalyst / Rails / Django / Struts /.NET), kann es bedeuten, dass man eine enormen Menge an Zeit investieren muss, bevor etwas dabei herum kommt. Langfristig gesehen lohnt sich hingegen ein (nötigerweise gut durchdachtes und aktiv weiterentwickeltes) Framework fast immer.
Uneingeschränkt empfehlen und als immerzu beste Lösung sollte man ein Framework dennoch nicht verkaufen, es gibt sicher Anwendungsfälle, wo es sich wirklich nicht lohnt, doch bilden diese bei langfristigen Projekten eher die Ausnahme.
Sicher gibt es auch Spiele, bei denen niemand erwartet, dass sie eine lange Lebenszeit haben werden und mit denen sich der Entwickler nur weiterbilden möchte. Dann ist das ja auch vollkommen in Ordnung, nur irgendwann wird auch da wohl eine Neuimplementierung nötig - und dann bestimmt nicht ohne Frameworks.

Was für'ne sinnlose Sandkasten-mein-Förmchen-ist-doller-als-deins Diskussion.
Ob nun Mootools, Prototype oder was weiß ich. Hauptsache es funktioniert und man selbst kommt damit klar...
Und prototype/scriptaculous funzt zusammen mit GoogeMaps ohne Probleme, aber das nur am Rande, ich will eure Schwanzvergleich Diskussion ja nicht wirklich beeinträchtigen.

Welche der folgenden Aussagen war Ernst gemeint?
* "Hauptsache es funktioniert"
* "*Hauptsache [...] man selbst kommt damit klar"
* "X-Framework kommt Y-Z klar"
Letzteres ist nur ne formale Sache, aber für alle drei Punkte gibt es eigentlich nur ein Kopfschütteln..

Die Diskussion ist auf dem selben Niveau wie Programm X ist besser als Programm Y, Betriebssystem X ist besser als Betriebssystem Y, Programmiersprache X ist besser als Programmiersprache Y, ... Das war und ist Kern meiner Aussage. Wie im Heise Forum halt...

Also eigentlich hat bis auf dich niemand auf dem Niveau geredet. ^^ Wir haben ueber den Sinn und Unsinn von Frameworks und ueber potentielle Schwachstellen und Probleme gesprochen, das hat recht wenig mit Heiseniveau zu tun.
Da ich mich bislang auch noch gar nicht auf ein Framework festgelegt habe, macht das sogar ziemlich wenig Sinn, eines zu befuerworten (wobei hey, ich tendiere atm zu jQuery + ExtJS).

Hm, dann habe ich das vielleicht anders aufgenommen, als es gemeint war. Für mich klang es jedenfalls so...
Ich selbst mag prototype + scriptaculous sehr gerne btw...

Bei prototype + Scriptaculous bin ich in der letzten Zeit einige Male an die Stelle gekommen, an der ich ein Script gebraucht habe und kein 100%ig geeignetes gefunden habe, da mir irgendeines von JQuery besser gefallen hat (als letzte ThickBox vs andere Modal Windows).
Für das Erstellen eigener Funktionalitäten hat mir Prototype als low-level Framework allerdings immer gereicht.
Mr.Maxx

Original von Kallisti
(wobei hey, ich tendiere atm zu jQuery + ExtJS)

warum nicht MooTools und Ext? Ist doch eine bessere Kombination

Ist zwar sehr out of topic aber egal...
Sehe ich es eigentlich richtig, dass die kostenloste Lizenz von ExtJS vorschreibt, dass das eigene Produkt Open Source sein muss? (damit fallen ja die meisten BGs raus)

Nein, es ist LGPL, nicht GPL. Das heisst wenn du die Bibliothek nur verwendest (also ExtJS), musst du dein Spiel nicht offenlegen. Wenn du die Bibliothek erweiterst oder veraenderst, musst du Aenderungen an der Bibliothek (also ExtJS) offenlegen, nicht jedoch den eigentlichen Code des Spiels. Das waere bei der GPL (erst ab GPL 3 bei Webservices) der Fall.
Bzgl. mootools vs. jquery - jquery hat einfach mehr Plugins/Erweiterungen und ich seh in der Richtung mehr Potential als bei mootools bislang. Aber ist eben auch ein subjektiv gepraegter Eindruck und bevor ich mich entscheide, werd ich es auf jeden Fall noch fuer mich mit ein paar Fakten untermauern. ^^

Original von Kallisti
Bzgl. mootools vs. jquery - jquery hat einfach mehr Plugins/Erweiterungen und ich seh in der Richtung mehr Potential als bei mootools bislang. Aber ist eben auch ein subjektiv gepraegter Eindruck und bevor ich mich entscheide, werd ich es auf jeden Fall noch fuer mich mit ein paar Fakten untermauern. ^^

das liegt daran, dass jquery für die massen ist und mootools einiges an erfahrung voraussetzt und nicht einfach zu lernen ist. Für mich war zB nie ein Thema, wie viele Plugins ein Framework hat, da ich fast alles sowieso selbst mache. Wobei man sagen muss, dass MooTools alleine schon den Großteil der Dinge, die man braucht (je nachdem, was man braucht), mitbringt

Original von wusch
Für mich war zB nie ein Thema, wie viele Plugins ein Framework hat, da ich fast alles sowieso selbst mache.

Höh? Widerspricht sich das nicht? Frameworks sind doch eben genau dazu da, damit man nicht alles selbst machen muss. Bitte berichtige mich, wenn ich falsch liege.

Frameworks geben die weitere Tols und Hilfestellungen, damit du Lösungen für Probleme und Aufgaben erstellen kannst.Sprich: du musst weiterhin deinen Ajax-Request selber bauen, der dein spezielles DIv aktualisiert. Allerdings musst du das nur logisch zusammenbauen, das Framework übernimmt dabei alle Eventualitäten und Techniken.
Ein Plugin könnte beispielsweise auch einkomplexeres Suggesting a la Google sein.. dann muss man das halt selber bauen. Ohne ein Framework ist das aber wesentlich mehr arbeit (Browserabhängigkeiten, etcpp).

@MrMaxx
Was ist bei dir eigentlich aus Dojo geworden? Ich kann mich erinnern, dass du dazu mal nen Thread gestartet hast. War das nicht so doll oder wieso bist du bei Scriptaculous?
Ich gucke mir gerade Dojo 1.1 an, und das gefällt mir bisher echt gut. Habe vor in meinem Game komplett auf Web 2.0 zu gehen, und nach den ersten Seiten Tutorial scheint das damit durchaus drin zu sein.

Dojo ist ne feine Sache...allerdings nur, wenn du dich 100%ig darauf einstellst.
Dojo ist nicht dafür geeignet um deinen bestehenden auf reloads basierenden Workflow zu verschönern...deine Anwendung sollte dann schon 100% asynchron funktionieren, denn das starten von Dojo dauert...mal ganz abgesehen von der Grösse der Dateien (und noch viel mehr abgesehen vom Speicherverbrauch...guck dir mal den Speicherverbrauch vom Firefox vor dem Starten von Dojo und danach an).
Nebenbei hat Yahoo User Interface developer.yahoo.com/yui/ einen grösseren Funktionsumfang, wenn du schon soein Riesenteil benutzen willst.
Falls du mal was neues versuchen willst, dann schau dir doch mal GWT an...da hätte ich Interesse an nem Erfahrungsbericht. Das was ich mir dazu durchgelesen hatte sah sehr vieversprechend aus.
Ich benutze Prototype/Scriptaculous, weil ich in meinem Spiel eh keine Verwendung für Standartwidgets habe (es ist immernoch die Brettspielumsetzung).

Original von MrMaxx
Dojo ist ne feine Sache...allerdings nur, wenn du dich 100%ig darauf einstellst.
Dojo ist nicht dafür geeignet um deinen bestehenden auf reloads basierenden Workflow zu verschönern...deine Anwendung sollte dann schon 100% asynchron funktionieren, denn das starten von Dojo dauert...mal ganz abgesehen von der Grösse der Dateien (und noch viel mehr abgesehen vom Speicherverbrauch...guck dir mal den Speicherverbrauch vom Firefox vor dem Starten von Dojo und danach an).
Nebenbei hat Yahoo User Interface developer.yahoo.com/yui/ einen grösseren Funktionsumfang, wenn du schon soein Riesenteil benutzen willst.
Falls du mal was neues versuchen willst, dann schau dir doch mal GWT an...da hätte ich Interesse an nem Erfahrungsbericht. Das was ich mir dazu durchgelesen hatte sah sehr vieversprechend aus.
Ich benutze Prototype/Scriptaculous, weil ich in meinem Spiel eh keine Verwendung für Standartwidgets habe (es ist immernoch die Brettspielumsetzung).

Habe ein paar Performance-Tests mit Dojo gemacht. Habe die Seite http://dojotoolkit.org/demos/email-using-1-0 aufgerufen und mir den Prozess vom Firefox angeschaut. Der Speicherverbrauch ging von 50 auf 60 MB hoch, die CPU-Last lag beim Laden maximal bei 40%. Das ist doch voll OK.
Das Laden hat aber lange gedauert. 10 Sek. beim ersten Mal sind schon nicht ohne, aber ich will tatsächlich alles komplett asynchron machen, da sind die 10 Sek. wohl drin.
Das Yahoo-Teil und GWT würden mich auch interessieren. Aber ich stehe momentan vor den vielen JavaScript-Toolkits, wie der Ochs vorm Berg und um sie alle durchzutesten habe ich keine Zeit und auch außer dem Funktionsumfang keine Vergleichskriterien (und da unterscheiden die sich wahrscheinlich auch nur in der Tiefe).
Habe diese Woche für die Grundfunktionen von Dojo einen kompletten Abdend gebraucht, und da war noch kein bisschen Tiefe drin. Momenatan bin ich auf Dojo festgelegt (und das eigentlich auch nur wegen dem Namen ) und freue mich, dass ich bisher von niemandem ein "bloss nicht" zu hören bekommen habe.

Könnte wahrscheinlich einige von euch interessieren: mootools.net/slickspeed/
An sich bin ich auch gerade am überlegen welches Framework wohl das richtige wäre aber weit bin ich mit dem Gedanken bzw. der Entscheidung nicht.
In einem aktuellen Auftrag nutze ich zwar jQuery aber auch nur weil es dort die passenden Plugins bzw. Erweiterungen gab (ne Slideshow die mit einem Lightbox-verschnitt harmoniert).

Original von MrMaxx
Falls du mal was neues versuchen willst, dann schau dir doch mal GWT an...da hätte ich Interesse an nem Erfahrungsbericht. Das was ich mir dazu durchgelesen hatte sah sehr vieversprechend aus.

Also ich kann dazu sagen, dass GWT derzeit auch eine reine asynchrone Geschichte ist, aber es mir schon gefällt, damit Sachen zu entwickeln, da man immer die gleiche Sprache nutzt (also vorrausgesetzt man entwickelt mit Java).
Es gibt dafür auch schon einige Erweiterungen für ExtJS und sowas (wobei ich ExtJS im Browsergamebereich nicht benutzen würde). Ein bißchen Gewöhnungsbedürftig ist halt nur die JSNI (Javascript Native Interface), aber wenn man das beherrscht kann man sich jedes Framework, was man will, hinzubauen.
Das schöne ist halt, dass der Code vorher optimiert wird und man sich dahingehend nicht irgendwelche Sorgen machen muss. Derzeit hab ich noch keine Schwächen gefunden (ausser das man bei Codeänderungen immer den Code vorher durch den GWT-Compiler jagen muss). Aber gleiches Bild, wie bei anderen großen Frameworks: Das erste Laden dauert immer ein wenig.

ExtJs steht nicht unter der LGPL, sondern unter der GPLv3.
extjs.com/products/license.php
Könnte mal jemand kundiges genau erklären, was das für Webapplikationen bedeutet, die extJS benutzen? Mit Version 3 hat sich ja da einiges geändert, wenn ich mich recht erinnere.
So long...
Maxx

Original von MrMaxx
Könnte mal jemand kundiges genau erklären, was das für Webapplikationen bedeutet, die extJS benutzen? Mit Version 3 hat sich ja da einiges geändert, wenn ich mich recht erinnere.

Die Neuerungen und Veränderungen wurden von FSF recht übersichtlich zusammengefasst:
www.fsf.org/licensing/licenses/quick-guide-gplv3.html
Klar, lesefreundlich ist das noch lange nicht , aber vielleicht hilfts ja weiter.

Original von MrMaxx
ExtJs steht nicht unter der LGPL, sondern unter der GPLv3.
extjs.com/products/license.php
Könnte mal jemand kundiges genau erklären, was das für Webapplikationen bedeutet, die extJS benutzen? Mit Version 3 hat sich ja da einiges geändert, wenn ich mich recht erinnere.
So long...
Maxx

Das haben die dann aber in den letzten paar Tagen geändert.
web.archive.org/web/20070826144613/http://extjs.com/license
Da ist noch ganz klar von LGPL die Rede und als ich meinen Beitrag weiter oben verfasst habe, stand das auch noch auf extjs.com. Zudem ist die Seite anders strukturiert als zuvor und leitet auch auf eine andere url weiter.

On April 21st, 2008 Ext JS announced its decision to adopt the GNU General Public License (GPL) v3 for open source usage of Ext development libraries.

Da steht es ja...
Was dabei imho niemand vergessen sollte:
Wenn ich Javascript Libs und Code habe, der GPL lizenziert ist, heißt das afaik ja nur, dass ich Änderungen und Erweiterungen [eben dieses Javascript codes] ebenfalls unter die GPL stellen muss. Das betrifft _nicht_ den serverseitigen Code der Anwendung.
Oder um sie selbst zu zitieren:

The simple rule to follow is if you modify any functionality or file in an Ext product for a purpose other than configuration, you have created a modification. All modifications naturally are covered by the GPL v3 license. Additional information is available in the official GPL FAQ.

The following are examples of modifications:
* * Modify Ext JavaScript, Java or CSS source file
* * Extend Ext class or override any Ext functions or methods
* * Modifying an Ext API
The following are not modifications:
* * Creating a new theme in a new CSS file
* * Creating or applying a locale/language pack
* * Overriding property defaults on class prototypes (configuration)
Ich glaube damit kann jeder leben, oder habt ihr vor clientseitig dermaßen wichtige Dinge zu programmieren, dass ihr Angst um eueren "Besitz" habt, wenn dieser freigegeben werden muss?
Zumindest ich habe eher vor extjs zu benutzen, um mir das Leben an dieser Stelle möglichst einfach zu machen und wenn nur irgendwie möglich auf Modifikationen komplett zu verzichten. Falls ich extjs erweitern sollte, kann das gern GPL werden.
Ansonsten koennte man die Version von vor einer Woche forken und unter der LGPL weiter arbeiten.

Meiner Meinung nach haben sie dann aber das Wesen der GPL nicht verstanden.
Wenn die Funktionsfähigkeit meines Gesamtproduktes 'Software' von dieser Clientkomponente abhängt, so ist auch der Servercode betroffen.

The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities.

Dazu Abschnitt 6 der GPL v3.
Ich würde die Zukunft meines Projekt nicht in die Hände des Stallman und der FSF legen, die eines Tages erklären, dass ja der Servercode als abgeleitete Software der GPL-Bibliothek gilt, da er ja die GPL-Komponente kontrolliert und zum Teil auch die Ansteuerungen zu dieser generiert und damit selbt 'deriative work' ist.
In meinen Projekten wird sich niemals GPL-Code befinden.
LGPL war völlig ausreichend. Damit wird des 'Extenden' einer Bibliothek erschlagen.

Gibt zu dem Thema einen 62 Seiten Thread im ExtJS Forum (extjs.com/forum/showthread.php?t=33096&highlight=lgpl) ... ist echt ne problematische Sache.
Ihnen ging es wohl vor allem darum, dass kommerzielle Kunden auch kommerzielle Lizenzen kaufen sollen, also "quid pro quo" durchzusetzen -> Wer etwas nimmt, soll auch etwas dafuer geben.
Das Problem ist wirklich wo man die Grenze zieht und das ist rechtlich eine ziemliche Grauzone. Es sieht wohl so aus, dass die Programme/Scripts, die den GPL3 JS Code einbinden selbst unter die GPL fallen, also zumindest der Templating Anteil. Code der ExtJS ausliefert faellt sowieso darunter.
Kritisch wird es dann wenn es z.B. um JSON Daten geht... Sind das nur Daten, oder ist es mehr? Gibt da wohl keine rechtliche Klarheit.
Nachdem ich nun den gesamten Thread gelesen habe, sehe ich es auch weit problematischer als vorher...
De facto kann man von 4 Situationen ausgehen:
- GPL 3 Projekt -> GPL 3 Lizenz
- Kommerzielle Nutzung ohne Einschraenkungen -> Kommerzielle Lizenz
- kommerzielle Projekte, fuer die GPL 3 nicht in Frage kommt (z.B. Kollision mit anderer Software oder weil sie closed source bleiben wollen) und die sich die Lizenzen nicht leisten koennen -> fucked
- non-profit Projekt mit closed source oder open source unter anderen Lizenzen -> fucked

We are working on a FLOSS Exception that may help in your case. Please give us a little time. Thanks.

Mehr dazu hier: extjs.com/blog/2008/04/27/open-source-license-exception-for-extensions/
GPL3 heisst nun nicht immer, dass der Source offen gelegt werden muesste (bei einem Webservice), da gibt es die Affero GPL fuer, aber wer weiss, was dann eben GPL4 bringt... + kritisch wuerde es, wenn man den Source doch distributen moechte.
Zudem koennte man es als "distribution" ansehen, wenn der Javascript Code an den Client geschickt wird...
Und sie haben momentan ein groesseres Problem, wie sie mit Usererweiterungen und Plugins umgehen wollen, die mit der GPL Version angefertigt wurden...
Der Status der 2.0.2 Version ist auch nicht eindeutig, da sie im Grunde eine Lizenz, die unter gewissen Einschraenkungen eine LGPL Lizenz erlaubt hat, was an sich aber gar nicht sein darf... Nun koennte man sich vorstellen, dass jemand der die Einschraenkungen erfuellt das ganze unter normalen LGPL Bedingungen weiter an andere verteilt, die die Einschraenkungen nicht mehr erfuellen muessen. Der Schritt zu GPL kam wohl vor allem um das Dilemma zu loesen.
Wie auch immer, es gibt auf jeden Fall Versuche die 2.0.2 Version weiter zu patchen:
ajaxian.com/archives/openext-the-fork
Es gibt allerdings auch andere Meinungen bzgl. des "Javascript einbinden" Problems.. Um mal aus dem Ajaxian Artikel oben zu quoten:

It’s a shame Jack has decided to go and spread FUD about how open source works, and is promoting falsehoods.
For instance he claims that if your (back-end) project in any way shape or form opens and reads a file that does a src=”extjs.js”, the project must be GPL too. This is blatantly incorrect, just as incorrect as compiling a commercial .c file with gcc doesn’t make it GPL, and opening a GPL based file with a commercial editor doesn’t make the editor GPL either.
To be clear:
- Having a closed source back end + ExtJs = ok under the GPL (it’s not linked (in the sense of libraries linked at compile time) or derived work
- Having ExtJs in your web page + closed libraries in your web page, is ok, as long as the closed source libraries don’t actually call extjs (if this was untrue having different licensed files in one directory would make everything gpl too, its nonsense to think so!)
- If you make javascript (or whatever) that does ‘link’ to ExtJS (ie extends its functions, calls its functions, etc) then -that- code is GPL too.
So if you want to use ExtJS in a closed source program what you do is:
- backend that loads html / template files and outputs them, with data available either output in javascript array’s or through json etc.
- a small bit of javascript that feeds the data to ExtJS, and only this bit of code is actually now GPL, but none of the other code is.
I take some offence to Jack claiming in his forums that you have to ‘distribute your source code’ of your back end or front end as soon as you include ExtJS in the page, this is not how the GPL works or is intended, and a back-end that reads and output’s templates is not GPL because that template includes some GPL work.
I wish Jack would ‘get’ open source and it’s licenses, it would make all our lives a lot more pleasant ;/
Mal beobachten, was da noch so kommt...

Grad gesehen und imho alles andere als unwichtig:
feedraider.com/item/7786426/Planet-PHP/GPL-and-Javascript-Arnold-Daniels/
Ueber Javascript und GPL....
Auch sehr sehr interessant und spiegelt auch meine Meinung zur Kombination von Open Source und Kommerzprodukt wieder (@Undeadable, erinnert mich an deinen Thread im Stammtisch - da hatte ich dieselbe Meinung wie er hier ^^):
www.cnet.com/8301-13505_1-9931220-16.html

deshalb bin ich freund der MIT-License (zB MooTools). Ich finde es bei nicht komerziellen Produkten einfach am Sinnvollsten, wenn im Header dem jeweiligen Autor Respekt gezollt wird (durch Namen, URL etc.). Hilft man noch aus, in dem man Bugs findet und sich mit den Entwicklern über eventuelle Änderungen unterhält, bringt es im Endeffekt allen mehr. Ich finde das Zwanghafte veröffentlichen von jeglichem Code ist sehr gefährlich. Nicht, dass ich ein Freund von Closed-Source bin, es ist jedoch zB in manchen Fällen einfach besser, wenn man die Innereien nicht preisgeben muss (vor allem bei einem Browsergame zB eine Kampfberechnung, evtl. will man nicht, dass man sich im vorhinein ausrechnen kann, wie alles ausgeht etc.)

Danke Kalliste, das du an dem Thema dran bleibst und uns so gut informierst. Besonders der Freerider Arktikel hat mir viel Verständnis gebracht.
Mein momentaner Arbeitgeber wird vermutlich ext kommerziell lizensieren...ausser ich verkacke den Prototypen, aber der sieht jetzt schon wunderschön aus. Das Arbeiten mit ext macht definitiv viel Spass, was besonders der sehr guten API Dokumentation zu verdanken ist.
Ich habe schon vorher versucht mit YUI und z.B. deren TreeView zu arbeiten, aber da ist die Dokumentation recht leer (bis auf die Beispiele)...kein Spassfaktor.
So long...
Maxx

Auch von meiner Seite ein Danke für die Informationen, nur bin ich da skeptischer. Man könnte ja einen eigenen Thread dafür eröffnen, aber der würde nur zur Darlegung der eigenen Meinung dienen.
GPL in meinem Auge bedeutet, dass Software, die DIREKT von einer Installation einer anderen GPL-Komponente abhängig ist, automatisch bei einer Weitergabe GPL-lizenziert sein muss.
GCC und anderer Kram fällt raus, da während des Betriebs der Software kein GCC mehr erforderlich sein wird. Was anderes wäre es, wenn der Compiler irgendwie in dem Programm eingebettet sein sollte. Daher finde ich den Vergleich mit dem Textpad oder dem Compiler mehr als unpassend.
Ich verstehe das Interesse der Entwickler auch etwas Geld aus der Sache zu schlagen, bzw insbesondere zu verhindern, dass Dritte mit der Software Geld verdienen, ohne davon eigenen Profit zu erlangen. Jeder ist ein Mensch und ein Mensch braucht Futter.
Es wäre besser gewesen, wenn die extJS eine etwas klarere Lizenz gewählt hätten.
> Wer etwas nimmt, soll auch etwas dafuer geben.
Korrekt. Daher sehe ich die GPL als einzig richtige Lizenz für den Gedanken der offenen Software an. Auch wenn ich sie vermeide.
Vielleicht um nochmals meine Meinung klarer darzulegen:
a) Website liefert Html-Code mit extJS aus.
Kein GPL, da kein Code im Sinne von 'Sourcecode' ausgeliefert wird. Höchstens AGPL.
b) Betreiber X vertickert einen Server/eine Applikation, der Html-Code mit extJS ausliefert:
GPL! Betreiber X muss den SourceCode des Servers auf Anforderung mit ausliefern. Und dies ist auch im Sinne der GPL gut so!

Original von TheUndeadable
Ich verstehe das Interesse der Entwickler auch etwas Geld aus der Sache zu schlagen, bzw insbesondere zu verhindern, dass Dritte mit der Software Geld verdienen, ohne davon eigenen Profit zu erlangen. Jeder ist ein Mensch und ein Mensch braucht Futter.

Interessanterweise sind sie aber selbst nicht besser Um meinen MooTools-Ext Adapter in Ext einzubauen, haben sie eine komplette Copyrightübertragung verlangt was einschließt, dass Herkunft des Scripts (also dass es von mir ist), entfernt wird. Und dann steht über meinem Adapter oben drüber "ExtJS Team" und wird weiterverkauft. Auch nicht die feine Art.

Zum Thema welches Framework hier noch nen kleiner Vergleich: klick