Čtete statickou verzi tohoto blogu. Nové články autora nalezenete v angličtině na blogu Restafari.

Ruby on Rails a revoluce ve vývoji pro web. Část třetí: Controller a view

Kategorie: Rails

Publikováno 03. 07. 2007 v 02:18

13 komentářů (poslední napsal/a Sharboorb)


V minulých dvou článcích (první část, druhá část) jsme se zabývali základními principy programovacího jazyka Ruby a frameworku Ruby on Rails, s konkrétním výkladem o jeho části Active Record (tedy onomu M v MVC). V dnešním článku bych chtěl pokračovat výkladem o zbývajících dvou součástech MVC: Controlleru a View. V článku následujícím náš úvod o tom, co je na Ruby on Rails pro programátory tak uchvacující, dokončíme.

URL jako rozhraní aplikace

Prozatím jsme si probrali jen jednu část z Model-View-Controller schématu, tedy model implementovaný pomocí návrhového vzoru ActiveRecord. Typická (nejen) webová aplikace potřebuje nejenom přistupovat ke zdrojům dat, ale také sbírat požadavky zvenčí a prezentovat na jejich základě výstup. Základním prvkem tohoto principu je směrování, anglicky routing, které zajištuje, že aplikace „ví“, na jaké prvky má směrovat konkrétní požadavek.

Typickým takovým „požadavkem zvenčí“ je pro webové aplikace URL, ať již je návštěvník zadá přímo, či klepne na odkaz nebo tlačítko ve formuláři. Dlouho se URL ve webových aplikacích bralo jako pouhý transportní mechanismus, u něhož nezáleží na tom, jak vypadá, jak je dlouhý, zda je čitelný. Proto jsme se setkávali (a leckdy i dnes setkáváme) s URL ve tvaru:

http://example.com/exec/default?action=list&template=article_list&currPage=2&order=DESC&showonly=title,perex& …

Takové URL má dvě základní vlastnosti: je maximálně pohodlné pro programátora a maximálně nepohodlné pro uživatele. Avšak dle pregnantního vyjádření Jakoba Nielsena je URL součástí grafického rozhraní aplikace. Lidé si URL posílají e-mailem, diktují do telefonu a dle výzkumné zprávy Microsoftu (PDF, 650KB) věnují až čtvrtinu času stráveného prohlížením výsledků vyhledávání právě „adresám stránek“.

To, že se v současné době setkáváme s „lidštějšími URL“ (pretty URL nebo user-friendly URL), je v určité míře způsobeno masivní evangelizací odborníků na použitelnost, daleko více však důležitostí, kterou na současném webu hraje optimalizace pro vyhledavače. I programátoři si uvědomili (nebo je k tomu někdo donutil), že pokud „nejste na Googlu“, váš web jakoby nebyl, a téměř všechny content management systems se dnes chlubí tím, že generují „SEO-friendly URL“.

