ugrás a tartalomhoz

Sablon vagy nem sablon

inf · 2011. Júl. 12. (K), 12.31
Üdv.

Arra keresem a kérdést, hogy melyik technológiát érdemesebb használni.

A sablon vagy nem sablon kérdését úgy értem, hogy ha mondjuk HTML generálásáról van szó, akkor a sablon esetében a fejlesztő írja a html kódot, a nem sablon esetében pedig vannak layout-ok, elemek, stb, amiket a kód generál.

pl:

<form action="{$action}">
<input type="text" name="x" id="x" />
</form>
helyett mondjuk:

$htmlBuilder->newDocument();
$htmlBuilder->addForm(array('action' => $action));
$htmlBuilder->addTextInput(array('id' => 'x'))
Az utóbbi módszernek annyi előnye van, hogy többféle dokumentumot lehet készíteni ugyanazzal a kóddal, a builder cseréjével, viszont cserébe macerásabb az egész.
‹ callback függvény - PHP bug? PHPMailer és foreach ›
 ■
1

sablon

Poetro · 2011. Júl. 12. (K), 12.52
Sablon, mivel
  • könnyebb formázni,
  • nem feltétlen kell fejlesztő ahhoz, hogy valaki módosítson benne,
  • áttekinthetőbb,
  • könnyebb debuggolni,
  • karbantarthatóbb,
  • minden valószínűség szerint gyorsabb.
2

Ahm, és ha mondjuk letárolom

inf · 2011. Júl. 12. (K), 21.22
Ahm, és ha mondjuk letárolom a nem sablonos dolgokat XML-ben, és abból generálok php fájlokat, akkor mi a szitu? :D
3

Ha értesz az XML-hez és

Hidvégi Gábor · 2011. Júl. 12. (K), 22.20
Ha értesz az XML-hez és XSLT-hez, akkor egyszerűbb és gyorsabb lehet a dolog.
4

Én mondjuk a cross-browser

inf · 2011. Júl. 13. (Sze), 00.12
Én mondjuk a cross-browser dolgok miatt gondoltam rá, hogy érdemes lenne így nekifutni. Mondjuk csinálok olyan layoutokat, mint java swing-ben, van, aztán az egyes böngészőkhöz csinálok külön fájlokat arról, hogy milyennek kell lennie a kimeneti html-nek ezekhez. Utána meg kb annyi lenne cross-browser kódot írni, hogy az XML sablonból XSLT-vel a fentiekhez hasonló php kódot generálok.

Persze ugyanezt meg lehet oldani úgy is, hogy csinálok sokféle újrahasznosítható sablont, és böngészőfüggővé teszem, hogy az egyes esetekben melyeket használom...

Meg persze meg lehet oldani XSLT-vel is, hiszen az is sablon.
5

Nem igazán értem, miért

Hidvégi Gábor · 2011. Júl. 13. (Sze), 07.39
Nem igazán értem, miért akarsz XSLT-vel PHP-t generálni, meg a cross-browser dolgot sem. Kis gyakorlattal simán lehet olyan HTML-t gyártani, ami minden böngészőben (1-2 pixel eltéréssel) ugyanúgy néz ki és ugyanúgy működik.
6

html vs css

Poetro · 2011. Júl. 13. (Sze), 11.03
Foleg mivel a megjelenes nem a html feladata, hanem a css-e.
7

Hát én már belefutottam olyan

inf · 2011. Júl. 13. (Sze), 16.10
Hát én már belefutottam olyan dologba, ahol az az 1-2 px is nagyon számított. Nem a kinézet szempontjából, hanem a koordináták miatt... Egyébként meg nekem kényelmesebb lenne, ha nem kellene a html+css résszel soha többet foglalkoznom, hanem egy program szépen legenerálná úgy, ahogy megmondom neki.
9

Elég ritka az ilyen. Ha meg

Hidvégi Gábor · 2011. Júl. 13. (Sze), 16.39
Elég ritka az ilyen. Ha meg nem akarsz ezzel foglalkozni, szerintem keress egy sitebuildert, aki megcsinálja, de a böngészőfüggő HTML-t szerintem ne nagyon erőltesd, mert csak a saját dolgodat nehezíted vele.
10

Ez csak egy elgondolás, hogy

inf · 2011. Júl. 13. (Sze), 16.42
Ez csak egy elgondolás, hogy hogyan lehetne platformfüggetlen view réteget csinálni. Bizonyos elemeket akár doc,pdf,jpg formában is meg lehet rajzoltatni.
11

Elvileg a GWT pont ilyen.

inf · 2011. Júl. 16. (Szo), 16.48
Elvileg a GWT pont ilyen.
8

Amúgy tényleg felesleges

inf · 2011. Júl. 13. (Sze), 16.34
Amúgy tényleg felesleges XSLT-t használni.

Nos az a koncepció, hogy építek egy fát a view elemekből. Ezek nem feltétlen hagyományos html elemek, lehetnek layout-ok is, stb... Amikor elkészült a fa, akkor vagy egyből behelyettesítem a változó részeket, vagy generálok belőle böngésző függő sablon kódokat. A lényeg, hogy amikor én a view réteget csinálom nem látok egy deka html-t sem. Ez az, ami megnyugtatna... :D

