Javascript Organisieren

[T-Rex]

Moin,

Wir fangen ein komplett neues Projekt an und können vor allem das Javascript neu organisieren. Bislang kamen wir ohne JQuery und solche Bibliotheken aus. Es waren entweder kleine Sachen oder unsere eigene Bibliothek hat das ganze ganz gut abgefangen. Jetzt wollen wir aber ein wenig mit der Zeit gehen und möchten auf JQuery setzen.

1. Es wird ja gesagt das viele Requests nicht gut sind. Bislang haben wir aber tatsächlich ca. 20-30 Javascrpt Dateien eingebunden. Waren natürlich eine Menge Dateien und Requests. Gibt es eine Lösung wie man die Javascript Sachen durch einen Parser (PHP) laufen lassen kann der mir am Ende eine Datei ausspruckt? Ich hab JS-Min im Internet gefunden. Ist das gut?
Eventuell ist es auch ratsam gleich am Anfang alles in eine Datei zu packen?

2. Führt mich auch gleich zur Zweiten Frage. Wir haben bislang auch für sehr kleine Probleme "Objekte" und "Klassen" gebaut. War natürlich eine tolle Sache alles OOP zu haben. Das haben wir aber auch für die kleinsten Funktionen gemacht. Gerade mit JQuery sind kleine sichtbar/unsichtbar Spielereien ja nicht mehr als 1-3 Zeilen. Dafür braucht man natürlich keine eigene Klasse oder Datei. Oder wie seht ihr dass?

Ich bräuchte da ein paar Vorschläge und Erfahrung. Gerne auch Links zu guten Vorgehen.

Gruß
derjenige der euch mit tausend "Dank Sagungen" überschüttet
T-Rex

[Kai345]

[latex]Mae  govannen![/latex]

Jetzt wollen wir aber ein wenig mit der Zeit gehen und möchten auf JQuery setzen.

"mit der Zeit gehen" ist meist nicht die richtige Begründung. jQuery (ich persönlich hasse es, aber das ist hier nicht maßgeblich) will - obgleich es viele Dinge vereinfacht - auch erst einmal erlernt werden. Diese Zeit muß eingeplant sein.

1. Es wird ja gesagt das viele Requests nicht gut sind. Bislang haben wir aber tatsächlich ca. 20-30 Javascrpt Dateien eingebunden. Waren natürlich eine Menge Dateien und Requests. Gibt es eine Lösung wie man die Javascript Sachen durch einen Parser (PHP) laufen lassen kann der mir am Ende eine Datei ausspruckt? Ich hab JS-Min im Internet gefunden. Ist das gut?

JS-Min dient dazu, *eine* Datei zu minifizieren, d.h. die Anzahl Requests bliebe erst einmal gleich und es müßte auch jede Datei einzeln minifiziert werden (was man natürlich automatisieren könnte). Es gibt daher Projekte, die dies automaisch erledigen, beispielsweise minify, das intern auch wieder eine js-min-Umsetzung ist, damit kann man die Dateien serverseitig automaisch zu Einer zusammenfassen und minifizieren lassen. Es gibt auch einen Cache, damit dies nicht bei jedem Aufruf erneut geschehen muß.

Eventuell ist es auch ratsam gleich am Anfang alles in eine Datei zu packen?

Nö, das ist unübersichtlich und nur für Kleinstprojekte sinnvoll.

2. Führt mich auch gleich zur Zweiten Frage. Wir haben bislang auch für sehr kleine Probleme "Objekte" und "Klassen" gebaut. War natürlich eine tolle Sache alles OOP zu haben. Das haben wir aber auch für die kleinsten Funktionen gemacht. Gerade mit JQuery sind kleine sichtbar/unsichtbar Spielereien ja nicht mehr als 1-3 Zeilen. Dafür braucht man natürlich keine eigene Klasse oder Datei. Oder wie seht ihr dass?

Der Vorteil ist halt, daß viele Dinge schon vom jQuery-Team geschrieben wurden und man es nicht mehr selber tun muß, sondern es einfach nur nutzt. Viel weniger Javascript ist es aber auch nicht, schließlich ist alleine jQuery ohne Zusätze unminifiziert auch mal locker fast 230kB Quellcode. Steckt also auch viel hinter. Es ist dann halt nur die Programmlogik, die vom Nutzer geschrieben wird und der Rest läuft jquery-intern ab und ist für viele Dinge wiederverwendbar.

