<!–texy–>Podle mého parametrizované dotazy nejsou záležitostí PHP nebo Javy, ale záležitostí příslušného SŘBD.
Například já v PHP používám parametrizované dotazy typu
INSERT INTO tabulka(sloupec1,sloupec2) VALUES (:parametr1, :parametr2)
nad SŘBD ORACLE naprosto běžně.

Přiznám se, že s MySQL nemám moc zkušeností, takže nevím, zda i tento SŘBD podporuje parametrizované dotazy.

<!–texy–>100% souhlasím, že "escapovaná" data do DB nepatří. Escapovat HTML* by se mělo těsně před výstupem, už jen proto, že se nikdy nemůžeme spolehnout na to, že nějaký zlovolný uživatel nevloží ručně do DB svůj HTML kód.

Trochu mě zarazil ten příklad se SQL – copak v PHP nemáte parametrizované dotazy (jako třeba my v Javě)?

Texy bych do DB necpal** – to je lepší to HTML, ve smyslu "metajazyka", tedy nějaký formát založený na XML se značkami které používáme (klidně shodné s HTML značkami), se kterým při výstupu nebudeme pracovat jako s textem (načíst z DB a bezmyšlenkovitě plácnout do výstupu), ale jako s XML dokumentem, který ještě těsně před výstupem zvalidujeme, aby obsahoval jen povolené značky.

*) resp. filtrovat jen povolené značky.
**) ani jako rozhraní s uživatelem mi nepřijde nejvhodnější.

http://www.joelonsoftware.com/articles/Wrong.html

[7] Já ten "aspekt" nevidím v rozdílu mezi tím, který jazyk je víc nebo míň "meta". Jediným pravidlem by IMHO mělo být ukládání textu v jeho zdrojové podobě. To, v jakém formátu je tento zdroj pořízen je z hlediska MVC přece jedno. Zdrojová data obsahují vždy nejsémantičtější možnou informaci, jakoukoliv transformací do jiného formátu se může jenom tratit. Takže pokud uživatel vkládá v syntaxi Texy, ukládá se Texy, pokud vkládá HTML pomocí WYSIWYG editoru, ukládá se přirozeně HTML.

<!–texy–>[5] parádním příkladem je ukládání ukázek zdrojových kódů s obarvenou syntaxí. Pokud je ukládáme v HTML už s barvičkama, kód je pak těžko editovatelný. Lépe je ukládat v textové podobě s metaoznačením "tohle je kus PHP co má být obarven". Metainformace může být zapsaná i v HTML (třeba pomocí třídy u bloku PRE) – tím se z HTML udělá metajazyk.

Vlastně i značka ve WordPressu `<!– more –>` patří do stejné kategorie.

Příkladem XML metajazyku je například DocBook. Z něj se v pohodě vygeneruje HTML nebo PDF podle potřeby.

[5] Právě proto jsem v článku taky nechal tu výtku, že takovéhle praktické aspekty nakonec často převažují. Ideálně si to představuji tak, že by strukturovaný text měl být vyznačen nějakým metajazykem nezávislým na konkrétním formátu, který půjde snadno transformovat na libovolný výstup. Mým představám takovému metajazyku nejvíce odpovídá asi Texy!, ale může jím být samozřejmě například nějaké vlastní XML.

Anebo, a tím se vracíme zase na začátek, třebas i HTML. Ale pak je důležité vidět a cítit ten rozdíl mezi HTML jako metajazykem v databázi a mezi HTML jako jedním z mnoha možných výstupních formátů. To pak totiž ovlivní celý návrh aplikace s struktury jejích View.

[4] Neměl jsem zde na mysli nabízení více různých paralelních verzí View (tam samozřejmě musíš většinou skrze Controller nějak určit, které z nich požaduješ), ale to, že vezmeš v aplikaci jedno stávající View, dáš ho pryč a místo něj tam dosadíš jiné. To by mělo jít bez toho, aniž bys musel cokoliv měnit v Modelu nebo Controlleru. V reálné praxi tohle asi člověk použije málokdy, ale je to výborný příklad pro pochopení MVC, pro ilustraci, jak vlastně funguje, a pro jasné vymezení odpovědností a pravomocí jednotlivých částí aplikace.

Když píšete, že HTML do databáze nepatří, jak si představujete uložení strukturovaných textů se správným sémantickým označením textových prvků, jako jsou nadpisy, odstavce, seznamy atd.
Díky za info :)

Nezbývá mi nic jiného než souhlasit. Ale nahodil si téma, že renderování html nebo pdf ve view by nemělo nijak ovlivnit model nebo controller. No :) Přece jenom někde v kontroleru se musím rozhodnout, jestli budu chci výstup v html nebo pdf. Generování pdf obsahuje přece jenom nějakou aplikační logiku.

Díky za vysvětlení, teď už je mi ten rozdíl jasný :)