Az xslt úgy jött létre, hogy akár XML-ben is le lehet tárolni a view fát, amit parsolva megkapjuk a php objektumos változatot. Viszont ha már XML-ben van a cucc, akkor akár meg lehet azt is csinálni, hogy lefuttatok rá XSLT-ket, és úgy kapok html sablonokat.
12

Én most valami ilyesmiben

inf · 2011. Júl. 21. (Cs), 17.23
Én most valami ilyesmiben gondolkodom:

template/controller/link.tpl (class Template_Controller_Link)

<a href="{@onActivate}">
	<value-of match="@text" />
</a>
template/remote/get.tpl (class Template_Remote_Get)
http://<value-of match="/environment/@domain" />
/<value-of match="@controller" />
/<value-of match="@action" />
template/page.tpl (class Template_Page)
<html>
	<body>
		<controllerLink>
			<onActivate>
				<remoteGet>
					<controller>article</controller>
					<action>list</action>
				</remoteGet>
			</onActivate>
			<text>
				get article list
			</text>
		</controllerLink>
	</body>
</html>
html output

<html>
	<body>
		<a href="http://my.domain.net/article/list">get article list</a>
	</body>
</html>
Persze a végeredményt ennél azért komplexebb formában gondoltam... A tpl fájlok helyett meg inkább php osztályokra gondoltam, mert úgy gondolom, hogy egyszerűbb külön sablonnyelv helyett php-ben megírni ezeket. A lényeg, hogy az egyes helper osztályokat a sablonokban szabadon lehetne használni, a paraméterezést pedig ha sablonból hívják őket, akkor XML-ben kapnák meg, ha meg php-ből, akkor meg tömbként vagy objektumként...

new Template(
	'<html><body><value-of match="@content" /></body></html>',
	array(
		'content' => new Template_Controller_Link(
			array(
				'onActivate' => new Template_Remote_Get(
					array(
						'controller' => 'user',
						'action' => 'list'
					)
				),
				'text' => 'get article list'
			)
		)
	)
);
13

Kicsit jobban átgondolva

inf · 2011. Júl. 22. (P), 20.55
Kicsit jobban átgondolva minden dokumentumot le lehet írni ilyen formában:

<o1>
	<p1>
		<o2>
			<p1>property 1</p1>
			<!-- ... -->
		</o2>
	</p1>
	<p2>property 2</p2>
	<!-- ... -->
</o1>
Az o1 és o2 objektumokhoz O1 és O2 osztályok tartoznak p1 és p2 tulajdonságokkal. Ezek generálják a php kódot, amit a sablon fordításakor kapunk. A végén a sablon kiértékelésénél ezt a php kódot lehet felhasználni.

Maga sablon nem is feltétlen kell, hogy php kódot adjon végül, úgy is meg lehet oldani, hogy xsl kódot adjon vissza, és xml-t várjon paraméternek, de úgy is, hogy php kódot adjon vissza, és objektumot vagy tömböt várjon paraméternek.

Nyilván itt arról van szó, hogy lehetséges egy saját elemekből álló view réteget csinálni, és azt átláthatóan leírni XML-ben.
14

Nem akarom teleszemetelni a

H.Z. v2 · 2011. Júl. 22. (P), 21.04
Nem akarom teleszemetelni a topic-odat, küldök egy Template-et (az osztályt) mailben. Úgy érzem, kicsit túlbonyolítod a dolgot. Persze lehet, hogy csak én nem értem, mit miért...
15

Hát itt konkrétan arról van

inf · 2011. Júl. 23. (Szo), 01.34
Hát itt konkrétan arról van szó, hogy az xsl-nek van egy (szerintem) hátránya, az, hogy ha mondjuk egy oldalt xml+xsl-el csinál meg az ember, akkor nagyon széthullanak a sablonok ezer fájlra, és a végén már nehezen követhető, hogy mi hova tartozik, vagy egy nagyon nagy fájl az egész, ami szintén átláthatatlan, legalábbis nekem.

Ezzel a fajta tákolással, vagy kiegészítéssel lehetne egy átláthatóbb sablont csinálni, amit aztán megfelelő eszközökkel egy jó nagy xsl fájlra le lehet fordítani (vagy php-re, kinek mi tetszik). Egy kicsit belebonyolódtam az elején, de azért kiderült a végére, hogy mire is jó mindez.
16

Maradjunk annyiban, hogy

H.Z. v2 · 2011. Júl. 23. (Szo), 04.11
Maradjunk annyiban, hogy "kissé" félreértettem az eredeti problémád lényegét.
17

Az eredeti az volt, hogy

inf · 2011. Júl. 23. (Szo), 13.32
Az eredeti az volt, hogy objektumokkal vagy sablonnal csináljam e, aztán rájöttem, hogy ha objektumokkal csinálom, akkor az ok ugyanúgy sablonokat fognak használni. Ja meg hát ha objektumokkal csinálom, akkor azokat le lehet írni a most említett leíró xml-el. Ennyi történt. Egyelőre nincs kedvem megvalósítani ezt a rendszert, még az se tiszta, hogy xsl-el vagy php-val lenne e jó, meg hogy a leíró xml-ben lehessenek e xsl kifejezések vagy sem. Kicsit még mindenképp érnie kell a gondolatnak.