sziasztok

adott ez a javascript okosság, amely tök jól működik egészen addig, amíg azt nem akarom mondani neki, hogy a szükséges adatokat egy x helyen tárolt csv fájlból rántsa be. ennek a scriptje az oldal szerint ennyi a lényege:

$.get('data.csv', function(csv) {
$('#container').highcharts({ [...]

itt elvileg a get parancs lenne az érdekes. nekem meg is van a szükséges csv, az egyszerűség kedvéért szintén data néven fut, viszont nem jelenik meg a tartalma. lehetséges, hogy rosszul hivatkozom vagy plusz beállítás kellhet neki? egyébként egy beágyazott adatokból dolgozó chart szépen megjelenik, de ez nem. maga a data.csv-m a weblap gyökerében van jelenleg, de pakoltam már mindenfelé - eredménytelenül

[ Szerkesztve ]

                          hey friend listen, i know the world is scary right now but its gonna get way worse

De sikeres egyáltalán a lekérdezés? Ha nem, akkor nézd meg a hibaüzenetet, státuszkódot, ha igen, akkor meg nem ártana a kód többi része ahhoz, hogy érdemben is tudjunk segíteni.

Sk8erPeter

Nem szép megoldás a style.display property-t változtatgatni JavaScriptből, inkább osztályt érdemes rátenni vagy épp levenni róla, ami a display tulajdonságot CSS-ben beállítva tartalmazza, sokkal rugalmasabb megoldás.

Sk8erPeter

http://jsfiddle.net/ksz653fz/

Nem tudod meg backenden konvertalni a csv-t json-be?

Köszi! Van valami gyakorlati előnye is vagy csak szimplán esztétikusabb?

Lenne esetleg értelme minden sort egy ID-val ellátni, a szűrést pedig client-side/local storage-ban elvégezni majd az eredmény alapján állítgatni a displayt?

Tudom egy kicsit overkill, de érdekes kihívás lenne ha van teljesítménybeli haszna is

Everything that has a beginning... has an end

sziasztok

végül egyelőre a json konvert vált be, azt szépen lekezeli. elvi akadálya annak sem volna, hogy a csv menjen, de ott maga a file nem tetszik neki. nem húz be belőle adatot, pedig utf8 wo bom, vessző tagolás stb mint a dokumentáció szerint...

                          hey friend listen, i know the world is scary right now but its gonna get way worse

Alapvetően annyi a baj azzal, hogy JavaScripttel állítgatod a stílusát egy DOM-elemnek, hogy így keversz két különböző területet: alapvetően a CSS feladata meghatározni az oldal megjelenését (benne van a nevében, hogy stíluslapokat készítesz), JavaScripttel pedig inkább a viselkedését illik manipulálni az oldalnak. Nyilván vannak kivételek, de ez pont olyan példa, amire érvényes. Persze nem érdemes túlizgulni, ez már csak szépítgetés, szemantikai okoskodás.
Most amúgy kíváncsiságból rákerestem a dologra, és találtam egy cikket, ami vitatja az osztályok ráhelyezésének vagy levételének elvét, és inkább a data-attribútumok használatát javasolja:
http://toddmotto.com/stop-toggling-classes-with-js-use-behaviour-driven-dom-manipulation-with-data-states/
Elfogadható, amit ír, de túlzásba esik az osztályok használatának elvetésével. De egyébként nem rossz a data-attribútumok használata sem.

"Lenne esetleg értelme minden sort egy ID-val ellátni, a szűrést pedig client-side/local storage-ban elvégezni majd az eredmény alapján állítgatni a displayt?"
Semmi értelme nem lenne ennek a megoldásnak. A szűrést így is az összes adaton kellene elvégezni, itt pedig semmiféle előnyt nem jelentene az, hogy csavarintasz és bonyolítasz egyet a dolgon.
Gondolj bele, a mostani megoldásod egy document.getElementsByClassName hívás, ami visszatér egy HTMLCollectionnel, amin végigmész egy for ciklussal, és megnézed, benne van-e az adott sorban valahol a keresett elem, aztán kész vagy. Ez is nagyon gyorsan fog végezni, még ha többezer elemed lenne, akkor se lenne vészes, a DOM-manipulálás már más kérdés. Ha viszont átállnál arra, hogy id-k szerint kérdezgess le, akkor értelemszerűen az id-kat is nyilván kellene tartani egy másik tömbben (mert különben honnan tudod, hogy miket kellene lekérdezni? Ha meg nem tudod a konkrét id-kat, akkor vissza kell térned az eredeti, amúgy ezerszer értelmesebb megoldásra), és azon a tömbön kellene végigmenned, lekérdezned id szerint az elemet, majd pont ugyanezt a keresést végrehajtani. Nem nyertél semmit, sőt, még overheadet is tettél a dologba (plusz egy-egy lekérdezés minden elemre az id szerint is, miután megkaptuk a tömbből az elemet).
Azt meg nem tudom, hogy érted, hogy "client-side"-ban elvégezni a keresést, most is kliensoldalon keresel. localStorage-be átpakolni a keresést meg megint semmi értelme, mit keresne ott, miért kellene perzisztens módon tárolnia a kliensnek az összes adatot. Nem beszélve arról, hogy valószínűleg az oldaladon változni fognak ezek a megjelenített és szűrhető adatok, így a localStorage-et mindig szinkronban kellene tartani az újabb adatokkal.

Sk8erPeter

"elvi akadálya annak sem volna, hogy a csv menjen, de ott maga a file nem tetszik neki. nem húz be belőle adatot, pedig utf8 wo bom, vessző tagolás stb mint a dokumentáció szerint..."
De megnézted, hogy az AJAX-kommunikáció során milyen hiba keletkezik? Mit jelent, hogy "nem tetszik neki", ezt honnan látod, miből tudod? Kapsz hibaüzenetet? Vagy mi történik?

Sk8erPeter

Sziasztok!

Szeretnék automatán klikkelni egy gombra, bizonyos időközönként és ez működik is ha az elem class tagja 1 elemű, de ha ilyen mint alább, akkor nem tudom, hogy hogy lehet rá hivatkozni. Tudnátok segíteni?

class="value-control max js_sliderMetalMax js_valButton tooltipRight js_hideTipOnMobile"

Dell G3 3779 || Samsung S23+ || Samsung Watch 5 Pro || Oculus Quest 2 || Creality Ender 3 V2

sziasztok

@ Sk8erPeter& martonx - remélem helyesen értelmeztem, nagyon sokféleképpen talán csak nem lehet. ez a script. ha legörgettek, ott a csv minta ami teljesült, majd alatt a szükséges script. annyi változtatást eszközöltem rajta, hogy a megfelelő helyre hivatkoztam a csv esetén. de itt a teljes.

[ Szerkesztve ]

                          hey friend listen, i know the world is scary right now but its gonna get way worse

http://jsfiddle.net/sm3e5wjz/

Sk8erPeter mar vagy 3x megkerdezte toled, hogy a $.get egyaltalan rendben betolti-e a csv-t?!

Ezzel lehet jatszani a tobbieknek is, hogy miert nem megy. http://jsfiddle.net/d7ffr6qo/1/

aha..megvan -> http://jsfiddle.net/d7ffr6qo/2/

[ Szerkesztve ]

szia

nagykirály vagy, itt tök szépen lefut fiddle-ben : )) viszont tekintettel arra, hogy te hozzám képest pro vagy és a teszterben is lefut, innentől nekem is szépen le kellene futnia. de nem teszi, a chart nem jelenik meg. szóval akkor viszont ez valami lokális dolog lehet

az ajax kérdésre visszatérve - rajta voltam - firebug, net, xhr - GET data.csv 200 OK /ha jót nézek/

[ Szerkesztve ]

                          hey friend listen, i know the world is scary right now but its gonna get way worse

Behuztad a data.js-t?
<script src="https://code.highcharts.com/modules/data.js"></script>

[ Szerkesztve ]

Nézd meg szépen alaposan, amit Jim-Y írt neked. Nyilván csak nem figyeltél oda, hogy mit küldött neked.
Ezek közül minden stimmel?

<script src="https://code.highcharts.com/highcharts.js"></script>
<script src="https://code.highcharts.com/highcharts-more.js"></script>
<script src="https://code.highcharts.com/modules/data.js"></script>

<div id="container" style="width: 100%; height: 400px;"> </div>

Mindegyik fájlt behúztad? Szerkesztette is a kolléga a hsz.-t, látható, hogy a felsoroltak közül a harmadiktól jött helyre az, ami először nem működött.
ÉS nyilvánvalóan kell a jQuery is.

De itt van a komplett kód, amit akár kopipésztelhetsz is magadhoz:

http://jsbin.com/kamobinuju/edit?html,output

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Trying out Highcharts</title>
</head>
<body>
<div id="container" style="width: 100%; height: 400px;"> </div>

<script src="https://code.jquery.com/jquery-2.1.4.js"></script>
<script src="https://code.highcharts.com/highcharts.js"></script>
<script src="https://code.highcharts.com/highcharts-more.js"></script>
<script src="https://code.highcharts.com/modules/data.js"></script>
<script>
$(document).ready(function() {
$.get('https://gist.githubusercontent.com/jim-y/d056bb03e6d3348d6aca/raw/d27bef445c3b38b4254f64f5052133851620ad89/data.csv', function(csv) {
//console.log(csv);
$('#container').highcharts({
chart: {
type: 'column'
},
data: {
csv: csv
},
title: {
text: 'Fruit Consumption'
},
yAxis: {
title: {
text: 'Units'
}
}
});
});
});
</script>
</body>
</html>

A Jim-Y által felrakott CSV-fájlban pedig csak ennyi van teszt gyanánt:
Categories,Apples,Pears,Oranges,Bananas
John,8,4,6,5
Jane,3,4,2,3
Joe,86,76,79,77
Janet,3,16,13,15
Ez így egy teljesen szabályos CSV-fájl.
Ha ez sem műxik, akkor tényleg valami gáz van nálad.

(#5759) martonx:
"hogy lássuk egyáltalán a hivatalos dokumentációt tudtad-e értelmezni"
Már hogy én? Brühühühhűűűűű. Amúgy csak trollkodom, tudom, hogy nem nekem szólt.

[ Szerkesztve ]

Sk8erPeter

Jim-Y és Sk8erPeter - bocs, ha idegesítően béna voltam, megoldódott a dolog, köszönöm a segítséget! nem írtam, mert nem gondoltam relevánsnak, de az egész történetnek a joomla ad keretet, egy ilyen oldalba kell beillesztenem. minden szükséges script a helyén volt, kivéve a Jim-Y által megemlített data.js. pótoltam, de nem lett jobb, sőt, az addig megjelent chart-részlet is eltűnt. ok, hibakonzol: a mootools-more.js egyik sora szerint hibás a dátum (all my wat) a csv-ben. szórakoztam vele egy kicsit, meguntam, átneveztem a mootool-t hogy ne foglalkozzon a csv-vel, és most tök király, frankón meg a chart

[ Szerkesztve ]

                          hey friend listen, i know the world is scary right now but its gonna get way worse

Akkor itt valami más turpisság van, mert így nem működik.

Dell G3 3779 || Samsung S23+ || Samsung Watch 5 Pro || Oculus Quest 2 || Creality Ender 3 V2

De, mégis megy csak bénáztam egyet. Köszönöm

Dell G3 3779 || Samsung S23+ || Samsung Watch 5 Pro || Oculus Quest 2 || Creality Ender 3 V2

Amit Jim-Y írt, az BabelJSben íródott. Mondjuk azt nem igazán értem, minek szopatni ilyesmivel valakit, aki nagy eséllyel nem ért a Babelhez.
Itt van plain JavaScriptben (jQuery sincs behúzva; itt mondjuk direkt leszedtem az onLoadot is, hogy lásd, hogy kell kezelni az ablak betöltődésének eseményét):
http://jsfiddle.net/sm3e5wjz/1/

Sk8erPeter

Több hiba is van benne. Egyrészt az a nagy hiba, hogy nem raktad fel nekünk jsFiddle-re, hogy egyből tesztelni tudjuk, másrészt nem használtad a kód kijelölése után itt a fórumon a Programkód gombot, hogy normálisan nézzen ki.
Aztán:
1.
var napok = ["H", "K", "Sz", "Cs, P"];
ez ez akart lenni:
var napok = ["H", "K", "Sz", "Cs", "P"];
(külön a "Cs", "P" stringek)

2.
document.write("<div>" + napok + "</div>");
Ennek semmi értelme, mert a napok egy tömb, míg te a tömb cikluson belüli aktuális elemére vagy kíváncsi, ami a napok[i], vagyis az előzőnek a ciklusváltozóval indexelt formája.
Ezenkívül document.write()-ot nem használunk a gyakorlatban. SOHA. Még ha a tanár azt is mondja, akkor sem. Ha a tanár azt mondja, akkor le van maradva. Bár már akkor sem volt értelme, amikor divatos volt használni.

3.
fokok(i)
itt már láthatóan indexelni akartál, csak nem jött össze. Indexelésre a szögletes zárójelet használjuk, tehát így: fokok[i].

4.
document.write(<img src='https://cdn0.iconfinder.com/data/icons/good-weather-1/96/weather_icons-68-128.png'>);
Itt az <img ...> részt úgy kezded el, hogy elfelejtetted stringként átadni. Tehát ez így nem lesz jó.
Így jó lenne:
document.write("<img src='https://cdn0.iconfinder.com/data/icons/good-weather-1/96/weather_icons-68-128.png'>");
A feltétel másik részénél ugyanez.

Itt láthatsz egy működő változatot:
http://jsfiddle.net/5hvwzquf/

=====================================

(#5776) Agostino:
Akkor jó.

[ Szerkesztve ]

Sk8erPeter

Az adatbázisban userek vannak, ahol van egy név és egy boolean ami online/offline. A célom az lenne, hogy kliensoldalon külön táblázatban lennének azok akik online vagy offline állapotban vannak. Ha valaki fellép az átkerül az online-ba ha kilép akkor... Ezeket websocketen keresztül nézném, de nem lenne kicsit sok az, hogy mondjuk 5 másodpercenként lekérem, hogy ki offline ki online? A backenden Go dolgozna ahol ezek a kérések párhuzamosan lennének lekezelve.

"Akinek elég bátorsága és türelme van ahhoz, hogy egész életében a sötétségbe nézzen, elsőként fogja meglátni benne a fény felvillanását." - Kán

"Ezeket websocketen keresztül nézném, de nem lenne kicsit sok az, hogy mondjuk 5 másodpercenként lekérem, hogy ki offline ki online?"

Óvatosan kérdezem, tudod hogy mire való a websocket? Mert pont arra (na jó, lehet fából vaskarikaként is használni, ahogy elképzelted), hogy ne kelljen a szervert kérdezgetni, hanem az magától szól a klienseknek, hogy XY immár online/offline. Pont ettől jó a websocket, hogy ellentétben a http-vel, a kommunikáció kétirányú tud rajta lenni. Ha pollozni akarod 5 másodpercenként a szervert, akkor ahhoz egy sima ajax http hívás is bőven megteszi. Teljesen irreleváns, hogy mi dolgozik szerver oldalon, ha egyszer a websocket kommunikációt meg tudod oldani vele.

Én kérek elnézést!

Igen, csak mivel közben még másokat is kér le meg folyamatosan tölt fől ezért nem akartam, hogy ez a csatorna folyamatosan nyitva legyen.

"Akinek elég bátorsága és türelme van ahhoz, hogy egész életében a sötétségbe nézzen, elsőként fogja meglátni benne a fény felvillanását." - Kán

Nem csak simán ES2015? Nem látom a Babelt behúzva.

Be van húzva:

De amúgy bocsi, asszem hülyeséget mondtam, és igazad van, JavaScriptre visszaváltva elég a "use strict"; az elejére, és Blink-motorral menni fog ("Uncaught SyntaxError: Block-scoped declarations (let, const, function, class) not yet supported outside strict mode"). Firefoxban még nem ("SyntaxError: let is a reserved identifier"). Mindenesetre ezeket a problémákat áthidalja a Babel.

[ Szerkesztve ]

Sk8erPeter

Bal oldalt kerestem az External Resources alatt, ajjj.
Csak nekem fura a LANGUAGE megnevezés ott?

Jaja, kicsit megváltozott a jsFiddle, amúgy szerintem előnyére, legalábbis nekem jobban bejön, jobb helyen vannak a JS library-k annál a lenyílónál.
Picit tényleg fura ez a Language megnevezés, de végül is ha úgy vesszük, ezek tényleg mintha más nyelvek lennének, más szintaktikát használsz, a JavaScript sajátjánál sokkal értelmesebbet.

Sk8erPeter

ES2015 szerintem már egész vállalható. Volt szerencsém CoffeScript kódot látni, de szerencsére nem én voltam azon a projekten, és az első benyomás alapján nem is szeretnék ilyenen dolgozni.

Gondolom ezzel valami ilyesmit akartak elérni. Szóval ez sem egy ördögtől való dolog, de én például a Pythonban sem tudtam megszokni ezt a "nem zárunk le semmit, ott van a tab" dolgot.

[ Szerkesztve ]

egy "fingom sincs a websocketről, csak olvastam róla, hogy trendi" elismerés is elég lett volna, a béna magyarázat helyett
Javaslom vagy olvass már végre utána, vagy kérdezz meg minket, de ez a nekifutás így elég gyengén indul.
Nekem van olyan 2 éves CRM rendszerem is, ami már websocket-et használ a csoportmunkára, ahogy nézem fordfairlane is éppen benne van egy ilyen fejlesztésben, szóval van vele tapasztalat.
Egyébként websocket-en tényleg nem szerencsés sok adatot küldözgetni, inkább csak maga a jel a lényeg. Nálam pl. elmegy a sima ajax-os kérés, ami akár több száz KB-t is mozgathat. Aztán ha az sikeres volt, akkor megy a jelzés websocket-en, hogy megtörtént a funkció, és mehet a jelzés a klienseknek, hogy mi változott.

Hogy konkrét példát hozzak. 15 ügyintézőhöz ömlenek be az elintézni való ügyek. Ezeket magukra veszik, megválaszolják stb. Maguk a válaszolások, meg minden olyan funkció ami sok adatot mozgat (pl. dokumentumot tölt fel és csatol a válaszához) ajax-on mennek, de a sikeres ajax után rögtön elsül egy websocket trigger, ami szól a többi ügyintézőnek, hogy XY megválaszolta az ügyet, és mindenkinél már át is vált az ügy státusza. De ez csak egy jel kifelé a klienseknek. Az ügy megjelenítésekor szintén lefut egy ajax, ami meg leszed minden oda tartozó infót a szerverről, ehhez ismét nem websocket kell.
Ugyanakkor egy ügynek ha c sak a státusza változik, nem fut le ajax, csak websocket, mert úgyis minimális adatot kell továbbítani (ügy id-ja, és az új státusza). Nálam van erre egy ökölszabály, hogy ha 32Kbyte-nál több adatnak kell mozognia, akkor ajax. Ha kevesebbnek, akkor lehet websocket.

Szóval az ajax-ot és a websocket-et mindenképpen kombinálni érdemes, nem pedig csak az egyiket vagy csak a másikat használni.

Én kérek elnézést!

Nálam van erre egy ökölszabály, hogy ha 32Kbyte-nál több adatnak kell mozognia, akkor ajax. Ha kevesebbnek, akkor lehet websocket.

Ez egy általános good practice, vagy valami okból kifolyólag találtad ezt ki? Én sem websocketeztem még, ezért kérdem csak.

Ez engem is érdekele, mert a szabvány ennél sokkal többet enged meg.

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

Nem azzal van a problémám, hogy sok adat megy, mert konkrétan csak egy szám megy át és jön vissza még egy szám válaszként.

Úgy néz ki, hogy egy játék lesz ahol a játékos1 koordinátáját (vagyis csak az y koordinátát) küldi el a szervernek, ezt a játékos1 id-ja mellett frissíti, és kikéri a játékos2 pillanatnyi koordinátáját amit visszaküld válaszként. Ezzel az a baj, hogy ezt igen sűrűn teszi, így vagy az lett volna, hogy még egy másik websocket üzemel a játékkal foglalkozó socket mellett ami a chat funkciót intézi, és nem akartam, hogy ez folyamatosan menjen, vagy az lett volna, hogy ebbe beleépítve megy a chat is meg a játék is egy socketen, de jobbnak láttam szétválasztani.

"Akinek elég bátorsága és türelme van ahhoz, hogy egész életében a sötétségbe nézzen, elsőként fogja meglátni benne a fény felvillanását." - Kán

Köszönöm, nagyon érdekes cikk. meg is próbálom implementálni

Everything that has a beginning... has an end

ASP.NET-en a konyhakész SignalR-t használom websocketezéshez windows szerveren IIS-el hosztingolva. Ez azért fontos, mert amit magamnak kitaláltam, az nem biztos hogy máshol is így van. No, SignalR-nél 64Kybte-ban maximalizálták a csomagok méretét, de tapasztalataim alapján 32K fölött és elég nagy számú csomag mozgásnál elkezd instabil lenni a dolog. Ahogy utána olvastam, valami pufferek viszonylag könnyen be tudnak telni a webszerveren websocket esetben.

Innen jött a 32KByte-os önkorlátom, így atom stabil komolyabb terhelés mellett is. Meg valóban igaz is, hogy a websocket nagyon gyors kétirányú kommunikációra lett kitalálva pici csomagokkal, nem pedig nagy csomagok lassú egyirányú kommunikációjára mint a http. Szóval már csak architekturálisan is szerintem alapvető hibát jelez, ha az ember elkezd több száz K-t áttolni websocketen.

Én kérek elnézést!

Instabil alatt mit értesz? Sebesség csökkenést, adatvesztést?

Véletlenszerű adatvesztést.

Én kérek elnézést!

Sziasztok!

JS programozó segítségét szeretném kérni, egy Movian plugin átírásában.
A szóban forgó pluginnak megváltozott a domain-je .eu-ról .tv-re.
Azt hittem, ha kicserélem az összes ".eu" kifejezést ".tv"-re akkor újra működni fog, de sajnos nem megy.
Csak az indavideo-s videókat játssza le, mást nem
(Plugint úgy lehet a Movianban telepíteni, hogy az eszköz tárhelyének \Movies könyvtárába bemásoljuk a zip file-t, és betöltjük.)

[ Szerkesztve ]

Olcsó kütyük: http://tiny.cc/fbkutyu

Ebben a pluginben katasztrofális hülyeségek is vannak, ahogy elnézem, pl. ez:

var param = showtime.httpReq(path).toString().match(/<Form method="POST" action=''>[\S\s]*?name="op" value="([\S\s]*?)"[\S\s]*?name="id" value="([\S\s]*?)"[\S\s]*?name="fname" value="([\S\s]*?)"[\S\s]*?name="hash" value="([\S\s]*?)"/);

Hát ez nem tudom, milyen reguláris kifejezés akar lenni, ami direkt nem illeszkedik SEMMIRE? (Legalábbis erre illeszkedő stringet értelmes+hozzáértő ember nem ír le.) Vagy-jel nélkül fordul elő benne többször is adott attribútum, amire vizsgálódni akar (pl. name, value), szóval ez tuti sosem fog illeszkedni semmilyen stringre.

Ezenkívül borzalmasan elavult és gány az egész kód, pl. a <font> tag ezer éve deprecated HTML-ben, JS-ben eval()-t használ, amit nem illik, meg még lehetne sorolni, de a lényeg, hogy spagettikód hatása van az egésznek, szóval nehézkes lesz ezt javítani: a gond az, hogy szerintem most hirtelen nehezen fogsz találni olyat, aki tudja debuggolni neked ezt az éles környezetében, és kideríteni, hogy mi pontosan miért nem működik. Ettől függetlenül ha elmondod, pontosan mikre is lenne még szükséged az indavideón kívül, amit használnál, de nem működik, akkor azt meg tudjuk nézni, és megmondani, mi lehet a gond vele.

Sk8erPeter