Při tvorbě správného URL je třeba dodržet minimálně dva základní principy: odhadnutelnost a reprodukovatelnost. To znamená, že běžný návštěvník ze samotného URL odhadne, co za obsah jej asi na dané adrese čeká („výpis článků nebo detail článku?“) a že URL vrací stále tentýž dokument (např. pokud URL někomu pošlu e-mailem), a obsahuje úplné informace k jeho zobrazení (proměnná lang tedy např. není uložena v cookie nebo session). (Existují samozřejmě výjimky, jako je adresa http://blog.example.com/latest-posts nebo http://blog.example.com/posts-since-your-last-visit. Zvláště v kontextu blogů se podobné problémy řeší tzv. permalinky, odkazy na komentáře ve tvaru http://blog…/#comment-45, apod.)

Řekli jsme, že typickým požadavkem zvenčí u webové aplikace je URL. Takové URL může v (téměř) ideálním tvaru vypadat např. takto:

http://www.example.com/article/show/1

Je zjevné, že toto URL velmi pravděpodobně zobrazí (show) nějaký článek (article) s identifikačním číslem 1 — je tedy velmi dobře odhadnutelné. To, co je zjevné člověku, ale stroje samy od sebe neví. Aby to „věděly“, je třeba jim to „říci“. Jak tedy Rails říkají stroji, co a jak zobrazit?

Direktivy, které routing řídí, jsou v Rails obsaženy v souboru config/routes.rb. Nepřekvapí nás, když tam najdeme tuto direktivu:

map.connect ':controller/:action/:id'

Rails vycházejí v této základní route z jednoduchého principu: první entita, na kterou v URL narazíme, je zároveň první dělící čárou aplikace v MVC architektuře — který controller převezme požadavek? Druhá entita je další dělící čárou — která metoda (akce) tohoto controlleru převezme požadavek? A konečně, této metodě je třeba předat nějaké parametry (např. ID stránky, způsob řazení výpisu, apod.)

90% všech routes v typické webové aplikaci je tvořeno právě takto: zavolej určitou metodu nějakého controlleru a předej jí nějaký identifikátor nebo jiný parametr. Rails obsahují tuto direktivu již v čisté instalaci a není třeba ji stroji zvlášť sdělovat. V typické aplikaci si s touto direktivou vystačíte a další ani nebudete muset přidávat.

Stačí tedy, když dodržíte tuto strukturu URL, a vaše aplikace bude „sama od sebe vědět“, co si má s požadavkem počít. Tento typický scénář ilustruje následující schéma:

Schéma směrování (routing) v Ruby on Rails

Protože routes je samozřejmě třeba stejně snadno číst jako vypisovat (typicky ve view), Rails obsahují pohodlné a čitelné generátory routes:

<%= link_to "Celý článek", :controller => 'article', :action => 'show', :id => article.id %>
=> <a href="/article/display/1">Celý článek</a>

Routing v Rails je samozřejmě velmi sofistikovaný (a odstiňuje vývojáře od direktiv pro mod_rewrite podobně, jako ActiveRecord od SQL). Nyní zmíníme jen jeden velmi poutavý koncept: koncept pojmenovaných routes, kdy určité pravidlo není „anonymní“, jako v našem příkladě výše, ale má svůj identifikátor, pomocí něhož se pak na pravidlo můžeme odkazovat. Místo uvedeného příkladu stačí použít jiný výraz než connect a nakonfigurovat pravidlo o něco složitěji:

map.show_article 'article/show/:id',
                                    :controller => 'article',
                                    :action     => 'show',
                                    :id         => /\d+/

Překlad: toto pravidlo zachytí URL, které začíná výrazem article/show, který následuje číslo (onen regulární výraz \d+, tedy alespoň jedno číslo). Kromě větší flexibility a případně i přehlednosti routovacích pravidel mají pojmenované routes jednu velkou výhodu: lze je volat ve views, takže místo relativně komplikovaného kódu:

<%= link_to "Celý článek", :controller => 'article', :action => 'show', :id => article.id %>

můžeme napsat velmi čitelně:

<%= link_to "Celý článek", show_article_url(:id => article.id) %>

Koncept pojmenovaných routes krásně ilustruje eleganci Rails. Transparentní routing, který člověka zbaví nutnosti konfigurovat a ladit nevyzpytatelný mod_rewrite je balzám na nervy vývojáře. Ale pojmenované routes, které umožní celý seznam pravidel zpřehlednit a učinit čitelný, a navíc je lze využít v Rails pro ušetření psaní dalšího kódu, to už je téměř živá voda. „Méně kódu!“ (less code!) je základní mantra vývoje v Rails, která úzce souvisí s filosofií „Nepiš to dvakrát!“ („Don't repeat yourself!“ neboli DRY) — tedy že vše by mělo být deklarováno jen jednou a na jednom místě.

Propojení controller ↔ view

Dosud jsme si ukázali, jak Rails řeší práci s daty v databázi a jak prostřednictvím routingu vědí, kterou část kódu mají vykonat při jakém požadavku. Jak ale Rails vědí, který view je třeba kdy zobrazit, a jak si data mezi jednotlivými komponentami předávají? Jak je vlastně uspořádána ta část aplikace, která řeší zobrazení uživateli?

Právě propojení mezi logikou aplikace a výstupem v HTML stránce je jednou z nejbolestivějších oblastí vývoje pro web. Diskuse o „správném“ přístupu k šablonám (tedy prezentační vrstvě aplikace) jsou jedny z nejžhavějších, a v kontextu webového vývoje se stále dokola rozebírá, zda může šablona obsahovat interpretovatelný kód, co tento kód „smí“ a „nesmí“, co je „srozumitelnější“ pro web designéry (takže vznikají „šablonovací systémy vytvořené pomocí šablonovacích systémů“) a podobně. Pro všechny možné jazyky existuje nespočet šablonovacích systémů s různou mírou striktnosti, čistoty a komplexity. Šablony jsou umisťovány ve složkách s různými názvy, různými příponami, a vztah mezi šablonami a controllery je začasté přinejmenším neodhadnutelný.

Jednoduchá definice „šablony“ v kontextu webové aplikace praví, že se jedná o HTML kód s „dírami“, do nichž se leje dynamický obsah, poskytovaný aplikací, tedy ono typické <p>Ahoj, {NAME}</p>, kde {NAME} je nahrazeno za Honzo. Koncept šablony ovšem přestává být takto prostý, jakmile začneme řešit výpisy v cyklu, střídání barev pozadí řádků tabulky, zobrazení obsahu pouze určitému uživateli, a jinou složitější logiku, které se v promyšlenější aplikaci nevyhneme.

Klasický akademický přístup reprezentuje např. StringTemplate Terence Parra, který rozhodně stojí za pozornost, zajímá-li vás problematika šablonovacích systémů hlouběji. (Děkuji Jiřímu Gruntovi za jeho připomenutí.) StringTemplate se (úspěšně) snaží o naprosté oddělení logiky aplikace od view a jedná se o velmi robustní koncept. Mementem pro všechny koncepty šablonovacích systémů je vyjádření Terence Parra: „Vypadá-li vaše šablona jako program, pak to asi bude program — podařilo se vám dokonale zamotat model a view dohromady“. A takové „zamotání“ je pro skutečnou Model-View-Controller architekturu nepřípustné.

Rails tento oříšek řeší velmi pragmaticky a dle dikta Davida Heinemeiera Hanssona, že správné techniky by měl nástroj podporovat, resp. k nim ponoukat, nikoliv je od vývojáře vyžadovat. Rails nepoužívají žádný „šablonovací jazyk“ (template language), HTML šablony Rails (.rhtml soubory ve složce app/views) obsahují „úplně normální“ Ruby kód, tzv. ERB neboli Embedded Ruby. Nevymýšlejí a nepoužívají tedy nějaké „jiné if“ nebo „jiný foreach“ (jak mají autoři šablonovacích systémů velice v oblibě), ale „úplně normální“ Ruby příkazy if … end, each … end, atd.

Na koncepci view v Rails je velmi sympatická maximální jednoduchost a vynalézavé uplatnění pravidla „konvence má přednost před konfigurací“. Mnohé nám díky znalosti routingu bude ihned srozumitelné.

Rails rozlišují obecnou šablonu celé aplikace nebo její části (typicky controlleru): layout, od šablon pro konkrétní výstupy (typicky metody controlleru): template. Layout obsahuje obecnou „skořápku“ aplikace — sekci <head>, záhlaví, zápatí — a template pak „maso“ stránky. Pokud Rails najdou ve složce app/views/layouts/ soubor application.rhtml, použijí jej automaticky jako obecný layout pro všechny controllery — dokud nenaleznou jinou konvenci nebo konfiguraci. Tohoto faktu můžeme skvěle využít, a speciální HTML layout vytvářet jen pro určité controllery.

Vyjdeme z toho, že máme controller nazvaný Article (viz app/controllers/article_controller.rb), s metodami index, list a show:

class ArticleController < ApplicationController

  def index
        # logika metody...
  end

  def list
        # logika metody...
  end

  def show
        # logika metody...
  end

end

Chceme mít pro tento controller zvláštní layout, odlišný od obecného v application.rhtml. Rails pro tento controller automaticky použijí layout ze souboru article.rhtml, pokud takový soubor ve složce app/views/layouts naleznou. To je konvence, kterou je velmi dobré v Rails dodržovat — kromě toho, že si (opět!) ušetříme spoustu psaní, struktura aplikace bude zas o něco srozumitelnější (nejenom vám, ale i někomu jinému, a to dle známého pravidla znamená i „vám po 2 letech“). Controller Page tedy používá layout page.rhtml, controller User layout user.rhtml, a tak dále. Nám pak stačí pouze tyto soubory vytvořit ve složce app/views/layouts, naplnit HTML, a Rails se postarají o ostatní.

Samozřejmě můžeme pro určitý controller použít i zcela jiný layout — jako téměř vše v Rails, je to otázka jednoduché konfigurace:

class ArticleController < ApplicationController
    layout "clanek"
    # zbytek logiky controlleru...
end

Rails pak budou layout pro controller Article hledat v souboru app/views/layouts/clanek.rhtml. Ba co víc! Layout můžeme klidně deklarovat dynamicky, podle stavu aplikace, typu požadavku nebo třeba (nesmyslně) IP adresy, z níž přichází HTTP požadavek (příklad je převzat z knihy Agile Web Development With Rails):

class StoreController < ApplicationController

    layout :determine_layout

    private

    def determine_layout
        if Store.is_closed?
            "store_closed"
        else
            "standard"
        end
    end

end

Podle toho, jakou hodnotu vrátí metoda Store.is_closed? (opět si povšimněte skvělého použití otazníku v Ruby, je zcela jasné, že metoda vrací booleovskou hodnotu) se použije layout store_closed nebo standard.

Náš controller Article, jak vidíme, má tři metody: index, list a show. Poslední dvě budou (nepřekvapivě) vypisovat seznam článků a zobrazovat konkrétní článek. Metoda index je specialita Rails: je volána, pokud voláme v URL samotný controller bez nějaké metody/akce — tedy např. http://example.com/article. (Povšimněte si, jak je elegantně nazvána podle názvu implicitně načítaného souboru na webovém serveru: index.html)

Šablony pro tyto metody jsou pak (nepřekvapivě) uloženy ve složce article ve složce app/views. Každé metodě pak odpovídá .rhtml soubor: index.rhtml, list.rhtml a show.rhtml — název souboru je tedy shodný s názvem metody. Není třeba nějak výslovně zobrazení toho view „volat“ nebo „konfigurovat“, aplikace provede kód metody a zobrazí šablonu.

Pro metody mohou též existovat šablony pro zobrazování jiného typu obsahu, např. XML (.rxml) nebo specificky pro Rails Javascriptu (.rjs), které se využívají zvláště pro práci s Ajaxem — metody controlleru mohou vracet jiný typ obsahu (klidně i obrázkový graf místo HTML tabulky) podle typu požadavku. K tomu se ještě vrátíme v některém z příštích článků o Ajaxu.

Struktura prezentační vrstvy aplikace je pak zobrazena na obrázku níže. (Tuto demonstrační miniaplikaci si můžete stáhnout (ZIP, 80KB), pokud si chcete propojení controlleru, jeho metod a views vyzkoušet sami.)

Views v Ruby on Rails

Vidíme, že díky jednoduché korespondenci: název controlleru = název layoutu a název metody = název šablony nám Rails (jako obvykle) šetří nejenom psaní kódu, ale především vymýšlení a konfigurování těchto vztahů. Právě tyto chytré vlastnosti Rails způsobují, že při psaní kódu máte pocit, že vám „počítač rozumí“, že programování nemusí být útrpná dřina a snaha přimět počítat vykonávat nějaké „příkazy“. Aplikace funguje jakoby „sama od sebe“ — stačí respektovat jednoduchá a velice přirozená pravidla: název metody je stejný jako název šablony, název controlleru je stejný jako název layoutu.

Pro určitou metodu však můžeme velmi triviálně použít zcela jiný layout:

def show
    # logika metody...
    render(:template => 'zobraz')
end

a to buď k dobru nebo ke škodě naší aplikace.

Dosavadní — snad až příliš rozsáhlý — exkurz měl sloužit k ilustraci nejvýraznější vlastnosti Ruby on Rails:

Rails obsahují téměř nejucelenější soubor best practices pro webový vývoj a design.

Jednoduchá, pragmatická a přitom maximálně promyšlená pravidla pro vztahy mezi controllery, jejich metodami a šablonami mají charakter „platinového standardu“. Těžko lze vymyslet něco chytřejšího při zachování stejné míry obecnosti a zároveň jednoduchosti. Téměř ve všech ostatních aspektech (např. hned za okamžik při výkladu o Embedded Ruby v HTML) potkáme v Rails identický přístup: zde je určitá „doporučená technika“, best practice, a je jen na vás, zda-li jejího intelektuálního přínosu využijete či budete vymýšlet „vlastní cesty“. Téměř vše lze v Rails ohnout, znásilnit, udělat „jinak“.

Ke správným technikám vás Rails, podobně jako Ruby, nenutí, jen je doporučují. Klasické vyjádření Yukihira Matsumota zní: „Globální proměnné začínají znakem dolaru. To vypadá dost ošklivě, takže vás to odrazuje od jejich používání“ (Přednáška „The Power of Ruby“). Je to ošklivé, takže by se to tak nemělo dělat… máloco shrnuje filosofii Ruby tak výstižně. Právě z těchto pozic vycházel David Heinemeier Hansson, když Rails navrhoval.

„Pohleďme na vývojáře. Po jeho levici stojí ďábel, po jeho pravici anděl. (…) V určitých situacích a za určitých podmínek je ďábel mocnější než anděl. (…) Ďábel praví například: ó, na tom nezáleží — tohle můžeš vždycky vylepšit později, k tomu se můžeš vždycky vrátit, nezáleží na tom, zda Petr ví, jak tohle funguje, ty víš, jak tenhle algoritmus funguje, a to z tebe dělá cenného zaměstnance. (…) Snažíme se ze všech sil, abychom do Rails vtělili anděla. [Vezměte si například] tyto konvence. Snažíme se, aby pro vás v Rails bylo jednodušší dělat věci správně a čistě než hackovat. Musíte se dost snažit, aby se vám povedlo udělat něco ošklivého. Musíte hrubě porušit nějakou konvenci a přidat nějakou konfiguraci, abyste vytvořili něco nekonzistentního. (…) Všude v Rails se snažíme klást tyto „pozvánky“, jak dělat věci lépe.“

~ David Heinemeier Hansson: Happy Programming and Sustainable Productivity with Ruby on Rails, přednáška na konferenci Future Of Web Applications, únor 2006

O vztahu mezi controllery a views tedy již víme hodně z koncepčního i praktického pohledu. Vynikající instruktáž o views v angličtině naleznete mj. v epizodě „All about layouts“ na Railscasts, kde Ryan Bates pravidelně publikuje screencasty o Rails.

Jak ale Rails předávají data do views? K tomu jsme se ještě nedostali. Je to opět velmi prosté: proměnné, které controller nastaví, jsou přístupné ve view. Představme si typický scénář, kdy chceme mít ve view dostupný objekt, obsahující data o článku s ID 1. (Tomu odpovídá URL ve známém tvaru: http://www.example.com/article/show/1.) Pomocí ActiveRecord data přečteme z databáze a uložíme do proměnné @article. (Zavináč před názvem proměnné znamená, že proměnná bude platit pro celou instanci controlleru a bude dostupná i ve view. Pokud bychom proměnnou nazvali article (bez zavináče), platila by pouze v rozsahu metody show — tedy jako lokální proměnná. O proměnných v Ruby si povíme více v některém z dalších článků.)

V controlleru tedy napíšeme:

# app/views/controllers/article_controller.rb
class ArticleController < ApplicationController

  def show
        @article = Article.find(params[:id])
  end

end

Ve view pak proměnnou @article můžeme jednoduše použít:

# app/views/article/show.rhtml
<h1><%= @article.title %></h1>
<div><%= @article.body %></div>
<hr />
<p>Publikováno dne: <%= @article.published_at %></p>

Výraz <%= otevírá onu zmíněnou „díru“ v HTML, kam prostřednictvím Embedded Ruby vypisujeme dynamický obsah (např. název článku: @article.title). V určité analogii odpovídá výrazu <?= v PHP. Pokud chceme v šabloně použít jinou logiku než prostý výpis proměnné do stránky, např. ověřit nějakou hodnotu pomocí if, použijeme podobný výraz bez rovnítka:

<% if @user.is_admin? %>
    <h2>Statistické informace o aplikaci:</h2>
    <p>Přihlášených uživatelů: <%= @application.logged_users_count %></p>
    ...
<% end %>

Tento přístup samozřejmě v jistém smyslu otevírá Pandořinu skříňku pro HTML prošpikované nekonečnými if … else sekvencemi, pro příliš logiky v šabloně. Rails jsou v tomto smyslu jednak nesmiřitelně pragmatické, jednak správné techniky doporučují, nikoliv vnucují, jak jsme probírali výše. Použití Embedded Ruby dává šablonám velkou moc — je na intuici a uvážení vývojáře, zda bude do šablony vkládat nepřehledné kusy logiky a jiné hacky či nikoliv. Čistě teoreticky lze tedy v HTML šabloně Rails napsat jakýkoliv Ruby kód, includovat knihovny, připojit se k databázi, a podobně.

V kontextu Rails je však takové nebezpečí relativně malé. Díky úspornosti a expresivitě Ruby každý nepřehledný kus kódu trčí ze šablony ven „jako šídlo z pytle“. Správné postupy, kterým se lze učit nejenom z ustrojení Rails samotných, ale i z ukázkových Rails aplikací, vás na dobré cestě vedou.

Podstatnější z praktického pohledu ale je, že Rails obsahují mnoho nástrojů pro to, že k hackování ve špatném slova smyslu nikdy ani nedojdeme. Jedním z těchto nástrojů jsou parciální šablony (partial templates), o nichž si povíme v některém článku, zabývajícím se Ajaxem. Daleko silnějším nástrojem je koncepce helperů, pomocných metod, do nichž se přesunuje logika z view. Rails obsahují mnohé helpery zabudované a disponují velmi transparentním mechanismem, jak si tvořit vlastní. O helperech si povíme hned v příštím článku, společně s výkladem o generátorech a konzoli, neocenitelných pomocnících při každodenním vývoji. Naše úvodní série článků skončí výkladem o pluginech pro Rails, tedy o práci energické komunity vývojářů, která nám může vlastní vývoj usnadnit a naše přemýšlení o webových aplikacích třeba nasměrovat na úplně jinou cestu…

Velké poděkování patří Vítku Burdovi za nepolevující kritický zrak, nezkalený „dobrým srdcem“ =)

~


13 komentářů

# 1
Ivan napsal před rokem:

Pises to velmi pekne a zrozumitelne Karle, snad to vydrzi dlhsie, ako 4 casti.

# 2
Jirka napsal před rokem:

Aaaa, skvěle! Konečně jsem pochopil propojení mezi cotrollers, views a layouts!

Díky!

# 3
Karel Minařík napsal před rokem:

@Ivan Určitě vydrží, po úvodních článcích budou následovat další. :)

@Jirka Rádo se stalo!

# 4
Misha napsal před rokem:

pěkné pokračování. jen technická poznámka, ty modré citace, resp. ten jejich levý okraj, který je odsazený doleva, nejdou přečíst pokud mám okno prohlížečě užší než maximalizované na šírku 1024px, na FF2.0

# 5
Karel Minařík napsal před rokem:

@Misha

Díky, zkusím to nějak poopravit pro menší rozlišení, jakmile vyjde čas.

# 6
Ivan napsal před rokem:

@Karel Ked sa uz spominalo to formatovanie ... neda mi ... co tak detail clanku roztiahnut na celu sirku, aj kod by sa potom zmestil do obalu :) Linky na posledne clanky by mohli byt dolu, medzi koncom clanku a komentarmi. Radost citat.