Stur lächeln und winken, Männer!
Kai

[Malcolm Beck´s]

مرحبا

Viel weniger Javascript ist es aber auch nicht,

Soll es aber werden.

schließlich ist alleine jQuery ohne Zusätze unminifiziert auch mal locker fast 230kB Quellcode.

Welche Version soll das sein? Aktuell ist JQuery ca. 93 kb Gross, gezippt noch Stolze 33 kb. ich finde nicht, dass das viel ist, wenn ich bedenke, was ich damit alles anstellen kann. Ohne wirklich Javascript zu beherrschen. Ich will garnicht wissen, was ich damit alles anstellen könnte, wenn ich Javascript könnte. Wobei dann würde ich Wahrscheinlich eh Mootools benutzen.

Es ist dann halt nur die Programmlogik, die vom Nutzer geschrieben wird

Dank vieler Plugins musst du nicht mal viel schreiben, nur einbinden, aufrufen und fertig.

mfg

[Kai345]

[latex]Mae  govannen![/latex]

schließlich ist alleine jQuery ohne Zusätze unminifiziert auch mal locker fast 230kB Quellcode.

Welche Version soll das sein? Aktuell ist JQuery ca. 93 kb Gross, gezippt noch Stolze 33 kb.

Wie ich schrieb: die unminifizierte. Siehe Link, rechte Box. Der Hinweis sollte dazu dienen, um klarzustellen, da0 auch jQuery nichts "magisch" mit ein paar Zeilen macht, sondern daß da halt auch viel Code hinter steckt. Unterschied ist halt nur, daß der "gemeine Nutzer" sich Arbeit (insbesondere Cross-Browser) sparen kann.

Stur lächeln und winken, Männer!
Kai

[Malcolm Beck´s]

مرحبا

Wie ich schrieb: die unminifizierte. Siehe Link, rechte Box.

Kurz nach meinem Posting hatte ich die Box gesehen, ich nehm alles zurück :)

mfg

[Cheatah]

Hi,

1. Es wird ja gesagt das viele Requests nicht gut sind. Bislang haben wir aber tatsächlich ca. 20-30 Javascrpt Dateien eingebunden. Waren natürlich eine Menge Dateien und Requests. Gibt es eine Lösung wie man die Javascript Sachen durch einen Parser (PHP) laufen lassen kann der mir am Ende eine Datei ausspruckt?

bei meiner Arbeit habe ich ein System erstellt, dass mittels Pseudo-Kommandos wie IMPORT:dateiname.js eine Datei einbinden kann. Das ist simpel, wirksam und bewahrt die Übersicht.

Vorsicht: Dies sollte nur _vor_ dem Deployment geschehen. Die Ergebnisse sollten unbedingt als statische Dateien abgelegt sein.

Ich hab JS-Min im Internet gefunden. Ist das gut?

Sowas macht ein Debugging am "lebenden Objekt" unmöglich. Dank mod_gzip u.ä. ist der Nutzen davon auch vergleichsweise gering.

Eventuell ist es auch ratsam gleich am Anfang alles in eine Datei zu packen?

Nope, das Gegenteil sollte angestrebt werden. Je mehr Dateien bei der Entwicklung, umso besser - auch weil es zu modularen Ansätzen zwingt, die sehr effizient sein können.[1] Tipp: Um sich in zentrale Dateien "einzuklinken", eignet sich das Event-Modell von jQuery; Stichwort .trigger().

2. Führt mich auch gleich zur Zweiten Frage. Wir haben bislang auch für sehr kleine Probleme "Objekte" und "Klassen" gebaut. War natürlich eine tolle Sache alles OOP zu haben. Das haben wir aber auch für die kleinsten Funktionen gemacht. Gerade mit JQuery sind kleine sichtbar/unsichtbar Spielereien ja nicht mehr als 1-3 Zeilen. Dafür braucht man natürlich keine eigene Klasse oder Datei. Oder wie seht ihr dass?

