ugrás a tartalomhoz

Adatküldés kliens oldali formázással?

mind1 valami név · 2019. Jan. 2. (Sze), 10.00
Kicsit csatlakoznék Gábor, szemantikus webbel kapcsolatos elképzeléseihez.
Valami hóttprimitív megoldást szeretnék arra, hogy küldök egy nagy halom adatot, leginkább gépi feldolgozást támogató formában a böngészőnek (természetesen megjelölve, hogy mi, micsoda benne), amiből aztán a böngésző készítene fogyasztható formátumú weblapot.
A kérdés az lenne, hogy ehhez milyen formát célszerű használni manapság?
Számomra ideális az lenne, ha JSON-t küldhetnék, meg mellé egy halom CSS-t, de úgy tudom, ez nem megy.
XML-ben lehetne, de az minden, csak nem egyszerű, ha kulturált formában akarom tartani az egészet.
Van erre valami bevált, kevés munkával megvalósítható eljárás?

Például van egy nagy halom IP cím, mindegyik mellett néhány számláló. Ez JSON-ben valahogy így néz ki:
'{"1.1.1.1": [1, 2, 3, 4], "1.2.3.4": [0, 12, 44, 55], "8.8.8.8": [123, 33, 55, 111]}'

Ebből szeretnék valami ilyet kapni a böngészőben:
1.1.1.1       1    2    3    4
1.2.3.4       0   12   44   55
8.8.8.8     123   33   55  111

Gondolom, ezt kliens oldalon macerás feldolgozni, ha nem akarok mélyebben elmerülni még a Javascriptben is.
Ha nem JSON-t, hanem XML-t küldök, azzal megoldható amit akarok (már nem emlékszem, pontosan mit kell használni, annak utána tudok nézni), csak az XML egy böszme állatfajta, akkor már az is egyszerűbb, ha a szerver rakja össze a HTML kódot.
Vagy eleve rossz úton járok?

