Beiträge von Arne Drews

Wie gesagt, alles was per <form>-Tag übermittelt wird, wird als String übermittelt, auch die Numberbox ( Ausnahmen: CheckBox, Radio, etc. ).

Das ist dann aber schade, bzw. der falsche Ansatz. Wenn Du gegen ein Wörterbuch vergleichen willst, musst Du erstmal wissen, wie Du die Daten in dem Wörterbuch ansprichst. Wie willst Du sonst vergleichen?!

Zitat von basti1012

bin mir jetzt nicht sicher, aber durch array.push werden die "" immer dazu gefügt.

Nö, push() wirft den korrekten Datentypen in das Array. Das Problem hier ist einfach nur, dass alles Formularfelder ( die zur Eingabe dienen ) grundsätzlich erstmal als String behandelt werden, ganz egal, was dort eingetragen wurde.

Du hast aber in Deinem Beispiel doch für die Berechnung bereits parseInt() verwendet, warum dann nicht gleich bei der Übergabe an das Array:

datenbank.push( parseInt(eingabe) );

Problem gelöst...

Dazu muss natürlich gewährleistet sein, dass der Wert der Eingabe tatsächlich einem Integer entspricht, oder man legt eine Prüfung und Fehlerbehandlung an.

Zitat von m.scatello

Damit geht es. Eigentlich habe ich mit 7Zip noch nie Probleme gehabt, warum Winrar da besser sein soll, wundert mich schon.

Ja, mich hats auch gewundert. Arbeite eigentlich nur mit WinRAR und habe auch auf Arbeit keine Probleme damit erstellte Zips mit dem Zip von Windows oder 7Zip wieder zu entpacken. Ich werde die Pakete oben mal gegen die mit Windows ZIP austauschen bei Gelegenheit. Könnten eh mal wieder neue Versionen erstellt werden

Lupus_III natürlich darfst Du Fragen stellen.

Wie ist Dein Wörterbuch aufgebaut?

Habe hier mal eine mit dem Windows eigenen ZIP mit anhgehängt, probier die bitte mal, danke!

Lies mal bitte die Hinweise in rot, respektive die Konversation darunter

WinRAR hat bspw. keine Probleme. Ich weiß leider nicht warum manche Programme damit Probleme haben.

Versucht euch selber dran, damit lernt es sich besser und das Formular ist einfacher anpassbar, wenn man es selber erstellt hat, weil man es besser verstanden hat.

Da es den PHPMailer aktuell nur schwer ohne Composer zu installieren gibt, habe ich den mal hier als fertig erstelltes Composer Paket abgelegt, dürfte noch ziemlich aktuell sein. Einbinden und Testmail ist dort auch kurz beschrieben.

Was heißt den "unterwegs", mit was für einem mobilen Gerät? Handy/Smartphone ist da nicht empfehlenswert und für alle anderen Gräte gibt es ausreichend Editoren/IDEs und auch FTP Clients. Das hängt aber wie gesagt davon ab, welches Gerät Du von unterwegs benutzt.

Ich würde für die PHP-Variante eher auf cURL gehen, als file_get_contents() zu verwenden.

Aber solange der Webserver ausreichend konfiguriert ist, macht es für das Ergebnis keinen Unterschied.

Ob der TE sich noch meldet? Mich interessiert brennend, was eine CSS-Tabelle ist...

Das hängt davon ab, ob Urheberrechte auf dem Inhalt der Audiodatei liegen und ob Du in dem Falle eine Genehmigung für das Streamen hast.

Wie Du dann streamen kannst, findest Du imNetz, bspw. hier: https://support.rackspace.com/how-to/streami…eo-with-html-5/

In den Foren werden zum größten Teil TinyMCE oder CKEditor verwendet Ich finde Quill ganz nett.

Ok, ganz so tragisch ist das scheinbar nicht, denn er bleibt zumindest auch ohne :scope im aktuellen Knoten:

<div class="wrapper">
  <div class="test">
    <span>test</span>
  </div>
  <span>foobar</span>
</div>

var _test = document.querySelector( '.test' );
console.log( _test.querySelectorAll('.wrapper span').length ); // Ausgabe: 1