OOP für umfangreichere Konzepte oder für Dinge, die man (ähnlich, nicht identisch) wiederverwenden will, ist eine super Sache. OOP als Selbstzweck ist der Versuch, Java-Konzepte auf JavaScript zu stülpen, was nur mit Gewalt geht und zu ähnlichen Ergebnissen führt. Don't do this at home.

Ich bräuchte da ein paar Vorschläge und Erfahrung. Gerne auch Links zu guten Vorgehen.

Deine Fragen zeigen deutlich, dass Du bereits über (meiner Ansicht nach) vernünftige Gedanken verfügst. Tue das, was Du für Dein Projekt sowie die (auch zukünftige) (Team-)Arbeit für richtig hältst. Noch'n Tipp: Die Inline-Dokumentation und andere Kommentare kann man im gleichen Script, das die Imports durchführt, vor dem Speichern der deployment-tauglichen Datei automatisch entfernen. Vergiss aber nicht, mit diesem Resultat auch zu testen ;-)

Cheatah

[1] Ja, sie können auch schlecht sein. Ich habe nicht den Eindruck, dass Du diesbezüglich Gefahr läufst ;-)

[molily]

Sowas macht ein Debugging am "lebenden Objekt" unmöglich. Dank mod_gzip u.ä. ist der Nutzen davon auch vergleichsweise gering.

Der Nutzen ist sehr groß. Üblicherweise lässt sich die Dateigröße durch Minification vor der Komprimierung nochmal im zweistelligen Prozentbereich verkleinern. Es ist gang und gäbe, das zu tun.

OOP als Selbstzweck ist der Versuch, Java-Konzepte auf JavaScript zu stülpen, was nur mit Gewalt geht und zu ähnlichen Ergebnissen führt. Don't do this at home.

OOP != Klassen. OOP in JavaScript kann vieles bedeuten, denn JavaScript bietet einem vieles. Diese Möglichkeiten zu nutzen hat nichts damit zu tun, fremde Konzepte auf JS zu übertragen. Konstruktoren als bloße Funktionen und Prototypen z.B. sind keine Konzepte aus Java.

Mathias

[molily]

Hallo,

Bislang kamen wir ohne JQuery und solche Bibliotheken aus ... Jetzt wollen wir aber ein wenig mit der Zeit gehen und möchten auf JQuery setzen.

Im Jahr 2012 mit jQuery anzufangen ist wirklich mutig. ;)

Bislang haben wir aber tatsächlich ca. 20-30 Javascrpt Dateien eingebunden.

Buildsysteme wie Grunt helfen, die mithilfe von UglifyJS Pakete erzeugen und komprimieren.

Für verschiedene serverseitige Umgebungen gibt es eigene Build- und Asset-Verarbeitungs-Systeme. Welche verwendest du? Reines PHP?

Wir haben bislang auch für sehr kleine Probleme "Objekte" und "Klassen" gebaut. War natürlich eine tolle Sache alles OOP zu haben.

Objekte strukturieren Code erst einmal. In JavaScript ist das sehr einfach mit Objekt-Literalen. Das ist in fast jedem Fall sinnvoll, und/oder man nutzt Funktionen.

Klassen (Konstruktoren/Prototypen), Mixins und funktionales Erzeugen von Objekten erlauben das Wiederverwenden von Code und die Verallgemeinerung von Operationen, sowie das flexible Zusammenbauen von Objekten nach Bedarf.

Das ganze ist sinnvoll, wenn es tatsächlich eine Abstraktionsebene hinzufügt, beispielsweise MVC. Ansonsten gibt es gegenüber nacktem, unstrukturierten jQuery-Code nicht notwendig Vorteile, außer dass du eine Modularisierung und Kapselung umsetzen kannst.

Ich bräuchte da ein paar Vorschläge und Erfahrung. Gerne auch Links zu guten Vorgehen.

http://molily.de/weblog/javascript-organisation
http://molily.de/js/

Darüber hinaus macht es Sinn, sich MVC-artige Bibliotheken anzusehen, denn jQuery-Code alleine führt oft zu Spaghetti-Code, in welchem die Aufgaben nicht sauber getrennt werden.