ui: a Spamrobot vagy? captcha kicsit gázos, ha az előnézetet használom. Valami "reuse attack"-ra panaszkodik. :(
‹ Formázott ul középre helyezése Rekurzió ›
 ■
1

Hát a Gábor megoldása az XML

inf · 2019. Jan. 2. (Sze), 10.55
Hát a Gábor megoldása az XML + XSLT. Minden máshol kelleni fog javascript, hogy kicsomagolja az adatot, szóval muszáj belefolyni. Az XSL nekem kicsit túlkomplikált volt, vagy inkább hasonlóan hülye logikája volt, mint pl a funkcionális programozásnak. Egyiknek sem lettem valami nagy híve, a klasszikus dolgokat én jobban értékelem. Az XSLT-vel kapcsolatban a Gábortól tudsz tanácsot, esetleg példakódot kérni, már ha ad. Nem vagyok benne biztos egyébként, hogy szemantikus, amit csinál, ha nincs benne microdata vagy microformats, vagy bármi ilyesmi, akkor nem az.

A másik megoldás, ha szabványos módon akarsz metaadatot hozzácsapni, hogy valamilyen RDF formátumot használsz. Ha JSON közelit akarsz, akkor a JSON-LD esetleg szóba jöhet, bár százszor bonyolultabb formátum, mint pl az n-triples és a feldolgozása sem annyira egyszerű, igaz nem neked kell megírni a parsert hozzá. Lehet embedded JSON-LD-t használni vagy AJAX-al ránthatod le a szervertől, a lényeg szempontjából tökmindegy, fel kell dolgoznod, aztán HTML-re kell alakítanod.

Esetleg egy harmadik opció, hogy HTML-t küldesz, aztán azt szórod meg RDF-el microdata-val. Pl a fenti lehetne egy table vagy egy list. Ugyanúgy gépileg feldolgozható ez is, és nagyjából le is lenne formázva CSS-el is. Az izgalmas mondjuk az lenne, ha a microdata-ra lehetne CSS-t írni, mert akkor nem kellene külön class-eket megadni neki. Nem tudom, hogy erre van e lehetőség, nem néztem utána még.

Ezen kívül még azt szokták, hogy elküldik a HTML-t, és beleágyaznak embedded JSON-LD-t, esetleg más fajta RDF-et. Szóval kétszer küldik el ugyanazt egyben. A JSON-LD lesz a gépileg feldolgozható, amit ért a kereső, a HTML meg amit megjelenítenek a felhasználónak. Ezt a legegyszerűbb megcsinálni, de kicsivel nagyobb sávszélességet használ. Ehhez nem is kell kliens oldali XSLT vagy JS formázás sem.
2

Köszi. Ahogy kiveszem a

mind1 valami név · 2019. Jan. 2. (Sze), 11.09
Köszi. Ahogy kiveszem a szavaidból, a mostani "projektem" kapcsán jobban teszem, ha inkább szerver oldali template-eket használok, azokkal generálok komplett HTML-t, nem szórakozok azzal, hogy a böngésző részben/csak nyers adatot kapjon.
Minden egyéb annyi plusz munkával jár, ami a dolgok jelenlegi állása szerint nem éri meg a befektetett energiát.
3

Igen, ha nem akarsz nagyon

inf · 2019. Jan. 2. (Sze), 11.29
Igen, ha nem akarsz nagyon beletanulni a JS-be vagy XSLT-be, akkor jobban jársz, ha sima HTML-t küldesz, és ágyazol bele valamilyen RDF formátumot. Közben utánanéztem, és microdata-ra is tudsz CSS-t tenni, pl:
span[itemprop="name"] {color:red;}
szóval akár egybe is mehetne a kettő ha a kinézet nem nagyon rugaszkodik el az adattól. Ránézésre úgy kéne, hogy "itemtype=... itemprop=...", és az itemtype-ra valami szokást kialakítani, pl hogy mindig a teljes URL legyen benne, esetleg kétféle selectort megadni teljes és részleges URL-el. Gyorsnak nem hiszem, hogy gyors lenne a CSS feldolgozás ilyen selectorokkal, de ki kell próbálni. Ha mást nem akkor generálásnál csapsz hozzá külön CSS class-t helyette, aztán kész. Az RDF-be így is bele kell tanulni egyébként valamennyire meg pl schema.org vocab használatába pl, de szerintem ehhez a megközelítéshez kell a legkevesebb energia.
4

XML

Hidvégi Gábor · 2019. Jan. 4. (P), 12.44
A legegyszerűbb XML-lel, amit XSLT-vel transzformálhatsz a kliensnek megfelelő formára. A funkcionális gondolkodást szokni kell, de igazából nagyon egyszerű, ha az ember ráérez a logikájára. Nem véletlenül hívják stíluslapoknak, ugyanúgy, mint a CSS-t, itt is egy bemenő adatból készítünk a definíciók segítségével kimenőt. Összeszámoltam, 21 nyelvi elemet használok, ennyit egy óvodás is meg tud jegyezni.

Az XML transzformációkat szinte minden elterjedt programozási környezet natívan támogatja.

A JSON ehhez képest minden szempontból visszalépés, a sémák, az XPATH vagy a névterek hiánya miatt igazából csak egyszerűbb adatok átküldéséhez elégséges. Ezeket persze lehet szimulálni szoftverből, de egyrészt nincs rájuk egységesen elfogadott és használt szabvány, másrészt jóval lassabb lesz, mint a natív megoldások.

Az RDF, microdata és microformats kliensoldali dolgok, azaz a kész HTML-t "díszítik fel" szemantikus adatokkal. Éppen ezért ezt XSLT-vel is el lehet végezni bármikor, ha szükség van rá.
9

Az RDF, microdata és

inf · 2019. Jan. 5. (Szo), 08.40
Az RDF, microdata és microformats kliensoldali dolgok, azaz a kész HTML-t "díszítik fel" szemantikus adatokkal. Éppen ezért ezt XSLT-vel is el lehet végezni bármikor, ha szükség van rá.


Ez így nagyon zavaros. Az RDF kötés azért kell, hogy fel tudja dolgozni a gépi kliens, nem a megjelenítés része. Kétlem, hogy a gépi kliens az XSLT kimenetét kezdené el feldolgozni, ha kaphat XML-t, de végülis has szivatod az API felhasználóit, akkor nyugodtan lehet így is csinálni...
5

Gepi feldolgozasra alkalmas

MadBence · 2019. Jan. 4. (P), 15.15
Gepi feldolgozasra alkalmas formatumot szeretnel kuldeni a kliensnek, hogy allitsa elo a megfelelo reprezentaciot, de nem szeretnel JS-t hasznalni... nekem ebbol ugy tunik, hogy a gepi feldolgozas egyaltalan nem feltetel.

Nekem ugy tunik, hogy egy sima tablazatot szeretnel megjeleniteni a kliensen. Akkor csinald meg a tablazatot backenden, es el van intezve az egesz. Tok folosleges ide mindenfele transzformacio.
6

Nem teljesen. Szeretnék egy

mind1 valami név · 2019. Jan. 4. (P), 15.30
Nem teljesen. Szeretnék egy programmal feldolgozható adathalmazt előállítani.
Ha ez megvan, akkor valahogy meg is jeleníteném esetenként.
Weben erre két opciót látok:
1. Az adatok és a böngésző közé betolok egy programot, ami html-ben, formázottan küldi ki.
2. Elküldöm ezt az egészet a böngészőnek, az meg "kitalálja", hogy mit kezdjen vele. Erre lehet megfelelő akár az XML-XSLT (bár én úgy emlékeztem, hogy az xslt elavultnak lett kikiáltva évekkel ezelőtt), csak reméltem, hogy van egyszerűbb mód is.
7

Valakinek elo kell allitania

MadBence · 2019. Jan. 4. (P), 15.42
Valakinek elo kell allitania a HTML-t. Ez most vagy kliensen tortenik JS-el, vagy valami egzotikus XSLT transzformacioval, vagy a szerver megoldja, hogy tobb modon is el tudja kuldeni a kliensnek az adatokat. Ez a te dontesed, hogy szamodra melyik a legegyszerubb/legkenyelmesebb.
8

Végülis az volt a lényeg,

mind1 valami név · 2019. Jan. 4. (P), 16.09
Végülis az volt a lényeg, hogy van-e egyszerűbb erre az XML-nél, de úgy fest, hogy esetemben az az egyszerűbb, ha a szerver eleve HTML-t küld, különben több vele a nyűg, mint amit nyerek azzal, hogy a web szerverem egyben API-ként is funkcionálhat. :)
10