# 7
Jakub Podhorský napsal před rokem:

skvělý články :) sice dělám v PHP(se Zend Frameworkem kterej jak koukám se v Railsech opravdu hodně inspirovat skoro až mi to přijde jako kopie :)) tak po Ruby už nějaký ten pátek koukám a tvoje články mně začíají vnucovat myšlenku se na Ruby podívat pořádně

mimochodem...divím se že nepapíšeš knihu protože píšeš opravdu moc pěkně a čtivě(nejsem schopnej od toho odtrhnout zrak :))...máš můj obdiv

# 8
jan napsal před rokem:

Opet velmi peclive napsany clanek, diky za nej.

Citelnost a reprodukovatelnost URL jdou nekdy proti sobe, typickym prikladem budiz vyhledavani, kdy ja osobne preferuji presmerovani uzivatele na osklivou, ale copy-and-paste kompatibilni adresu.

Udelat kod v sablonach hezky, citelny a stravitelny i napr. pro designera, ktery Ruby nezna, neni myslim tak snadne, jak naznacujete. Nakonec to je jeden z duvodu, proc pro Railsy vznikly alternativni sablonovaci enginy (Liquid atp.) Vynikajici tipy, jak zprehlednit vase views, je pak zde: http://www.web2expo.com/presentations/rails2007/VisForVexing.pdf