http://backbonejs.org/
http://spinejs.com/

Interessant sind auch Modulsysteme wie AMD oder CommonJS und entsprechende Modul-Loader und Packaging-Tools wie RequireJS und r.js.

Mathias

[T-Rex]

Moin Mathias,

Hab mir heute das UglifyJS ein wenig angeschaut. Jedoch weiß ich nicht was ich damit anfangen soll. Ich hab gesehen, dass ich Javascript mittels Javascript minimieren kann. Aber wäre es nicht Sinnvoll die Dateien per Serverseitigem Script zu minimieren, bevor man sie ausliefert?
Oder soll ich die Script jedes mal Manuell in irgend eine Textarea kopieren und dann per Knopfdruck minimieren?

Gruß
der mal wieder nix schnallt
T-Rex

[molily]

Hab mir heute das UglifyJS ein wenig angeschaut. Jedoch weiß ich nicht was ich damit anfangen soll.

UglifyJS ist ein Node.js-Paket, dass du serverseitig (bzw. beim Deployment) ausführen solltest, um deinen Code zu minifizieren, BEVOR er zum Client geschickt wird.

Mathias

[T-Rex]

So wie ich das verstehe ist nodejs ein Serverseitiges Javascript. Dass muss wahrscheinlich installiert werden und läuft wie alles andere nur auf Linux Systemen?
Und jetzt die Quizfrage. Wieso sollte ich, um eine Javascript Datei zu verkleinern, eine komplett neue Technologie in mein Projekt einbauen? Mal davon abgesehen dass man Vollzugriff auf den Webserver braucht um neue Sachen zu installieren und den hab ich nicht.
Gibt es den Weltweit keine brauchbaren PHP Sachen die sowas schaffen?

Gruß
der in Sackgassen rennende
T-Rex

[molily]

So wie ich das verstehe ist nodejs ein Serverseitiges Javascript.

Node.js ist im engeren Sinne ein Kommandozeilenprogramm, das JavaScripte ausführt.

Dass muss wahrscheinlich installiert werden

Du musst es nicht auf dem Server installieren. Du kannst die Scripte auch auf deinem Rechner  minifizieren, bevor du ein Deployment vornimmst.

und läuft wie alles andere nur auf Linux Systemen?

Läuft auf Unix-Systemen genauso wie auf Windows.

Wieso sollte ich, um eine Javascript Datei zu verkleinern, eine komplett neue Technologie in mein Projekt einbauen?

Weil es die richtige Technologie für diesen Zweck ist.

Gibt es den Weltweit keine brauchbaren PHP Sachen die sowas schaffen?

JavaScript komprimieren erfordert einen JavaScript-Parser. Davon gibt es brauchbare in C++, JavaScript und Java.

Für PHP gibt es eine Portierung von JSMin. Das ist nicht wirklich ein brauchbarer JavaScript-Parser, deswegen würde ich darauf letztlich nicht vertrauen. Du kannst es allerdings probieren:
http://code.google.com/p/minify/

Mathias

[hotti]

hi,

Ich bräuchte da ein paar Vorschläge und Erfahrung. Gerne auch Links zu guten Vorgehen.

OK, wei Du's bist ;)

Meine Lösung setzt weiter oben an, da wo die Responses zusammengebaut werden (PHP, Perl), benutze ich Templates. Diese T. enthalten HTML, Links den jeweiligen JS-Klassen/Modulen, die JS-Funktionen/Methoden selbst und auch die Links zu den jeweiligen CSS-Dateien.

Das wird sehr übersichtlich und hat darüber hinaus den Vorteil, dass in den JS-Funktionen auch Platzhalter notiert sein können die dann beim Expandieren mit Werten bestückt werden (Strings, Zahlen...), eine JS-Funktion kann so mit Werten arbeiten, die serverseitig erstellt wurden.

Horsch'ti

[T-Rex]

Boah!!

Ich möchte ja die anderen Posts nicht klein machen, aber das ist eine coole Idee! Somit könnte man html Template erstellen die total frei von JS sind. Sau geil!! Das ist nämlich ein sehr großes Problem. Man hat zwar viele Objekte und eventuell auch viele Dateien, doch muss man diese im globalen Bereich mit Leben füllen. Und das kann sehr unschön werden.

