ugrás a tartalomhoz

Tábla bővités

bnc1995 · 2012. Jún. 25. (H), 08.14
Sziasztok!

Az lenne a kérdésem, hogy hogyan tudnék egy gombnyomással bővíteni egy táblázatot új sorokkal?
Mindehhez elég a JavaScript, vagy valami más is kell hozzá?
<table>
<tr>
<td>egy</td>
<td>kettő</td>
<td>három</td>
</tr>
<tr>
<td colspan="3"><input type="button" name="plusz" id="plusz" value="+" onClick="" /></td>
</tr>
</table>
Most kezdtem el tanulni a JavaScriptet, és csak akadozva megy.

Valaki tudna adni nekem linkeket tutorialokról? Első sorban magyar nyelvűt, de jó az angol is.

Segítségeteket előre is köszönöm

Bence
‹ Background-repeat LIMIT? Szöveg buborék hiba ›
 ■
1

Sor

janoszen · 2012. Jún. 25. (H), 08.42
Minden soron végig kell menned és hozzá kell adnod egy TD-t. jQueryvel pl. emlékeim szerint így:

$('table tr').each(function(index, tr) {
    var td = document.createElement('td');
    td.appendChild(document.createTextNode('valami'));
    tr.appendChild(td);
}
4

Ez új oszloppal bővíti. Új

tgr · 2012. Jún. 25. (H), 09.46
Ez új oszloppal bővíti. Új sorral bővítéshez a legegyszerűbb duplikálni az utolsó sort ($('table').append($('table tr:last').clone())). Ha valamivel szebb megoldást akarsz, akkor érdemes valamilyen kliensoldali templating eszközt használni (pl. jQuery.tmpl).
5

XSLT

Hidvégi Gábor · 2012. Jún. 25. (H), 11.06
Szerintem nem túl jó ötlet külön kliensoldali sablonkezelést használni, mert akkor kétszer dolgozol, hisz ugyanazt meg kell írnod szerveroldalon is ahhoz, hogy elkészítsd az adott oldal html kódját.

Célszerűbb XSLT-vel elkészíteni az egészet, így több legyet üthetsz egy csapásra:
  • egyszer kell a kódot, az ellenőrzéseket stb. elkészíteni
  • javascript nélkül is működik
  • javascripttel könnyen megoldható, hogy csak a változásokat töltse le XML-ben, nem kell mindent
  • külön kezelheted az adatokat a megjelenítésüktől
6

Attól függ, mi a feladat. Ha

eddig bírtam szó nélkül · 2012. Jún. 25. (H), 11.32
Attól függ, mi a feladat. Ha történetesen arról van szó, hogy a felhasználó kap egy üres, egysoros táblázatot, ami ki kell töltenie és az új sorokat gombnyomásra kell hozzáadni...
Ezt hogy oldanád meg JS nélkül, pláne XSLT-ből?
7

Az üres sorok mezőiben is van

Hidvégi Gábor · 2012. Jún. 25. (H), 11.52
Az üres sorok mezőiben is van adat, null vagy üres karakterlánc, mindegy.

Példa XML:
<xml_reszlet>
<!-- sor létező adatokkal -->
  <sor_adatok>
    <mezo1>ertek1</mezo1>
    <mezo2>ertek2</mezo2>
    <mezo3>ertek3</mezo3>
  </sor_adatok>

<!-- új sor -->
  <sor_adatok>
    <mezo1></mezo1>
    <mezo2></mezo2>
    <mezo3></mezo3>
  </sor_adatok>
</xml_reszlet>
8

Ha javascriptből XSLT-zel, az

tgr · 2012. Jún. 25. (H), 12.25
Ha javascriptből XSLT-zel, az is külön kliensoldali sablonkezelés, csak éppen a létező legfájdalmasabb sablonnyelvben, ráadásul böngészőfüggő lesz az eredmény (és pont ugyanaz fog JS nélkül működni, ami amúgy is - pl. új sorokat biztosan nem fogsz tudni hozzáadni a táblához).
11

Ha javascriptből XSLT-zel, az

Hidvégi Gábor · 2012. Jún. 25. (H), 13.11
Ha javascriptből XSLT-zel, az is külön kliensoldali sablonkezelés
Teljesen mindegy, hogy hol fut, a lényeg, hogy nem kell kétszer elkészíteni a kódot ugyanahhoz a feladathoz.

ráadásul böngészőfüggő lesz az eredmény
Az XSLT 1.0-t mindegyik böngésző támogatja, én még nem találkoztam kompatibilitási problémékkal, de persze nem is zárom ki. Amelyiknek gondja van, annak szerveroldalon elkészítheted a HTML-t.

pl. új sorokat biztosan nem fogsz tudni hozzáadni a táblához
Miért is nem?
15

Teljesen mindegy, hogy hol

tgr · 2012. Jún. 25. (H), 13.52
Teljesen mindegy, hogy hol fut, a lényeg, hogy nem kell kétszer elkészíteni a kódot ugyanahhoz a feladathoz.


Kivéve, hogy mégis, mert pl. teljesen máshogy fogod valószínűleg az adatokat tisztítani, meg majdnem biztos, hogy a kliens- és szerveroldali motor nem működik teljesen egyformán. Elvben van egy csomó sablonnyelv, amit kliens- és szerveroldalon is használhatsz (pl. Smarty vagy Moustache), a gyakorlatban hasonló okból nem bíznék bennük nagyon, pedig ott még a böngészőfüggőség nem is játszik be.

Az XSLT 1.0-t mindegyik böngésző támogatja, én még nem találkoztam kompatibilitási problémékkal, de persze nem is zárom ki.


Pl: Opera's XSLT engine supports exslt:node-set, Mozilla/Firefox's XSLT engine doesn't in the current release, but does in the "Gran Paradiso" alpha tests for Firefox 3. Internet Explorer (6 and 7) don't support EXSLT, but do support the functionally identical msxsl:node-set function in the usual msxsl extension namespace. Igen, ez nem XSLT 1, és csak olyan ritkán használt dolgok vannak benne, mint pl. az URL encoding.

Amelyiknek gondja van, annak szerveroldalon elkészítheted a HTML-t.


Amely esetben lesz egy szerveroldali sablonmotorod, egy kliensoldali sablonmotorod, és egy másik kliensoldali sablonmotorod, ami a szerveroldalon fut. Máris minden sokkal egyszerűbb.

Miért is nem?


Javascript nélkül, dinamikusan? Hogyan?
19

Kivéve, hogy mégis, mert pl.

Hidvégi Gábor · 2012. Jún. 25. (H), 14.24
Kivéve, hogy mégis, mert pl. teljesen máshogy fogod valószínűleg az adatokat tisztítani
Kimenő adatokat minek akarsz sablonrendszerrel tisztítani?
majdnem biztos, hogy a kliens- és szerveroldali motor nem működik teljesen egyformán
Eltérés legfeljebb a Microsoft böngészőiben lehet, a többiek a libxml-t és a libxslt-t használják. Ettől függetlenül én biztos vagyok benne, hogy az XSLT 1.0-t mindegyik böngésző és szerveroldali szoftver ugyanúgy transzformálja.
Igen, ez nem XSLT 1, és csak olyan ritkán használt dolgok vannak benne, mint pl. az URL encoding
PHP is tud URL encodingot, bele lehet tenni egy új mezőbe és megoldottuk a problémát
Amely esetben lesz egy szerveroldali sablonmotorod, egy kliensoldali sablonmotorod, és egy másik kliensoldali sablonmotorod, ami a szerveroldalon fut.
Miért lenne? A sablonmotor abból áll, hogy van egy bemenő XML, egy bemenő XSLT, és egy kimenő HTML. Mivel mind szerver-, mind pedig kliensoldalon ugyanazok a bemenő adatok, a kimenő is ugyanaz lesz, azaz nem kell külön motort fejleszteni.
Javascript nélkül, dinamikusan? Hogyan?
Lásd 7-es hozzászólásomat
21

Kimenő adatokat minek akarsz

tgr · 2012. Jún. 25. (H), 15.08
Kimenő adatokat minek akarsz sablonrendszerrel tisztítani?


Pl. XSS kivédésére...

Ettől függetlenül én biztos vagyok benne, hogy az XSLT 1.0-t mindegyik böngésző és szerveroldali szoftver ugyanúgy transzformálja.


Azért én erre pl. mobil böngészőknél nem fogadnék nagy összegben.

PHP is tud URL encodingot, bele lehet tenni egy új mezőbe és megoldottuk a problémát


És akkor az eddigi három sablonrétegünk mellé van egy negyedik is, a PHP-ben végzett előfeldolgozás. Uhh.

A sablonmotor abból áll, hogy van egy bemenő XML, egy bemenő XSLT, és egy kimenő HTML. Mivel mind szerver-, mind pedig kliensoldalon ugyanazok a bemenő adatok, a kimenő is ugyanaz lesz, azaz nem kell külön motort fejleszteni.


De ha a kliensoldali kimenetet szerveroldalon generálod, azt el kell valahogy juttatni a kliensoldalra. Nem nehéz, de ez már a harmadik módja lesz a sablonkezelésnek -> egyre több apró inkompatibilitás (pl. abban, hogy pontosan mivé transzformálódik az invalid HTML).

Lásd 7-es hozzászólásomat


Nem látom, hogy oldja meg, hogy egy gombra kattintva beszúródjon egy új sor a táblázatba.
24

Pl. XSS kivédésére...Ezt nem

Hidvégi Gábor · 2012. Jún. 25. (H), 15.47
Pl. XSS kivédésére...
Ezt nem teljesen értem, kérlek, írj példát.
Azért én erre pl. mobil böngészőknél nem fogadnék nagy összegben.
Ezt rövid úton le lehet tesztelni.
És akkor az eddigi három sablonrétegünk mellé van egy negyedik is, a PHP-ben végzett előfeldolgozás. Uhh.
Ezt eddig is a szerveroldalon oldottad meg.
De ha a kliensoldali kimenetet szerveroldalon generálod, azt el kell valahogy juttatni a kliensoldalra.
Ezt hívják úgy, hogy HTML.
Nem látom, hogy oldja meg
Van egy bemenő XML-ed, amiben az utolsó sorban üres értékek vannak. XSLT transzformáció után ebből egy üres beviteli mezőket, táblázatokat stb. tartalmazó sor lesz. Megkapod a szervertől az XML-t, transzformálod Javascripttel a memóriában lévő XSLT-vel, az elkészült HTML fragmentet pedig beteszed a helyére, és már készen is vagyunk. Egy mai számítógépen ez annyira gyors, mintha a fenti jquery példa futott volna le, akár egy nagyon sok soros táblázatnál is.
18

Jogos

janoszen · 2012. Jún. 25. (H), 14.06
Jogos, tul koran volt, hajnalig videot vagtam. :)
2