Tesim se na dalsi clanky.

# 9
karf napsal před rokem:

Taky musím pochválit, pěkně napsané. Nicméně mám k tomu jisté poznámky:

URL typu http://www.example.com/article/show/1 se nedají považovat za SEO-friendly ani user-friendly, to je prostě to samé jako ten odstrašující příklad výše. Právě tyto URL jsou fajn pro programátory a pro systém, pro "vnější svět" by měly být přeloženy do srozumitelnější podoby typu http://www.example.com/nazev-clanku. Z výkladu jsem nepochopil, jestli RoR toto nějakým způsobem podporují.

Jinak ty emotivně zabarvené citace railsových evangelizátorů jsou srandovní a podporují ve mě pocit, že RoR je spíš než programovací jazyk a framework náboženství (nic ve zlém ;).

# 10
Josef Stříbný napsal před rokem:

@karf Právě, že Rails toto podporuje velice jednoduše a místo :id zadáte akorát :name a už to bude odpovídat SEO-friendly adrese :-).

# 11
Martin Stiborský napsal před rokem:

Zdravím. Paráda čtení, opět. Mám prosbu, šel by zařídit RSS export komentářů ? Děkuji

# 12
Karel Minařík napsal před rokem:

@Jakub

Díky! Zajímavý nápad, ona je však nejlepší knížka o Rails už bohužel napsaná :) — a český překlad se bohužel nepodařilo dojednat.

