Android-Standard anderer Zugriff?

[elementardragon]

Hallo an alle.
Ich habe gesucht, aber leider nichts gefunden. Ich weiß auch nicht, ob mir wirklich jemand helfen kann, aber ich wollte es versucht haben:

Ich habe eine Website erarbeitet, die ganz "normal" mit HTML, CSS und JS funktioniert. Sieht auch ganz ordentlich auf allen Browsern aus. Jetzt kommt der Haken: Als Bildergalerie habe ich mich für Lightbox entschieden. Ich klicke auf ein Bild und es öffnet sich im Vordergrund - auch schick. Bis auf den Standardbrowser von Android. Dort passiert nichts, wenn ich das Thumb antippe. Und jetzt der Clou: lege ich die HTML-Datei+zugehörige Ordner noch mal in einen Unterordner funktioniert es.

Meine Frage: Hat der Standardbrowser evt. einen anderen Ordnerzugriff? Es ist mir so nicht möglich eine völlig neue Ordnerstruktur nur für die Site an zu legen (noch bin ich gewillt für einen einzigen eine solche Ausnahme zu machen). Kann ich den Zugriff irgendwie richtig "legen", dass er auch im gegenwärtigen Ordner tut, was er soll?

Der Zugriff sieht so aus:

<script src="js/jquery-1.11.0.min.js"></script>
<script src="js/lightbox.js"></script>

<a class="image-link" href="Projekt/Ordner/DasBild" data-lightbox="GalerieName" data-title="Was man erzählen will."><img class="images" src="Projekt/Ordner/Thumb"  height="90px" width="90px"/></a>

liegen diese HTML-Datei + Ordner "Projekt/Ordner/" + Ordner "js/" in einem seperaten Ordner funktioniert es.

Ich hoffe, ihr könnt mir folgen. Würde mich über Hilfe freuen.

Liebe Grüße
element

[Felix Riesterer]

Liebe(r) elementardragon,

gibts ein online-Beispiel (gerne auch als Fiddle), bei dem man diese ganze Ordnerei mal genauer anschauen kann? Oder magst Du wenigstens ein (aufs Wesentliche reduziertes) File-Listing posten? Deine Beschreibung ist für mich nur bedingt nachvollziehbar.

Liebe Grüße,

Felix Riesterer.

[elementardragon]

Liebe(r) elementardragon,

gibts ein online-Beispiel (gerne auch als Fiddle), bei dem man diese ganze Ordnerei mal genauer anschauen kann? Oder magst Du wenigstens ein (aufs Wesentliche reduziertes) File-Listing posten? Deine Beschreibung ist für mich nur bedingt nachvollziehbar.

Liebe Grüße,

Felix Riesterer.

Hallo,

meine Website ist unter tinaleischker.com zu finden.

Ordnerstruktur:
Alle html-Datein

Docs (alles, was man runterladen kann)
Projekte > einzelne Ordner für Projektbilder
Concepte > einzelne Ordner für Konzepe
Layout (css und php) > js (alle Javascripte)

> Pictures (LayputPics) > Lightbox (die zur Lightbox gehörenden NavElemente)
                                               > Menue (alle MenüPics)

Und ich werde jetzt auch mal hootis Tipp versuchen. Was aber irgendwie seltsam wäre, weil überall funktioniert es ja, nur nicht im AndroidStandardBrowser. Aber ich werde es definitiv versuchen.

[hotti]

hi,

<script src="js/jquery-1.11.0.min.js"></script>

Vermeide relative Pfadangaben. D.h. aber auch nicht, dass eine Pfadangabe bis hoch zur Root im FS erforderlich ist, denn das macht auch Probleme, wenn das Template über einen Script-Alias ausgeliefert wird (in diesem Fall funktioniert werde eine relative noch eine absolute Pfadangabe). Eine Pfadangabe, die in JEDEM Fall funktioniert, hat den Bezug zum Webserver. Beispiel:

http://example.com/foo/bar/baz.js und mit der Pfadangabe
                  "/foo/bar/baz.js"

Machst Du Dich sogar unabhängig vom Protokoll und von Domain-Name (falls http zu https geändert werden muss oder der Entwicklungs-Server einen anderen Namen hat).

Um den Vorzug solcher Pfadangaben genießen zu können, wird eine lokale Serverumgebung eingerichtet, welche in Sachen Dateipfade dem Produktivsystem 1:1 entspricht.

MfG