Danke

Gruß
der mit der Glühbirne über dem Kopf
T-Rex

[hotti]

Boah!!

Ich möchte ja die anderen Posts nicht klein machen, aber das ist eine coole Idee! Somit könnte man html Template erstellen die total frei von JS sind.

He Moment mal, erst willst Du JS und nun wieder nicht!!??
Entscheide Dich!11!!

Sau geil!! Das ist nämlich ein sehr großes Problem. Man hat zwar viele Objekte und eventuell auch viele Dateien, doch muss man diese im globalen Bereich mit Leben füllen. Und das kann sehr unschön werden.

Mit Templates arbeiten, ist überhaupt eine feine Sache ;)
Ich arbeite u.a. mit Klassen, da ist das Template gleich eingebaut, da ist nur noch das Template selbst ggf. eine globale Variable (PHP) oder wird über den Special-Handler __DATA__ gelesen (Perl). Andere Klassen laden Templates aus Dateien...

Ho Sch'ti

[T-Rex]

Ähm. Also Templates benutze ich schon seit Jahren. Aber eben nur für HTML Sachen. Und wenn man eine Template Variable ins Javascript übergeben möchte muss man irgendwo einen script block definieren und irgendeiner Objektmethode des Javascript per Parameter eben diese Variable übergeben. Das können unter umständen viele Zeilen werden. Und wenn man nicht aufpasst übersäht man das komplette HTML mit script blöcken.

Ich habe dich so verstanden dass du die Javascript Dateien auch über ein Template laufen lässt. Das macht für mich sehr Sinn, so könnte man Defaultwerte per Template direkt in dem JS Objekt setzen. Man könnte auch "Konstruktoren" Erstellen die sich um das laden von anderen Objekten kümmern. Somit würde das laden im globan Bereich wegfallen. Und das meine ich auch mit JS freiem HTML. Es würde keinen Scriptblock mehr geben, dass könnte man auch in JS Dateien "verstecken".

Ich muss mir jetzt auf jeden Fall mal Zeit nehmen und mich durch die Horde von Links kämpfen, sonst wird molily noch böse ;).

Gruß
der versteckte
T-Rex

[hotti]

hi,

Ich habe dich so verstanden dass du die Javascript Dateien auch über ein Template laufen lässt.

Genau ;)

Freilich nicht alle, aber die, die's betrifft, brauchen dann z.B. kein getElementById('field').value; zu haben, sondern kriegen den Valü gleich mitgeliefert *G*.

Denke bitte daran, ein parseInt(valueahh, 10); zu tätigen, falls die Variable ein Integer(dezimale) sein soll, dann klappts auch mit den numerickenen Vergleichen (Ohmann, hat mich letzte Woche ne Stunde Arbeit gekostet) ;)

Ansonsten werden Links zu JS_Ressourcen auch ins Template geschrieben, das wird dann auch gekäschd und andere Seiten, die das nicht brauchen, kriegen das gar nicht erst.

Viele Grüße,
Hotti

[T-Rex]

Kommen wir doch mal zu den Details :D.

Es müssen bei dir zwei Templates laufen. Eines für Javascript und eins fürs reine HTML? Ist da die Laufzeit nicht immens hoch?
Gibt es den Fall das dein Javascript neu "compiliert" werden muss, falls sich Einträge in deiner Datenbank bzw. in deinem CMS ändern? Ergo muss das Template wie das HTML Template bei jeder Anfrage neu erstellt werden?

Ich schätze mal du hast mehrere Dateien die du zu erst zu einer Zusammenfasst und darüber das Template laufen lässt?

Erstmal die Fragen, später gibts bestimmt ncoh mehr :D.

Gruß
der Fragende
T-Rex

[hotti]

Kommen wir doch mal zu den Details :D.

ok,

Es müssen bei dir zwei Templates laufen. Eines für Javascript und eins fürs reine HTML?

Nicht trennen, das kann, soll und muss alles schön zusammenbleiben: HTML was JS braucht und der Link zur JS-Source: Ein in sich geschlossenes Template.