@jan

Díky za odkaz na PDF! Co se týče „programování v šablonách“, já se v praxi moc nesetkal s výtkami ze strany kodérů ani proti slušnému PHP. Pro ERB mluví stále síla, kterou šablonám dává. Liquid kupříkladu je hezký vynález, ale jen tam, kde má smysl: třeba v Shopify, pro uživatelem definované šablony, pro které ho Tobias Luetke vymyslel. Když jsem připravoval tento blog, tak jsem tisíckrát proklel autory Mephista za to, že jej defaultně použili místo ERB. :)

@karf

Velmi trefné, díky! Číselné ID je samozřejmě nepřátelské lidem i strojům skoro stejně jako to komicky špatné URL v článku. Nechtěl jsem tím výklad zatěžovat, a to bylo „šetření na nesprávném místě“. Rozhodně by mělo být URL právě tak, jak uvádíte, a aplikace by si je sama měla přeložit do „svého jazyka“.

Co se týče „náboženství“… každý si samozřejmě nadšení okolo Rails může přebrat jak chce. :) Faktem ale je, že spousty velice talentovaných programátorů na celém světě jsou jimi nadšené. Na přednáškách v Ostravě bylo jedním z nejčastěji používaných slov slovo fun. Lidi zkrátka Rails strašně baví, a moc se nestydí to dávat najevo. Já sám v tom vidím spíše radost, nadšení (které znám dobře od sebe) než nějaké „umění manipulace“, „dílo mistrů propagace“, apod., jak občas čítám na webu. :)