[Christian Kruse]

Moin hotti,

Vermeide relative Pfadangaben.

Bitte nicht. Das führt dazu, dass man Software nur noch in einer Umgebung installieren kann; dass mag OK sein, wenn man alleine nur an seinen Sachen arbeitet, aber sobald man im Team arbeitet oder seine Software in einer anderen Umgebung braucht fällt einem das auf die Füße.

LG,
 CK

[elementardragon]

Moin hotti,

Vermeide relative Pfadangaben.

Bitte nicht. Das führt dazu, dass man Software nur noch in einer Umgebung installieren kann; dass mag OK sein, wenn man alleine nur an seinen Sachen arbeitet, aber sobald man im Team arbeitet oder seine Software in einer anderen Umgebung braucht fällt einem das auf die Füße.

LG,
CK

Hallo,

ich bin da ähnlicher Meinung, weil ich schon gern einen Aufruf im gleichen Ordner oder Unterordner machen würde, ohne Umwege zu gehen. Ich habe es dennoch versucht.
Zunächst: das Bild wird eigentlich schon geöffnet - nur Kilometer weit unten. Dann habe ich die Pfandangaben für die JS geändert, dannach öffnete er es als neuen Link, dummerweise geht diese Pfadangabe nicht für die CSS-Dateien. Komischerweise greift er dann auf die CSS gar nicht mehr zu.

LG
element

[hotti]

hi,

Bitte nicht. Das führt dazu, dass man Software nur noch in einer Umgebung installieren kann; dass mag OK sein, wenn man alleine nur an seinen Sachen arbeitet, aber sobald man im Team arbeitet oder seine Software in einer anderen Umgebung braucht fällt einem das auf die Füße.

Deine Aussage ist hinsichtlich Teamarbeit Unsinn. Eine Entwicklungsumgebung ist so beschaffen, dass sie dem Produktivsystem weitestgehend gleicht. Ggf. wird auch ein Kundenserver in einer VM nachgebildet, das garantiert ein reibungsloses Deployment. Ein Staging-System dient demselben Ziel und wie ich schrieb: Da funktionieren Pfadangaben auch dann zuverlässig, wenn der Staging-Server einen anderen Namen hat.

Relative Pfadangaben hingegen haben sich beim Entwickeln von Webanwendungen immer wieder als Fehlerquelle erwiesen, nach 15 Jahren Erfahrung, auch in Teamarbeit, gebe ich das gerne weiter.

MfG

[Christian Kruse]

Moin hotti,

Bitte nicht. Das führt dazu, dass man Software nur noch in einer Umgebung installieren kann; dass mag OK sein, wenn man alleine nur an seinen Sachen arbeitet, aber sobald man im Team arbeitet oder seine Software in einer anderen Umgebung braucht fällt einem das auf die Füße.

Deine Aussage ist hinsichtlich Teamarbeit Unsinn.

Soso ;)

Eine Entwicklungsumgebung ist so beschaffen, dass sie dem Produktivsystem weitestgehend gleicht.

Wie gesagt, dass gilt wenn man weitestgehend allein arbeitet. Aber in einem Team hat man idR sehr heterogene Umgebungen. Der eine benutzt Windows, der andere Linux, der nächste OSX. Der eine benutzt Subdomains, der nächste wieder Unterverzeichnisse.

Ggf. wird auch ein Kundenserver in einer VM nachgebildet, das garantiert ein reibungsloses Deployment. Ein Staging-System dient demselben Ziel und wie ich schrieb: Da funktionieren Pfadangaben auch dann zuverlässig, wenn der Staging-Server einen anderen Namen hat.

Es ging hier nicht um Testing/Staging, sondern um Development. Und da sind absolute Pfadangaben immer ein Problem. Übrigens, spätestens wenn man Software verkauft gibt es wieder Probleme: wer weiss, wo der Kunde die Software installiert? Klar kann man da Lösungen für Entwickeln, aber man kann ja auch einfach relative Pfadangaben benutzen – dafür sind sie da.

Relative Pfadangaben hingegen haben sich beim Entwickeln von Webanwendungen immer wieder als Fehlerquelle erwiesen, …

NACK. Die Fehler passieren ganz woanders. Wenn eine Ressource nicht verfügbar ist, dann fällt das sofort auf.

nach 15 Jahren Erfahrung, auch in Teamarbeit, gebe ich das gerne weiter.