d.h. er ignoriert in diesem Falle zwar den .wrapper, aber er sammelt zumindest schon mal keine <span> außerhalb des Scope.

Ein Problem tritt erst dann auf, wenn ich weitere Elemente unterhalb des Knoten an beliebiger Stelle habe, die auf das Matching passen:

<div class="wrapper">
  <div class="test">
    <span>test</span>
    <div><span>test+</span></div>
  </div>
  <span>foobar</span>
</div>

var _test = document.querySelector( '.test' );
console.log( _test.querySelectorAll('.wrapper span').length ); // Ausgabe: 2

Wenn ich nun den Selector entsprechend anpasse, zeigt sich das Verhalten, wie beschrieben:

console.log( _test.querySelectorAll('.wrapper .test > span').length ); // Ausgabe: 0
console.log( _test.querySelectorAll(':scope wrapper > .test > span').length ); // Ausgabe: 0
console.log( _test.querySelectorAll(':scope .test > span').length ); // Ausgabe: 0
console.log( _test.querySelectorAll(':scope > span').length ); // Ausgabe: 1
console.log( _test.querySelectorAll(':scope span').length ); // Ausgabe: 2

Was bedeutet, dass :scope tatsächlich eine Referenz auf die Node ist, über die querySelectorAll() angewendet wird.

Die Fälle, wo das jetzt wirklich zur Stolperfalle wird, sind dadurch zwar etwas geringer, aber man sollte sie dennoch nicht außer Acht lassen.

Da es keinen sinnigen Grund gibt, querySelectorAll() auf eine Node anzuwenden, wenn man diese nicht als Basis des Selector annimmt, sollte man sich angewöhnen in so einem Falle immer :scope zu verwenden.

Alternative

Man baut sich seinen eigene Selector auf Basis von querySelectorAll().

Interessant, das habe ich bisher wohl überlesen.

Ist zwar aus meiner Sicht ein merkwürdiges Standardverhalten, wenn eine Selector-Method auf Elemente/Nodes gebunden zur Verfügung gestellt wird, aber gut zu wissen.

Danke!

Zitat von Loula9626

Also wie ich es mache... Es funktioniert einfach nicht.

Dann machst Du es immer noch falsch, #7 funktioniert mit dem gezeigten HTML. Wenn bei Dir nicht, hast Du ein anderes HTML als gezeigt oder das CSS immer noch falsch angewendet. Bleibt aber am Ende Rumraterei, weil Du uns nicht zeigst, was Du wirklich hast. Damit meinen wir einen Link oder geposteten Code ( kein Bild! ).

And where is the problem? Your solution is functionally working like that. Did you try it?

Welche Sprache wann zu verwenden ist, ist tatsächlich nicht sooo pauschal zu beantworten, das hängt wirklich immer vom Problem/Vorhaben ab.

Wie gesagt, mit JS würde das mit der FileSystem API gehen, kann aber bedingt durch Deine Browser-Version und dem nicht standardisierten Zustand der API zu unerwünschten Nebeneffekten führen oder gar nicht funktionieren.

Nunja, was Du vorhast ist allerdings mit JS deutlich unkomfortabler, als mit PHP.

Was man lernen möchte ist das eine, welche Sprache dafür besser geeignet ist, die andere.

Dir will ja keiner was böses, aber JS ist dafür einfach schlechte Wahl, weil es abängig von der Browser-Engine ist.

JS ist nicht dafür gedacht, lokale Resourcen zu bearbeiten o.ä. Dass das mit neuen Schnittstellen, wie dem FileSystem API geht, ist der modernen Weiterentwicklung geschuldet, die JS ( glücklicher Weise ) erfährt. Die beste Lösung ist es deshalb aber noch lange nicht.

Zitat von Adviter

Weil man dafür wieder ein Server braucht [...]

XAMPP bietet dies als lokale Variante an. Wenn Du es eh im Browser ausgeben willst, macht es Sinn, das auf der Basis zu entwickeln.

Zitat von Adviter

[...] und weil ich versuche alles in JavaScript zu erstellen.

Da stellt sich die Frage: Warum?