Sempervivum bei deinem JS Fiddle kommt auf meinem IPhone das gewünschte blau heraus, ich denke dass es somit an der Canvas API des jeweiligen Browsers liegen muss..
Beiträge von wolf
-
-
Serverseitig mit PHP funktioniert die Methode mit GD recht gut, aber wie ich oben schon bemerkt habe ist sie ungenau.
Da offensichtlich entweder die Canvas API oder die von euch genutzte Canvas Library einen Fehler haben, wäre auf clientseite noch ein Kompromiss vorstellbar - Bild auf 10x10 verkleinern und diese Puschel nach dem Pixel für Pixel verfahren auslesen, evtl. Funktioniert dass ja
-
basti1012 Der witz ist jetzt das Bild im canvas auf 1x1 pixel zu verkleinern und dann die Farbe des einen Pixels zu lesen!
-
-
BITTE bleib doch einfach bei deinem alten Thread anstatt ein neuen aufzumachen 🤨
-
Sorry aber das ist nicht genug eigener versuch, ich mein du erwartest dass ich hier Freizeit von mir investiere dir etwas zu erklären und dir zu helfen. Prinzipeill mach ich das gerne, aber nur wenn schon versucht wird, das ganze selber zu lernen, fanch doch mal mit dem JS part an.. hier ein start Suchbegriff.
-
Ja helfen kann ich dir gerne, aber anfangen musst du
Hier eine kleine Hilfestellung was verlangt wird: Wie erstelle ich korrekt einen neuen Beitrag im HTML & HTML5 Forum - bitte vor dem Erstellen eines neuen Themas lesen!
-
Egal in welcher Sprache, zwei mir bekannte Optionen:
A: Pixelzeile für Zeile durchgehen, und die Farbe des Pixels speichern, am ende den durschnitt bilden. - sehr genau, aber Resourcenintensiv
B: Bild auf 1x1 Pixel skalieren und dessen Farbe ist dem Durschnitt ähnlich - nicht ganz so genau, dafür aber sehr Resourcensparend
-
-
Im Prinzip sind es nur zwei Methoden,
currency::init() und currency::calculate() die ::init() wird ausgeführt, wenn die Seite geladen ist, die ::calculate(), wenn sich im Formular etwas ändert oder das Formular abgesendet wird.currency::init()
- Liest alle Elemente aus dem DOM die gebraucht werden
- Holt sich den aktuellen Kurs von fixer.io
- Schreibt alle Währungen für die der Kurs bekannt ist in das Dropdown und aktiviert es dann
- Sorgt dafür das ::calcualate() aufgerufen wird
currency::calculate()
- Liest die "Einstellungen" aus dem Formular
- Holt sich den Kurs aus den von ::init() geholten Daten
- Berechnet das Ergebniss und schreibt es in das vorgesehene DOM objekt
Gerne könnt ihr meinen Code mit einem Verweis auf mich (elementcode.de) verwenden, für den Lerneffekt hat man mehr davon, wenn mann es nachprogrammiert (und nicht nur abschreibt ^^)
-
Stef , die Section ist nicht das richtige Element für das Ausgeben der Daten, in dem Fall eignet sich das outputElement hervorragend
-
Moin, bitte mach in Zukunft nur einen Thread auf!
Währungsrechner mit HTML, CSS und Javascript programmieren
Mein beitrag aus dem parralel Tread:
Denk daran, dass die Kurse schwanken.
Hierfür lohnt es sich eine API zu nutzen die einem diese angibt, z.B. http://fixer.io/ bzw.: https://api.fixer.io/latest?base=EUR
-
MrMurphy SEO hat sich verändert, es geht eben nicht emhr darum eine möglichst hohe Keyword dichte zu erreichen, möglichst viele Metainformationen auszuliefern uws.
Es geht inzwischen darum dem Nutzer der über Google kommt möglichst präzise, passenden Inhalt auszuliefern.
Natürlich kommt es auf weitere Faktoren an, wie z.B. das nutzen von aktuellem HTML, das bereitstellen von responsiven Ansichten, Informationen logisch aufgewertet bereitzstellen (Structured Data wie z.B. JSON-LD).
-
Richtig Stef, wenn es so einfach wäre, würde wohl kaum jemand PayPal als Zahlungsmethode nutzen.
PayPal Buttons sind vorerst einfacher für dich, die API ist n dickes ding, macht aber natürlich auch Spaß an solchen Dingen zu basteln
-
Dabei interessiert sich Google nicht für den Inhalt selbst, den können Suchmaschinen nicht entschlüsseln. In erster Linie interessieren Google bis heute die HTML-Elemente von Webseiten. So werden Webseiten mit aktuellen HTML5-Elementen wie header, main, article, footer gegenüber Seiten mit reinen div-Elementen bevorzugt.
Moin MrMurphy, dass stimmt so nicht, Google intressiert sich sehr Wohl für den Inhalt deiner Seite, z.B. werden die Beschreibungen (meta description) nur genutzt, wenn der Google Algo keine bessere findet (die gesetzte Beschreibung am besten zutrifft).
Auch Bilder werden von Google ausgewertet, ein Bild mit dem alt-Tag "Grüner Abpfel" und entsprechendem Namen, was aber einen Roten Apfel zeigt, findest du in der Google Suche unter "Roter Apfel"! -
Denk daran, dass die Kurse schwanken.
Hierfür lohnt es sich eine API zu nutzen die einem diese angibt, z.B. http://fixer.io/ bzw.: https://api.fixer.io/latest?base=EUR -
Abgesehen davon, dass ich denke das dein Beispiel ein anderes ist als es hier in diesem Thread geht:
Jeder eingeloggte User erhält seine eigene Session. In der Session ist deren id. Nun bei einem Beitrag wird diese Id in die Beitragtabelle abgespeichert. Nun hat man in dieser Tabelle nur die ID des Posters und seinen Beitrag. Nun muss ich ja irgendwie an den Namen kommen. Ohne Join habe ich dann den Namen durch ein Select-Statement aus der anderen Tabelle, welche die ganzen Registrationsdaten speichert, herausbekommen. Diesen Namen kann man dann auch bei der Ausgabe des Beitrages im Frontend dann verwenden.
So weit, so richtig.
Mit Join ist dies aber doch viel einfacher?
"Einfacher" ist subjektiv, manche machen lieber Joins, ander (Sub)selects.
Dabei beachtet man dann auch die Normalisierung.
Die Normalisierung besagt "nur", dass du Daten nicht doppen speichern sollst, z.B. die Adressen der Nutzer sollst du in eine extra Tabelle speichern (n:1, da ein Benutzer 1 Adresse hat : eine Adresse n Nutzer haben kann). Die Normalisierung wird in dem Thread Beispiel allerdings einhgealten, da beim Beitrag ja nur die jeweilige Nutzer ID gespeichert wird.
In deinem Beispiel beachtest du ja schon die Normalisierung, da wie du oben schreibst, ja der Beitrag und dessen Nutzer ID in einer Zeile stehen, da allerdings nur ein Nutzer diesen Beitrag verfasst hat, und eben nicht Viele nutzer diesen einen Beitrag verfasst haben brauchst du ja pro Beitrag nur einen Nutzer zu speichern (1:n ein Nutzer kann n Beiträge "haben" : ein Beitrag kann 1 Benutzer "haben"), richtig? -> Normalisierung eingehalten.
Beispiel n:n
Wenn du jetzt Aber die Funktion "Beitrag liken" implementieren willst, dann hast du n:n ein Nutzer kann n Beiträge Liken : ein Beitrag kann von n Nutzern geliked werden. Hierfür brauchst du eine Zuweisungstabelle, in der du auch noch Metadaten speichern kannst, z.B. wann der Like gemacht wurde.
Schlusswort
Wie du jetzt bei deinem Beiterag an z.B. den Nutzernamen kommst, ist nicht wichtig für die Normalisierung, hier kannst du eben einen Join oder ein extra Select nutzen. Da bei OOP (ObjektOrientierter Porgammierung) alle Datenbank-Ergebnisse sowieso in Objekten abgespeichert werden, ist dort ein einzelnes Select für den Benutzer sowieso nötig.
-
Stef dies ist nicht ganz richtig, verknüpfungstabellen werden nur bei n:n (mehrere Benutzer pro Beitrag) beziehungen benötigt, nicht bei 1:n (ein Benutzer pro Beitrag).
Der join funktioniert auch ohne die verknüpfungstabelle, da wir ja die User ID schon beim beitrag gespeichert haben (fk_user_id) -
Moin,
beim generieren der Liste der Beiträge (Post's) loopst du doch duch deine Beiträge durch -
bei jedem einzelenen Beitrag hast du bestimmt auch in irgendeiner Spalte (z.B. fk_user_id) den Benutzer gespeichert, der diesen Beitrag verfasst hat.
Wenn du jetzt den Beitrag augibst nutzt du einfach die fk_user_id um sie als GET Parameter an den Link anzuhängen z.B.: <a href="user/?id=<?=$row->fk_user_id?>"> -
Richtig,
da die Daten von Ajax neu eingefügt werden (und dein bootstrap davon nichts mitbekommt), muss das ganze neu initialisiert werden.