Hát ez pl jogosultság

inf · 2019. Jan. 5. (Szo), 08.45
Hát ez pl jogosultság függvénye is lehet. Nekem tisztábbnak tűnik, ha csinálsz egy külön service-t, ami az adatot szolgáltatja, aztán az egyik kliense a feldolgozó programod, a másik kliense meg a webalkalmazásod, ami HTML-t állít elő. Igy nem kell beletanulnod a böngészős technológiákba teljesen feleslegesen. Elméletileg vagy olyan szinten Python-ból, hogy meg tudd csinálni.
11

Mindenre külön service...

Pepita · 2019. Jan. 7. (H), 08.58
Alapjában véve egyetértenék, de nem tudjuk a feladat komplexitását, és a témaindítóból kiindulva egy "valamekkora", egyszerűnek tűnő adattömbről van szó.
Erre külön service-t + klienseket írni szerintem ágyúval a verébre, bár tény, hogy tisztább szárazabb érzés, csak sok munka.
Nagyjából inkább Bencével értek egyet: simán egy webalkalmazás, ezen belül is legyen egy réteg, ami előállítja az adatot, egy másik réteg, ahol különböző kimeneteket generál belőle.
Egyszerű MVC framework-kel megoldható, és nem kell kliensekkel se bajlódni.
12

Ja, azt is lehet, csak már

inf · 2019. Jan. 7. (H), 12.48
Ja, azt is lehet, csak már előtte valami socket-es témával szórakozott, aztán ez szerintem ahhoz kapcsolódik.
13

Nincs igazi feladat, csak

mind1 valami név · 2019. Jan. 7. (H), 14.39
Nincs igazi feladat, csak unatkozom és amíg még látok valamennyire, addig próbálom ilyen hülyeségekkel elfoglalni magam.

De még mindig a régi: van egy log szerverem, a rajta tárolt logokat akarnám majdan webről nézegetni.
Gondoltam, hogy a kigyűjtött adatokkal nem sokat szórakoznék szerver oldalon, a gépi feldolgozásra alkalmas formátum mindenképpen szükséges, kihagynám a html-lel való játékot szerveren, küldeném az egészet a browsernek úgy, ahogy előállt.
De úgy tűnik, sokkal egyszerűbb, ha mégis berakok egy kis konvertert, ami html-t csinál a nyers adatból, mert minden egyéb megoldás sokkal több munkával/tanulnivalóval jár.
14

Igy is úgy is HTML-re kell

inf · 2019. Jan. 7. (H), 15.20
Igy is úgy is HTML-re kell alakítanod, ha böngészőben akarod nézni. Akkor meg már egyszerűbb a szerveren.
15

Csak bíztam benne, hogy van

mind1 valami név · 2019. Jan. 7. (H), 15.27
Csak bíztam benne, hogy van rá valami primitív eszköz, ami ezt kliens oldalon megoldja. :)
16

Semmi sem megy varázsütésre,

inf · 2019. Jan. 7. (H), 17.07
Semmi sem megy varázsütésre, ott még nem tartunk.
17

Attól függ... XML-t pl. meg