Ich gehe ungern ad hominem, aber wir wissen ja, was du sonst so für Unsinn verzapst… und die 15 Jahre krieg ich auch zusammen.

Whatever, durch die Verwendung moderner Frameworks erledigt sich die Diskussion eh. Stichwort path helper.

LG,
 CK

[hotti]

hi,

Es ging hier nicht um Testing/Staging, sondern um Development. Und da sind absolute Pfadangaben immer ein Problem.

Hast Du überhaupt gelesen und verstanden was ich zu absoluten Pfadangaben schrieb? Gerne nochmal: Ich empfehle absolute Pfadangaben genausowenig wie relative Pfadangaben. Also weder absolute noch relative Pfadangaben. Was ich empfehle, sind auf den Server bezogene Pfadangaben, die mit einem "/" beginnen.

Es gibt also nicht nur 2 sondern 3 Möglichkeiten, ist Dir das eigentlich klar?

Und hier nochmal die Begründung:

1. solche Pfadangaben funktionieren unabhängig von Protokoll (http, https),
2. sie funktionieren unabhängig vom Servernamen
3. sie funktionieren auch dann, wenn Seiten, solche Pfadangaben enthaltend, über einen Script-Alias ausgeliefert werden
   3a) ein Script-Alias ist ein auf den Server bezogener virtueller Pfad
   3b) auch für PHP kann ein Script-Alias konfiguriert sein

Und, wer hätte das gedacht, bei den von mir empfohlenen Pfadangaben spielt es keine Rolle, ob Teile der Anwendung auf Windows oder Linux entwickelt werden.

Schönes Wochenende.

[Matti Mäkitalo]

Hi,

abgesehen davon, dass ich glaube, dass ihr von unterschiedlichen Dingen redet (Pfadangaben in URLs vs. Dateisystem)...

Eine Entwicklungsumgebung ist so beschaffen, dass sie dem Produktivsystem weitestgehend gleicht.

Wie gesagt, dass gilt wenn man weitestgehend allein arbeitet. Aber in einem Team hat man idR sehr heterogene Umgebungen. Der eine benutzt Windows, der andere Linux, der nächste OSX. Der eine benutzt Subdomains, der nächste wieder Unterverzeichnisse.

ich denke, dass hotti an diesem Punkt recht hat. Wenn das für euch ein Problem ist, CK, solltet ihr mal über den Einsatz von vagrant für Entwicklungsumgebungen und/oder etwas wie docker für Produktivsysteme nachdenken.

Vagrant (im Zusammenspiel mit einem Provisionierer wie puppet, ansible, chef) sorgt für den das Management der Entwickler-VMs, so dass es zu "works for me"-Problemen nicht mehr kommt.

Docker baut deine Applikationen in Container ein, die dann intern ganz andere Pfadstrukturen haben können, unabhängig vom Ort, wo der Container eingesetzt ist (quasi eine leichtgewichtige VM).

Ansonsten gebe ich dir recht: relative Pfadangaben erlauben es, eine Webapplikation in einem anderen Kontext (bei URLs wären das also "Unterordner" [ja, es gibt keine Ordner in URLs], "Subdomains" o.ä.) zu installieren. Das geht bei absoluten URLs (weder mit Serverangabe noch relativ zum Document-Root) nicht. Punkt CK.

Bis die Tage,
Matti

[hotti]

hi,

ich denke, dass hotti an diesem Punkt recht hat. Wenn das für euch ein Problem ist, CK, solltet ihr mal über den Einsatz von vagrant für Entwicklungsumgebungen und/oder etwas wie docker für Produktivsysteme nachdenken.

VirtualDocumentRoot ist auch ein nettes Feature ;)

Vagrant (im Zusammenspiel mit einem Provisionierer wie puppet, ansible, chef) sorgt für den das Management der Entwickler-VMs, so dass es zu "works for me"-Problemen nicht mehr kommt.

Docker baut deine Applikationen in Container ein, die dann intern ganz andere Pfadstrukturen haben können, unabhängig vom Ort, wo der Container eingesetzt ist (quasi eine leichtgewichtige VM).

Danke für den Tipp, ich gucke mir das auf jeden Fall mal an. Im Übrigen gibt es mit meinem Framework die Möglichkeit, eine Entwicklungsumgebung direkt auf dem Server einzurichten (Staging) ohne dass an der Serverkonfiguration was geändert oder gar Sub(Staging)domains eingerichtet werden müssen: Über Content-Negotiation und eine damit verbundene Policy ist es möglich, ein Produktivsystem komplett mit denselben URLs als Entwicklungsumgebung einzurichten.