Gibt es den Fall das dein Javascript neu "compiliert" werden muss, falls sich Einträge in deiner Datenbank bzw. in deinem CMS ändern?

Wenn sich Alles ändern kann, kriegt die Response ein Cache-Control: no-cache. Was an JS-Ressourcen verlinkt ist, wird vom Browser gecached (i.d.R. per Last-Modified Header vom Webserver).

Ich schätze mal du hast mehrere Dateien die du zu erst zu einer Zusammenfasst und darüber das Template laufen lässt?

Eher andersherum: Mehrere Templates in einer Datei ;)

Hotti

[T-Rex]

Ich fühle mich gerade wie ein Zebrastreifen - mal verstehe ich und dann wieder doch nicht :D.

mal ein praktisches Beispiel. Bei mir gibt es aktuell eine sagen wir mal Tooltip Klasse. Die bekommt einen Value über eine Methode. Da dieser Value per Templatevariable gesetzt wird, muss es einen aufruf im global bereich geben:

  
<head>  
   <script type='text/javascript' src='tooltip.js'></script>  
   <script type='text/javascript'>  
       var objTooltip = new cTooltip();  
       objTooltip.load("${TEMPLATE_VARIABLE}");  
   </script>  
</head>  
<body>  
</body>  

Das ist für mich übrigends schon ein vermischen von JS und HTML. Die Datei tooltip.js ist sauber getrennt vom HMTL, aber das laden des Tooltips ist schon wieder im HTML Template. Und das ist halt nicht so toll, da hier enorm viele Klassen geladen werden können. Vor allem kommt man hierbei zu der Versuchung mitten im HTML ein Scriptblock zu definieren, weil dort eine Wiederholgruppe ist mit Daten die man halt so braucht. Am Ende hat man 40 Scriptblöcke über das gesamte Dokument verstreut. Deshalb ein Vermischen von JS und HTML. Damit meine ich kein onclick oder so ein blödsinn. Aus der Zeit bin ich (Gott sei dank) schon lange raus :).

Jetzt hab ich dich so verstanden, dass dieser globale Bereich nicht mehr im HMTL Template steht, sondern in einer extra Javascript Datei:

  
<head>  
   <script type='text/javascript' src='tooltip.js'></script>  
   <script type='text/javascript' src='execute_tooltip.js'></script>  
</head>  
<body>  
</body>  

Diese Datei wird dann mittels Template extra angesteurt und mit allen Werten die man so braucht bestückt.

Gruß
Bitte Ankreuzen
[ ] der Rex durchschaut alles
[ ] ok ich erklärs nochmal für den Rex
[ ] Der Rex sollte Friseur werden, dass rafft der nie
T-Rex

[hotti]

Ich fühle mich gerade wie ein Zebrastreifen - mal verstehe ich und dann wieder doch nicht :D.

HI ;)

mal ein praktisches Beispiel. Bei mir gibt es aktuell eine sagen wir mal Tooltip Klasse. Die bekommt einen Value über eine Methode. Da dieser Value per Templatevariable gesetzt wird, muss es einen aufruf im global bereich geben:

<head>
   <script type='text/javascript' src='tooltip.js'></script>
   <script type='text/javascript'>
       var objTooltip = new cTooltip();
       objTooltip.load("${TEMPLATE_VARIABLE}");
   </script>
</head>
<body>
</body>

  
Zum 1. Verständnis: Der <html><head></head><body>-Bereich ist bei Mir zwar auch ein Template, aber für alle Responses, die HTML ausgeben, derselbe. Da kommt nur das rein, was alle brauchen wobei Attribute wie title, descr.. über Platzhalter gesetzt werden. JS: Nur Links und nur welche, die alle brauchen.  
  

> Das ist für mich übrigends schon ein vermischen von JS und HTML. Die Datei tooltip.js ist sauber getrennt vom HMTL, aber das laden des Tooltips ist schon wieder im HTML Template.  
  
Zum 2. Verständnis: Das HTML-Template enthält das was in den <body>-tag soll (alles oder nur Teile). Wenn das, was dazwischen steht, JS braucht, dann kommt erst hier und genau in dieses Template der Link zur JS-Ressource obendran. Ggf. auch noch einzelne Funktionen.  
  