tutorial

eddig bírtam szó nélkül · 2012. Jún. 25. (H), 08.48
Én a w3schools.com-ot szoktam használni, de ezt sokan nem szeretik. Ezen kívül, ha jól emlékszem, a tutorialspoint.com oldalon is találsz viszonylag jó anyagokat. (mindkettő angol)
3

Köszi

bnc1995 · 2012. Jún. 25. (H), 09.00
Köszönöm a segítséget
9

OFF: Itt nem tudom miért kell

Karvaly84 · 2012. Jún. 25. (H), 12.27
OFF: Itt nem tudom miért kell jQuery-vel példázni, kérdezőnk most kezdte el tanulni a JavaScript-et! A jQuery-vel nem lesz okosabb!

ON: table.insertRow, plusz létezik számos egyéb metódus amit DOM-on keresztül el lehet érni táblázat elemekre (táblázatra, sorokra, cellákra).
10

Javascriptet nem jQuery-vel

tgr · 2012. Jún. 25. (H), 12.57
Javascriptet nem jQuery-vel elkezdeni tanulni masszív mazochizmus szerintem. De ha gondolod, demonstrációképpen írd meg a 4-es komment snippetjét pure javascriptben, aztán beszéljük meg, melyik a könnyebben tanulható.
12

Ezzel