@karf & @Josef Stříbrný

Z výkladu jsem nepochopil, jestli RoR toto nějakým způsobem podporují.

Tak jednoduché, jak píše Josef, to rozhodně není. :) Klasicky se „manuálně“ řeší přetížením metody to_param modelu, kdy se k numerickému ID vytvoří nějaký ASCII slug, takové to klasické: http://www.example.com/article/23-hurikan-katrina-a-my. Jinak na to existují pluginy, ty však neznám z reálného nasazení.

@Martin

Jasně, mrknu, co umí Mephisto, mohl by to umět „sám od sebe“. Pokud ne, tak zkusím dopsat, jakmile vyjde chvilka. :)

# 13
Sharboorb napsal před 29 dny:

OK, let me repeat that… Are you becoming attached to my paperwork routines Do you want a joke? :) What is the biggest ant? An elephant.



Karel Minařík navrhuje a programuje webové stránky a aplikace s důrazem na čistý design a interaktivitu. Přednáší o web designu na Institutu Digitálních Médií a o Ruby na FF UK. Píše blog o Ruby On Rails, díky němuž ho opět začalo bavit programovat. Žije v Praze se svojí ženou a dvěma dcerkami, které mu to vše umožňují. Můžete mu napsat e-mail.

Karel Minařík is an independent web designer and developer with focus on clean UI and rich interactivity. He lectures on web design at Institut Digitálních Médií and on Ruby at FF UK. He writes blog about Ruby On Rails (in Czech), which re-ignited his passion for programming. He lives in Prague with his wife and two little daughters, who are making it all possible. You can send him an e-mail.

˜