Ja, richtig gelesen: Da sind neben plattformunabhängigen Pfadangaben (z.B. Artikelbilder) auch die URLs dieselben, nur der Benutzer ist ein Anderer. Letzterer kann auf diese Art und Weise z.B. den Warenkorb (Bestellvorgang) eines produktiven Shopsystems direkt auf dem Produktivsystem und mit demselben URL so testen, dass der Regelbetrieb davon nicht beeinträchtigt wird oder gar stillsteht und ohne dass dabei anfallende Daten in produktiven Datenbanken anfallen.

Gerne erkläre ich, wie das funktioniert, aber wer sowas als Blödsinn abstempelt, meint damit allenfalls, dass er nix versteht und sollte sich besser dem Kartenspielen widmen, als hier polemische Stimmungsmache gegen mich zu betreiben.

Schönen Abend.

[Christian Kruse]

Moin Matti,

abgesehen davon, dass ich glaube, dass ihr von unterschiedlichen Dingen redet (Pfadangaben in URLs vs. Dateisystem)...

Nö, nö. Da redeten wir durchaus von demselben.

Eine Entwicklungsumgebung ist so beschaffen, dass sie dem Produktivsystem weitestgehend gleicht.

Wie gesagt, dass gilt wenn man weitestgehend allein arbeitet. Aber in einem Team hat man idR sehr heterogene Umgebungen. Der eine benutzt Windows, der andere Linux, der nächste OSX. Der eine benutzt Subdomains, der nächste wieder Unterverzeichnisse.

ich denke, dass hotti an diesem Punkt recht hat. Wenn das für euch ein Problem ist, CK, solltet ihr mal über den Einsatz von vagrant für Entwicklungsumgebungen und/oder etwas wie docker für Produktivsysteme nachdenken.

Ich kenne beides, aber beides war in den Projekten, die mir da aus meiner Vergangenheit vorschweben, keine Option, aus historischen Gründen (Legacy-Projekte sind immer nervig). Wäre hier sofort mit sinnvollen, relativen Pfadangaben gearbeitet worden (sowohl in der URL als auch im Dateisystem), dann hätte man sich viele Probleme erspart.

Docker baut deine Applikationen in Container ein, die dann intern ganz andere Pfadstrukturen haben können, unabhängig vom Ort, wo der Container eingesetzt ist (quasi eine leichtgewichtige VM).

Also, den Begriff „leichtgewichtige VM“ für Docker finde ich aber mutig ;)

LG,
 CK

[mark]

Dass dein Problem mit der Ordnerstruktur zusammenhängt ist höchst unwahrscheinlich.
Bei dem Problem "Ordnerstruktur funktioniert bei Browser A aber nicht bei Browser B", würd ich als allererstes mal den Browser-Cache leeren, um diese Fehlerquelle auszuschließen.

Hast du andere mobile-Browser auch ausprobiert? Wie verhalten die sich? Laut Suchmaschine gibt es nämlich auf mobilen Geräten immer wieder mal Probleme mit Lightbox.

lg
mark

[Mitleser]

Dass dein Problem mit der Ordnerstruktur zusammenhängt ist höchst unwahrscheinlich.
Bei dem Problem "Ordnerstruktur funktioniert bei Browser A aber nicht bei Browser B", würd ich als allererstes mal den Browser-Cache leeren, um diese Fehlerquelle auszuschließen.

Dito.

Hast du andere mobile-Browser auch ausprobiert? Wie verhalten die sich? Laut Suchmaschine gibt es nämlich auf mobilen Geräten immer wieder mal Probleme mit Lightbox.

Meine Glaskugel empfiehlt, einen anderen Zugang zu versuchen (z.B. WLAN statt Mobilfunkanbieter). Die Mobilfunkanbieter zerrupfen den Traffic gerne, um ihn dann neu verwurstet an den Client zu senden. Ein Beispeil hierfür wäre JavaScript-Inlining, das kann gerne mal schief gehen. Um es zu verhindern, kann man die fraglichen JS-Ressourcen um einen Zugriff auf Script-Elemente erweitern, das reicht aus, um die Mobilfunkanbietermagie die Füsse still zu halten, z.B. mittels "(function() {var x = document.getElementsByTagName('script')}());"

[elementardragon]