3\. Das letzte zu ladende Template hat </body></html> und ggf. noch was davor, was alle Seiten kriegen.  
  
  
  

> Und das ist halt nicht so toll, da hier enorm viele Klassen geladen werden können. Vor allem kommt man hierbei zu der Versuchung mitten im HTML ein Scriptblock zu definieren,  
  
Näh. Wenn Template und Code zusammen in einer Datei stehen, dann sauber getrennt in genau zwei Bereichen. Ich lege da immer eine Kommentarzeile rein, damit ich das auch im Quelltext sehe, wo das Template ist. Für meine private Seite werde ich das heute abend mal machen, guck einfach mal in die Startseite, so gegen 9....  
  

> weil dort eine Wiederholgruppe ist mit Daten die man halt so braucht. Am Ende hat man 40 Scriptblöcke über das gesamte Dokument verstreut.  
  
Da mach lieber mehrere Templates, wo in jedem Einzelnen die Übersicht gewahrt bleibt...  
  
  

> Deshalb ein Vermischen von JS und HTML.  
  
Irgendwo musst Du es ja machen ;)  
  

> Jetzt hab ich dich so verstanden, dass dieser globale Bereich nicht mehr im HMTL Template steht, sondern in einer extra Javascript Datei:  
  
Sowohl als auch, nicht jedoch im <head>-Tag, siehe Punkt 1  
  

> [code lang=html]  
> <head>  
>    <script type='text/javascript' src='tooltip.js'></script>  
  

> Bitte Ankreuzen  
> [ ] der Rex durchschaut alles  
> [ ] ok ich erklärs nochmal für den Rex  
> [ ] Der Rex sollte Friseur werden, dass rafft der nie  
  
[x] Der Rex ist ok, alles ganz normal und im grünen Bereich ;)  
  
So, und jetzt lass mich mal meine Seite machen, halbe Stunde... da siehst Du vo meine Templates liegen ;  
  
Ho Ch'ti

-- 
OOch den Film Ch'ti musst Du unbedingt mal gucken! 

[Kai345]

[latex]Mae  govannen![/latex]

Jetzt hab ich dich so verstanden, dass dieser globale Bereich nicht mehr im HMTL Template steht, sondern in einer extra Javascript Datei:

Sowohl als auch, nicht jedoch im <head>-Tag, siehe Punkt 1

In den head-Tag gehören ohnehin ausschließlich dessen zulässige Attribute und deren Werte... ;)

Stur lächeln und winken, Männer!
Kai

[hotti]

hi,

In den head-Tag gehören ohnehin ausschließlich dessen zulässige Attribute und deren Werte... ;)

Hä, Zipfel!?

Stur lächeln und winken, Männer!

Ho Ch'ti; SCNr

[T-Rex]

Soweit ich das verstehe hast du keinen extra Javascript Template Parse, sondern es wird ein Template für den Content geladen und da ist das Javascript dabei. Nur packst du das Javascript anscheinend nochmal extra weg, so dass es sauber aufgeräumt ist.
Dass ist natürlich eine gute Idee.

Achja deine Template Struktur konnte ich gestern nicht sehen. Das war zu kurzfristig. Aber trotzdem vielen Danke für deine Mühe.

Gruß
den Hotti in die Freundesliste aufnehmender
T-Rex

[hotti]

hi,

Soweit ich das verstehe hast du keinen extra Javascript Template Parse, sondern es wird ein Template für den Content geladen und da ist das Javascript dabei. Nur packst du das Javascript anscheinend nochmal extra weg, so dass es sauber aufgeräumt ist.

Jes; JS in Dateien ist und bleibt die beste Lösung, vo allem deswegen, weil Du Dich um 'issue cache' nicht kümmern musst, das handeln Webserver und Browser alleine aus.

Achja deine Template Struktur konnte ich gestern nicht sehen. Das war zu kurzfristig. Aber trotzdem vielen Danke für deine Mühe.

Ist seit gestern, 20:50 drin ;)

Und heute: Hab ich ein FusionChart über's Template eingebaut für eine Statistik-Seite, effektiv ne halbe Stunde Arbeit und im Prinzip nur Tipparbeit. Template mit Werte-Übergabe aus einer DB-Abfrage, ratz fatz war das erledigt, da macht das Arbeiten richtig Spaß!!!