eddig bírtam szó nélkül · 2012. Jún. 25. (H), 13.16
Ezzel vitatkoznék.
Tapasztalatból mondom, hogy igen nagy szopásokkal jár, ha az ember nem az alapokkal kezdi a tanulást. :-(
14

Egyetértek

Hidvégi Gábor · 2012. Jún. 25. (H), 13.19
Komoly gondokat okozhat hibakeresésnél, ha nem tudod pontosan, mi hogyan működik.
16

Javascriptnél az igen nagy

tgr · 2012. Jún. 25. (H), 13.55
Javascriptnél az igen nagy szopások elkerülésének legbiztosabb módja, ha az alapok 90%-át messziről elkerülöd, és a natív DOM API tipikusan ide tartozik.
13

Valahogy így

Hidvégi Gábor · 2012. Jún. 25. (H), 13.17
var tabla = document.getElementsByTagName('table')[0];
var tr-ek = tabla.getElementsByTagName('tr');
tabla.appendChild(tr-ek[tr-ek.length - 1].cloneNode(true));
17

Ok, ebben az esetben még

tgr · 2012. Jún. 25. (H), 13.57
Ok, ebben az esetben még viszonylag fájdalommentes. De ha például a tábla minden sorában van valami gomb, és azon van egy eseménykezelő, és azt akarod, hogy az új sorban is legyen... good luck. Vagy ha nem csak egy táblád van, és osztálynév alapján akarod kiválasztani a megfelelőket. Vagy ha le akarod kezelni azt az esetet, amikor nincs tábla, vagy üres (mondjuk ezt én is elszúrtam, de jQueryben könnyű javítani). Vagy ha a tábla egyes celláiban lehetnek más táblák is stb.
20

XSLT

Hidvégi Gábor · 2012. Jún. 25. (H), 15.06
Ezért írtam, hogy nem érdemes kétszer fejleszteni, mert most az esetek 99,99%-ában ez történik. A programozó elkészíti a szerveroldali HTML generálását, amiben ugyanúgy benne van a táblákba ágyazott táblák elkészítése, aztán ő vagy a kollegája elkészíti a jquery scriptet, ami dinamikusan megcsinálja ugyanezt a kliensoldalon. Aztán, ha változtatni kell a későbbiekben, akkor azt is mindkét helyen el kell végezni.

XSLT-vel ez úgy megy, hogy a programozó elkészíti az XML-t, amiben a kimenő adatok vannak, és onnantól kezdve el is felejtheti a projektet. A sitebuilder legyártja az XSLT-t hozzá, és ha van javascript, akkor a kliensen, ha nincs, akkor pedig a szerveren készül el a HTML, aztán a kliens pedig eldönti, hogyan jeleníti meg.
22

Eltekintve annak a

tgr · 2012. Jún. 25. (H), 15.12
Eltekintve annak a problémájától, hogy mennyire hemzsegnek az XSLT-t használó sitebuilderek, illetve mennyivel lassabb programozni benne, mint emberi fogyasztásra szánt nyelvekben, jellemzően a szerveroldalon komplett HTML oldalakat akarsz gyártani, a kliensoldalon pedig meglébő oldalba HTML fragmenteket beszúrni. A kettőt csak Prokrusztész-ágy-jellegű megoldásokkal lehet egyesíteni.
23

illetve mennyivel lassabb

Hidvégi Gábor · 2012. Jún. 25. (H), 15.39
illetve mennyivel lassabb programozni benne, mint emberi fogyasztásra szánt nyelvekben
Mennyivel?
A kettőt csak Prokrusztész-ágy-jellegű megoldásokkal lehet egyesíteni.
Vagy elkészítheted ugyanannak a HTML-nek a legenerálását kétszer. Melyik a jobb?
25

Erre jutottam

bnc1995 · 2012. Jún. 25. (H), 22.31

<html>
     <head>
     <style type="text/css">
	 td{
		 border: 1px solid black;
	 }
	 </style>
     <script language="JavaScript">
	 function Plus(){
		 
		 
		 x = document.getElementById('table').innerHTML;
		 
		 l = x.length;
		 
		 y = x.indexOf('<tr>');
		 
		 z = x.lastIndexOf('<tr>');
		 
		 rows = x.substr(y, z-y);
		 
		 input = x.substr(z, 147);
		 
		 output = rows + '<tr><td><input type="text" /></td><td><input type="text" /></td><td><input type="text" /></td></tr>' + input;
		 
		 a = document.getElementById('table').innerHTML = output;
		 
	 }
	 </script>
     </head>
     <body>
          <div>
              <table id="table">
                    <tr>
                       <td>Egy</td><td>Kettő</td><td>Három</td>
                    </tr>
                    <tr>
                       <td colspan="3"><input type="button" id="plus" name="plus" value="+" onClick="Plus();" /></td>
                    </tr>
              </table>
          </div>
     </body>
</html>
26

Pár észrevétel

Karvaly84 · 2012. Jún. 26. (K), 07.45
Észrevettem, hogy XML stílusú lezárások vannak a kódban, viszont a gyökér elemben nem utalsz az XML szintaktikára.

Pl:

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title></title>
</head>
<body>

</body>
</html>
Ha HTML szitakszist követsz akkor a <input type="text" />, helyett a <input type="text"> lesz valid.

Továbbá, nincs dokumentum típus meghatározva ami lehet kellemetlen.

Ezen felül a script elemekben a "language" deprecated vagyis elavult.

<script language="JavaScript"></script>
<!-- helyett -->
<script type="text/javascript"></script>
27

XHTML?

eddig bírtam szó nélkül · 2012. Jún. 26. (K), 08.01
Ezt nem a DOCTYPE-ban illene megadni? Vagy megint lemaradtam valamiről?
28

Nem, mert nem lesz valid. A

Karvaly84 · 2012. Jún. 26. (K), 08.12
Nem, mert nem lesz valid. A DOCTYPE megmondja mik engedélyezettek az adott típusú dokumentumban és ez alapján olvassa a böngésző vagy más. Az XHTML az XML szintaktikájára épül, ezt pedig egy névtér deklarációval kell jelezni, praktikusan a gyökér elemben, az xmlns attribútum segítségével.
29

Lehet, hogy félreértjük

eddig bírtam szó nélkül · 2012. Jún. 26. (K), 08.43
Lehet, hogy félreértjük egymást? Vagy tényleg hiányosak az ismereteim? Így hirtelenjében nem tudom, hol kellene utánanézni: eddig úgy tudtam, a doctype adja meg, hogy az adott dokumentum milyen szintaktikával dolgozik (HTML, XHTML stb.) és ennek folyománya, hogy pl. a html tagben megadhatod az xmlns-t. Az más lapra tartozik, hogy a böngészők többsége az xmlns alapján felismeri, hogy mivel kell dolgoznia.
30

validáld ezt a lapot: Markup

Karvaly84 · 2012. Jún. 26. (K), 08.52
validáld ezt a lapot: Markup Validation Service

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>Insert title here</title>
</head>
<body>

</body>
</html>
Ez fog kijönni:
Line 2, Column 1: Missing xmlns attribute for element html. The value should be: http://www.w3.org/1999/xhtml

<html>

✉

Many Document Types based on XML need a mandatory xmlns attribute on the root element. For example, the root element for XHTML might look like:
<html xmlns="http://www.w3.org/1999/xhtml">
32

Nem erre gondoltam, hanem az

eddig bírtam szó nélkül · 2012. Jún. 26. (K), 09.03
Nem erre gondoltam, hanem az ellenkezőjére: ha doctype nélkül használod az xmlns-t, akkor (bár most néztem, a validator szerint így is valid, csak nem strict, hanem transitional) az a dokumentum sima html lenne(??? egyáltalán lehet valid egy ilyen lap a doctype nélkül?).
Más kérdés, hogy pl. a validator és a legtöbb böngésző felismeri doctype hiánya ellenére.
34

tegyük fel nincs doctype: 1.

Karvaly84 · 2012. Jún. 26. (K), 09.28
tegyük fel nincs doctype:

1. ha van xmlns deklaráció a validátor XHTML-nek olvassa, és elvárja, hogy a sort tagokat "/>"-el zárd nem pedig ">"-el.
2. ha nincs xmlns deklaráció a validátor HTML-nek olvassa, és elvárja hogy hanyagold a "/>" lezárást.

Itt az okozhat problémát, hogy pl. a böngészők nem biztos, hogy ugyan úgy találgatnak a dokumentum típust illetően mint a validátor.

továbbá valahol olvastam, hogy az IE kiakad egy ilyentől, de nem jártam utána teljesen a verziókat illetően:

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>Insert title here</title>
</head>
<body>

</body>
</html>
ugyan is a legelső sorban nem a doctype van és a IE átvált quirks módba, tehát nem strict xhtml-nek veszi. Mégeccer mondom ennek utána kéne járnom pontosan, de linuxomon nincs explorer.
31

köszi

bnc1995 · 2012. Jún. 26. (K), 08.59
Ezt a lezárást a szerkesztő csinálja automatikusan.

A language meg nem tudtam, hogy elavult.

köszi, hogy szóltál
33

empty element

tiku I tikaszvince · 2012. Jún. 26. (K), 09.22
Azért ez az <input /> nem valid HTML-ben dologgal kapcsolatban, egy kis pontosítás.

  • HTML4 esetén - ha nincs DOCTYPE a böngészők e szerint dolgoznak - Warning jár érte.
  • XHTML esetén ez a kötelező forma. Tehát nem lehet lezáratlan elem. Ilyenkor kötelező elem az általad említett xmlns feltüntetése is.
  • HTML5 esetén a fenti input forma teljesen szabályos.


De a megoldandó probléma szempontjából majdnem teljesen mindegy a dokumentum típus.
35

Az <input /> egyébként

tgr · 2012. Jún. 26. (K), 13.50
Az <input /> egyébként teljesen valid html 4, csak nem azt jelenti, amit várnál (hanem egy üres input taget és utána egy literális > karaktert - google kulcsszó: sgml shorttag).

Az xhtml validságán fennakadni default névterek és egyéb funkciótlan dolgok kapcsán viszont teljesen értelmetlen, mert valid xhtml nem létezik. Az xhtml szabvány megköveteli, hogy a mimetype application/xml legyen, amivel viszont mindannyiunk barátja, az IE nem tud mit kezdeni, ezért text/html+xhtml és hasonlókat szoktak használni, amik viszont nem validak, ezért a böngészők eleve html4 quirks módban olvassák (és a namespace deklarációt eldobják, mint html4-ben értelmezhetetlent).