Dass dein Problem mit der Ordnerstruktur zusammenhängt ist höchst unwahrscheinlich.
Bei dem Problem "Ordnerstruktur funktioniert bei Browser A aber nicht bei Browser B", würd ich als allererstes mal den Browser-Cache leeren, um diese Fehlerquelle auszuschließen.

Hast du andere mobile-Browser auch ausprobiert? Wie verhalten die sich? Laut Suchmaschine gibt es nämlich auf mobilen Geräten immer wieder mal Probleme mit Lightbox.

lg
mark

Hey mark,

um deine Frage wenigstens zu beantworten: Ja, wir hatten einige ausprobiert. Auch den Chach habe ich mehrfach geleert - mindestens nach jeder Änderung. Ich hab stark versucht, die Website so zu gestalten, dass sie "überall" ähnliche Ergebnisse bringt. IPad (also Safari) und der mobile Firefox brachten die Website fehlerfrei zustande. Es war wirklich nur der Standardbrowser und da ich irgendwie davon ausgehe, das der doch oft verwendet wird, war mir das ein Dorn im Auge.

LG
element

[elementardragon]

Gelöst.

Man mag es kaum glauben. Mal wieder. Es hatte nichts mit den Ordnerzugriffen zu tun, nichts mit den Verlinkungen oder dem Script an sich. Er mag sicher nicht der schönste sein, er funktioniert: ich musste die Reihnfolge des Aufrufs der verschiedenen CSS-Datein ändern. Anscheinend hatte ich ausversehen mit einer CSS-Datei etwas anderes ausgehebelt.

Danke trotzdem für eure Hilfe. :)

LG
element

[Mitleser]

Man mag es kaum glauben. Mal wieder. Es hatte nichts mit den Ordnerzugriffen zu tun, nichts mit den Verlinkungen oder dem Script an sich. Er mag sicher nicht der schönste sein, er funktioniert: ich musste die Reihnfolge des Aufrufs der verschiedenen CSS-Datein ändern. Anscheinend hatte ich ausversehen mit einer CSS-Datei etwas anderes ausgehebelt.

Vermutlich durch Inlining

[elementardragon]

Man mag es kaum glauben. Mal wieder. Es hatte nichts mit den Ordnerzugriffen zu tun, nichts mit den Verlinkungen oder dem Script an sich. Er mag sicher nicht der schönste sein, er funktioniert: ich musste die Reihnfolge des Aufrufs der verschiedenen CSS-Datein ändern. Anscheinend hatte ich ausversehen mit einer CSS-Datei etwas anderes ausgehebelt.

Vermutlich durch Inlining

Danke für den Tipp. Werde ich mir auf jeden Fall noch mal genauer anschauen. Zu meiner Schande muss ich gestehen, dass ich die JS-Dateien relativ unangetastet gelassen habe (ich beherrsche zwar Java, aber mit Script tue ich mich schwer). Wenn ich etwas mehr Zeit habe, würde ich mich damit aber durchaus noch mal beschäftigen und über deinen Tipp genauer nachdenken.
Danke. :)

[Gunnar Bittersmann]

@@elementardragon:

nuqneH

…  dass ich die JS-Dateien relativ unangetastet gelassen habe (ich beherrsche zwar Java, aber mit Script tue ich mich schwer).

Die Aussage war in etwa so sinnvoll wie auf die Frage nach Tenorsaxophon zu antworten: ich singe zwar Tenor, aber mit Saxophon tue ich mich schwer.

Qapla'

[Mitleser]

...ich beherrsche zwar Java, aber mit Script tue ich mich schwer...

So verschieden sind die Geschmäcker. Gezwungenermassen musste ich einige Male mit Java rumfummelen und fand es einfach nur schrecklich. "Gefühlt" viel zu akademisch, formal. Der Pragmatimus von JavaScript dagegen macht viel mehr Spass, erlaubt mit Hilfsmitteln (z.B. mittels Closures Compiler) auch Komfort wie z.B. Typprüfung, wird immer schneller und... ist plattformübergreifend einfach so verfügbar.

Außerdem: bei allem, woran node.js noch ein paar Jahre kränkeln wird: auf dem Server wie Client mit einer Sprache zu entwickeln, erscheint irgendwie _sinnvoll_.

[Gunnar Bittersmann]

@@elementardragon:

nuqneH

ich musste die Reihnfolge des Aufrufs der verschiedenen CSS-Datein ändern.