mind1 valami név · 2019. Jan. 7. (H), 17.15
Attól függ... XML-t pl. meg tud jeleníteni a legtöbb böngésző, mindenféle hókuszpókusz nélkül, viszonylag formázott állapotban.
Más kérdés, hogy ez nem végfelhasználóknak való.
18

XML

Hidvégi Gábor · 2019. Jan. 7. (H), 18.30
Ha valami egyszerű és kompatibilis dolgot keresel, akkor ajánlom figyelmedbe az XML transzformációkat stíluslappal.

alap.xml:
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="alap.xsl" ?>

<gyoker>
  <fejlec>Cím</fejlec>
  <bejegyzesek>
    <bejegyzes>Első bejegyzés</bejegyzes>
    <bejegyzes>Második bejegyzés</bejegyzes>
  </bejegyzesek>
</gyoker>
alap.xsl: 
<?xml version="1.0" encoding="UTF-8" ?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:output method="html" version="1.0" encoding="utf-8" doctype-public="-//W3C//DTD HTML 4.01 Transitional//EN" doctype-system="http://www.w3.org/TR/html4/loose.dtd" />

<xsl:template match="gyoker">
  <html>
    <head>
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
      <title>Engem érdeklő adatok</title>
    </head>
    <body>
      <xsl:apply-templates />
    </body>
  </html>
</xsl:template>

<xsl:template match="fejlec">
  <h1><xsl:value-of select="." /></h1>
</xsl:template>

<xsl:template match="bejegyzesek">
  <table>
    <xsl:for-each select="bejegyzes">
      <xsl:call-template name="bejegyzes" />
    </xsl:for-each>
  </table>
</xsl:template>

<xsl:template name="bejegyzes">
  <tr>
    <td>Felirat:</td>
    <td><xsl:value-of select="." /></td>
  </tr>
</xsl:template>

</xsl:stylesheet>
Hogyan működik?

  • megnézzük, hogy van-e a gyökér elemet feldolgozó sablon, van (<xsl:template match="gyoker">)
  • elkezdjük legenerálni a benne lévő HTML kódot
  • eljutunk a <xsl:apply-templates />-ig, ez azt csinálja, hogy az aktuális kontextuson belül fog minden gyerek elemet, és alkalmazza rájuk a sablonokat
  • az aktuális kontextus: <gyoker>, ennek a gyerek elemei: <fejlec> és <bejegyzesek>
  • meghívjuk a <fejlec>-et feldolgozó sablont, ami kitesz egy <h1>-et
  • meghívjuk a <bejegyzesek>-et feldolgozó sablont, ami létrehoz egy táblázatot
  • végigiterálunk az összes <bejegyzes> elemen, és meghívjuk a "bejegyzes" nevű sablont
19

Ez már más, mint amiről én

mind1 valami név · 2019. Jan. 7. (H), 18.35
Ez már más, mint amiről én beszéltem. Nézz meg stíluslap nélkül egy xml-t mondjuk firefoxból... csak erre gondoltam.
20

Ismerem

Hidvégi Gábor · 2019. Jan. 7. (H), 20.21
Igen, ismerem. A böngésző alapból nem tud vele mit kezdeni, de a fenti példából láthatod, hogy gyerekjáték HTML-t készíteni belőle.
21

XML vs JSON

Pepita · 2019. Jan. 8. (K), 11.29
Mindkettővel van némi matek, mire html lesz belőle, de talán épp ezért érdemes szerver oldalon megcsinálni (a html-t is), mert kevesebb transzformációval megoldható.
Az eddigiek alapján úgy néz ki, hogy lesz egy valamekkora adattömböd, mint "nyers adat".
A html kiszolgálód nyugodtan foreach-elhet rajta és rajzolgathatja a html-t, nem kell se XML-lé, se JSON-né parsolni hozzá.
Aztán - ha a JSON-t választod - a gépi feldolgozó kiszolgálásához csak ráhívsz egy json_encode - ot és kész is vagy.

Ha a nyers adatból minden feldolgozó számára előbb XML-t vagy JSON-t csinálsz, akkor mindenképp többször fogod átalakítani.
22

JSON csak azért jött a képbe,

mind1 valami név · 2019. Jan. 8. (K), 11.33
JSON csak azért jött a képbe, mert egy dictrionary-ben tárolt adathalmazt egyetlen paranccsal oda-vissza tudok konvertálni. A gyűjtött adatok meg többnyire ilyesmiben lesznek. XML meg úgy, hogy talán azt is elő lehet állítani hasonlóan "bonyolult" módon pythonból.