den Hotti in die Freundesliste aufnehmender

Das freut mich sehr!!

Hotti

[molily]

Ich möchte ja die anderen Posts nicht klein machen, aber das ist eine coole Idee! Somit könnte man html Template erstellen die total frei von JS sind.

Das solltest du ohnehin tun.

Wenn du HTML dynamisch in JavaScript zusammenbauen musst, so kannst du Templating-Engines wie Mustache, Handlebars verwenden. Die lassen sich auch auf dem Server in JavaScript-Funktionen präkompilieren.

Das ist nämlich ein sehr großes Problem. Man hat zwar viele Objekte und eventuell auch viele Dateien, doch muss man diese im globalen Bereich mit Leben füllen. Und das kann sehr unschön werden.

Muss man nicht. Dazu habe ich dir verschiedene Links gegeben.

Mathias

[Mitleser]

Meine Lösung setzt weiter oben an, da wo die Responses zusammengebaut werden (PHP, Perl), benutze ich Templates. Diese T. enthalten HTML, Links den jeweiligen JS-Klassen/Modulen, die JS-Funktionen/Methoden selbst und auch die Links zu den jeweiligen CSS-Dateien.

Das wird sehr übersichtlich und hat darüber hinaus den Vorteil, dass in den JS-Funktionen auch Platzhalter notiert sein können die dann beim Expandieren mit Werten bestückt werden (Strings, Zahlen...), eine JS-Funktion kann so mit Werten arbeiten, die serverseitig erstellt wurden.

Du belastest den Webserver damit um das zigfach nötige und musst außerdem den Client noch (be)hindern, statische Ressourcen zu cachen. Supi!

[hotti]

hi Mitesser,

Du belastest den Webserver damit um das zigfach nötige und musst außerdem den Client noch (be)hindern, statische Ressourcen zu cachen. Supi!

Mach Dir keine Sorgen, der Cache kriegt immer noch genug zu fressen und nicht nur das: In Meinen Responseklassen (PHP/Perl-Framework) kann jeder HTTP-Header der Response entsprechend gesetzt werden, auch diejenigen Header, welche das Cacheverhalten bestimmen ;)

Hotti

[Matti Mäkitalo]

Hi,

Wir fangen ein komplett neues Projekt an und können vor allem das Javascript neu organisieren. Bislang kamen wir ohne JQuery und solche Bibliotheken aus. Es waren entweder kleine Sachen oder unsere eigene Bibliothek hat das ganze ganz gut abgefangen. Jetzt wollen wir aber ein wenig mit der Zeit gehen und möchten auf JQuery setzen.

Vielleicht wollt ihr euch mal die Closure Library ansehen (passend dazu gibt es auch den Closure Compiler und Closure Templates). Ich habe damit mal ein Projekt umgesetzt und fand es, nach ein wenig Eingewöhnungszeit, ganz gut.

Ich meine auch irgendwo ein soy2php-compiler gesehen zu haben (schau dir die Beschreibung zu Closure Templates an, wenn du diese Bemerkung nicht verstehst), aber auf die schnelle finde ich es nicht mehr.

Bis die Tage,
Matti

[T-Rex]

Hi Matti,

sowas in der Art kenne ich schon durch die YUI Bibliothek von Yahoo. Die hab ich auch mal angefangen genauer zu untersuchen und zu studieren. Doch nach einem Gespräch mit einem Bekannten möchte ich mich doch eher auf jQuery konzentrieren. Bei dem Gespräch haben wir beide gemerkt das YUI durch die viel zu starke Dominanz von jQuery eventuell ausstirbt und die Dokumentation bzw. Hilfeforen nicht zu jedem Thema Hilfe versprechen. Es gibt nichts schlimmeres, als wenn man ein Problem hat, es nicht selbst lösen kann und niemand hat den man Fragen könnte.

Die gleichen Probleme sehe ich bei dem Google Ding auch.
Auf der anderen Seite hat der Kern von JQuery eben nicht den Umfang den YUI bietet.

Das ist aber auch verzwickt...

Gruß
verzwickter
T-Rex