Wieso hast du davon überhaupt mehrere? Es sollte doch besser genau eine CSS-Ressource sein, die übertragen wird.

Man kann auch serverseitig mehreren CSS-Dateien zu einer Ressource zusammenfassen.

Qapla'

[elementardragon]

@@elementardragon:

nuqneH

ich musste die Reihnfolge des Aufrufs der verschiedenen CSS-Datein ändern.

Wieso hast du davon überhaupt mehrere? Es sollte doch besser genau eine CSS-Ressource sein, die übertragen wird.

Man kann auch serverseitig mehreren CSS-Dateien zu einer Ressource zusammenfassen.

Qapla'

Hallo,

ich muss sagen, das ist mehr für mich, um meine Übersicht zu wahren. Ich trenne dabei für mich nur wichtige Gedanken, wie zB das Menü (weil es etwas speziell ist), das allgemeine Layout und das Aussehen der Lightbox. Mag vielleicht aus Programmsicht nicht optimal sein, aber für mich sind Änderungen und Fehlersuchen so einfacher.
Ich weiß nicht genau, was du meinst mit "zu einer Ressource" zusammenfassen. Die Datein einfach in eine Stecken, oder gibt es die Möglichkeit eine Art switch zu schaffen?

LG
element

[Gunnar Bittersmann]

@@elementardragon:

nuqneH

Wieso hast du davon überhaupt mehrere? Es sollte doch besser genau eine CSS-Ressource sein, die übertragen wird.
Man kann auch serverseitig mehreren CSS-Dateien zu einer Ressource zusammenfassen.

ich muss sagen, das ist mehr für mich, um meine Übersicht zu wahren.

Ich weiß die Modularisierung auch durchaus zu schätzen.

Ich trenne dabei für mich nur wichtige Gedanken, wie zB das Menü (weil es etwas speziell ist), das allgemeine Layout und das Aussehen der Lightbox.

Bspw. also menu.css, layout.css, lightbox.css.

Mag vielleicht aus Programmsicht nicht optimal sein

Es ist aus Performancesicht nicht optimal: 3 HTTP-Requests anstatt einer. Für Geräte im Mobilnetz mit deutlich längerer Ladezeit verbunden.

Ich weiß nicht genau, was du meinst mit "zu einer Ressource" zusammenfassen.

Aus layout.css, menu.css und lightbox.css mach standard.css.

Dafür gibt es mehrere Möglichkeiten:

1. Hinter standard.css steckt keine Datei, sondern ein serverseitiges Script, bspw. PHP:

<?php  
header('Content-Type: text/css');  
readfile('layout.css');  
readfile('menu.css');  
readfile('lightbox.css');

Der Server baut die CSS-Ressource dann bei jedem Aufruf von standard.css aus den Dateien neu zusammen.

2. Das Zusammenbauen übernimmt ein Buildtool wie Grunt. Man pflegt weiterhin die einzelnen Dateien layout.css, menu.css und lightbox.css; auf dem Server liegt aber die zusammengefasste Datei standard.css.

3. Man verwendet einen CSS-Präprozessor wie Sass. Die einzelnen Dateien heißen _layout.scss, _menu.scss und _lightbox.scss (mit _ am Anfang). In standard.scss (ohne _) steht:

@import "layout";  
@import "menu";  
@import "lightbox";

Sass generiert daraus die Datei standard.css.

Qapla'

[Mitleser]

Es ist aus Performancesicht nicht optimal: 3 HTTP-Requests anstatt einer. Für Geräte im Mobilnetz mit deutlich längerer Ladezeit verbunden.

+1 +1 +1

Der Server baut die CSS-Ressource dann bei jedem Aufruf von standard.css aus den Dateien neu zusammen.

+1

2. Das Zusammenbauen übernimmt ein Buildtool wie Grunt. Man pflegt weiterhin die einzelnen Dateien layout.css, menu.css und lightbox.css; auf dem Server liegt aber die zusammengefasste Datei standard.css.

Prinzipiell ja. Allerdings bevorzuge ich den Workflow, dass der Präprozessor bereits in der Entwicklung mittels RewriteRule(ReverseProxy) just in in time die Übersetzung vornimmt(JS wie CSS). Der Deploy-Prozess feuert dann denselben Browserrequest der Entwicklungsumgeben zur Generierung der statischen Dateien ab. Es mag nach Paranoia klingen, führt aber zu einem entscheidendem Vorteil: single point of failure.