Visiškas puslapių ID TVS’e unikalumas: is this a feature or what?

Susimąsčiau…

Dabartinė VU TVS leidžia kiekvienam „tinklapiui“ (aka struktūriniam elementui, ar kaip kitaip bepavadintum) sukurti po du pavadinimus: vieną „gražų“, su tarpais ir praktiškai belenkokiais simboliais, o kitą — „techniškesnį“, be tarpų, diakritikų ir panašaus „išsikalinėjimo“. Pastarasis pavadinimas (aš jį vadinsiu ID, WordPress jį vadina „slug“) naudojamas, formuojant nuorodas. Tokiu būdu, pavyzdžiui, puslapis, kurį vartotojas mato „International Relations“ pavadinimu, nuorodoje gali figūruoti kaip „international“, o puslapis „Faktai ir skaičiai“ nuorodoje matomas kaip „faktai“. Savaime aišku, jog šie nuorodose naudojami identifikatoriai turi būti unikalūs. Tačiau yra vienas kabliukas — kiekvienas puslapis mūsų TVS’e yra priskiriamas konkrečia kalba identifikuojamam visiškai atskiram hierarchiniam medžiui, o šių medžių gali būti keli. VU svetainėje jie kol kas yra du — lietuviškas ir angliškas. Štai čia man ir iškilo klausimas — ar sistema turėtų leisti skirtinguose medžiuose kurti puslapius su vienodais ID, ar ne? Kiek mąstau, nenusprendžiu, kuris variantas geresnis. Abu turi šiek tiek pliusų ir minusų:

  • Leidžiant kurti vienodus ID, atsiranda trūkumas — nuorodose būtinai turės figūruoti kalba, kuria pageidaujama gauti tekstą. Šio varianto suteikiamas pranašumas, manau, akivaizdus — nereikia sukti galvos dėl skirtingų ID kūrimo.
  • Neleidžiant jų kurti, kalbą nurodyti tampa nebūtina, tačiau tuomet kyla potencialių nepatogumų, kuriant patį ID. Paprasčiausias pavyzdys — tarkime, jūsų firma gamina produktą, pavadintą „Aspirin“, ir turi svetainę penkiomis kalbomis, kurioje aprašo savo produktus. Logiška, kad puslapio apie šį produktą ID turėtų būti „aspirin“. Ir pageidautina, kad jis toks ir būtų. Tačiau gaunasi kitaip — tenka kurti „aspirin_es“, „aspirin_de“ ir pan. Tai nepatogu!

Dabartinės VU svetainės puslapiai yra adresuojami, nuorodoje nurodant kalbą. Tačiau TVS neleidžia kurti puslapių skirtingomis kalbomis, bet vienodais ID, taigi kalbos nurodymas yra iš principo nereikalingas. Ėmiau galvoti, gal reik tuos /lt/ bei /en/ išmesti. Bet galvoju, jog kita vertus, gal geriau reiktų praplėsti TVS funkcionalumą… Kaip manote?

21 komentaras apie “Visiškas puslapių ID TVS’e unikalumas: is this a feature or what?

  1. O kodėl problema naudoti vartotojo kalbą. Ją galima prisiminti cookie’iuose – manau.

    Tada blablabla.com/aspirin rodytų į tą kalbą, kuria puslapį naršo vartotojas.

  2. Nea, nuoroda IMHO turėtų būt vienareikšmė. T.y., tokia, kurią gali padėti bet kur ir žinoti, jog ją spustelėjus, atsidarys puslapis ta kalba, kuria nori…

  3. OK. Pažiūrėk, ką pats pasakei: „ta kalba, kuria nori…“. Ar tam žmogui kuriam duosi nuorodą noras kyla iš to kokia kalba nuorodą matei tu ar iš to kokia kalba skaito jis pats ? Tau nuoroda liks ta kalba kokia ją paėmei, kitam žmogui galbūt tai perskaityti angliškai būtų daug patogiau.

  4. Bet įsivaizduokime tokį scenarijų: mes norime duoti nuorodą užsieniečiui, niekada nesilankusiame mūsų puslapyje. Kaip reiktų tai įgyvendinti? Manau dado1945 pasiūlyme yra problemų :)

  5. dado1945, OK, man tavo argumentacija suprantama.

    Iš tiesų, tai, ar tu saugosi kalbą cookie’uose, ar įrašysi ją nuorodoje, yra jau svetainės implementavimo reikalas. Kitaip tariant, tu manai, jog ID turėtų būti unikalus tik vieno kalbos „medžio“ viduje, o kitame „medyje“ jis gali vėl pasikartoti, taip?

  6. spt> jokios čia problemos. Kalbą paimti galima netik iš sausainėlių. Galbūt teisinga tvarka būtų netgi:
    1) Jei naudoji firefox’ą nueik į Options -> Advanced -> Edit languages.
    2) Pagal IP (nekorektiška, jei esi užsienyje);
    3) ir tik tada pagal cookie’ius.

    RQ> Taip :)

  7. As palaikyciau varianta su vienu id kelioms kalboms, bet tada jokie kukiai negali buti… Informacija turi buti aiskiai identifikuojama URL pagalba, tame tarpe ir kalba…

    P.S. sitas Security code yra tiesiog pasityciojimas… Tika turejau suvesti 9 simbolius!!! Nepatingejau, bet manau daug komentatoriu galetu atbaidyt :)

  8. O ka pas jus puslapiai ne medžio struktūroje? Jei būtų medyje, užtektų, kad kiekvieno parent viduje child’ų ID būtų unikalūs.

    /apmokejimai/kasa
    /merginos/kasa
    /darbininkai/kasa/griovi

    gi yra skirtingi dalykai, o tavo pavadintas ID gali buti toks pats :-).

    Žinoma tokius dalykus lengviau saugoti failų sistemoj, o jūs tikriausiai DB saugot? Tai ir turit bėdą tuomet implementuoti FS logiką visą.

    Sėkmės!

  9. o tai
    drugs.com/aspirin?lang=de
    drugs.com/aspirin?lang=en
    negerai?
    cia klausimas giliau — ka tu laikai unikaliu resursu (kuris turetu unikalu ID)? ar puslapi, ar puslapio versija kazkokia kalba?

  10. manau, kad geraiu du medžiai, tuomet mažiau vargo su unikalumu, beto galima sukurti atsikra lentelę, ar įgrūsti kur kitur, kitos kalbos ID atitikmeni! Gi aišku, kad „aspirn“, tai aspirni, bet jei pvz „Rūta“ ar dar koks biesas? Manau kad iš nuorodos turėtu būti aišku kur eini bet kuria kalba :)

  11. Tamole, registruotiems useriams kodo įvedinėti nereikia. O pats kodas, žinok, mane kol kas kokiais 99% apsaugojo nuo spamo. :) Ne ti pirmas dėl jo skundies, bet ghm… Na, kas turi ką pasakyti, netingės kodą įvest. O kas dažnai įvedinėja kodą, nepatingės susikurt userio. Manyčiau taip… :D Egoistiška, bet ką padarysi…

    Dėl kalbos – galima pasinaudoti pumbos pasiūlymu — keičiant kalbą, pridėti ?lang=foo. Pas mus iš esmės taip ir yra, tik čia jau mod_rewrite pasidarbuoja, kad /en/ reiškia /?lang=en. :)

    Emili, taip, tas variantas galbūt ir būtų užvis geriausias. Tačiau ar tai jau nebebus per daug painu? Juolab, kad, pavyzdžiui, dabar bet kurio VU puslapio turinį galima pasiekti „trumpuoju keliu“. Pvz., puslapio http://www.vu.lt/lt/stojantiesiems/uzsienieciams/uzs_priemimo_tvarka/ tekstą galima paskaityti, nukeliavus į http://www.vu.lt/lt/uzs_priemimo_tvarka/. Naudojantis tavo schema, tai būtų neįmanoma. Aišku, čia dar klausimas, ar labai tokia galimybė reikalinga. Šiaip ar taip, manau, tai yra feature, o ne bug. Ar jūs taip nemanot?

    pumba, unikaliu resursu aš skaitau atskirą puslapį atskira kalba. Pavyzdžiui, VU svetainės atveju tie medžiai visiškai skiriasi, ir 1:1 mapping‘o tarp jų nesukursi.

    lfx, tau gal „Babytype“ suveikti? :D Dabartiniu atveju viskas yra saugoma vienoje lentelėje. Išvis ten, manau, tie įrašai per daug atributų turi pvz., tiek skaitinį ID, tiek tekstinį. Abu unikalūs. Kam to reikia?..

    Šiaip ar taip, bendrą nuomonę daugmaž susidariau. Reiks gal padaryt kokius eskizinius brėžinukus tokio dalyko duombazės. Ar ką nors domintų juos pamatyti? :)

  12. Aš /en/ ar /lt/ palikčiau URLe, kaip kad yra.
    1. Iš vienos pusės tai suteikia informaciją vien iš URL, kokia kalba yra puslapis;
    2. is kitos puses, galima intuityviai pasikeist svetainės kalbą, pakeitus url.

    Taigi galėtum leisti ID duplikavimą skirtingoms atšakoms,

    arba net toki burtą, kaip wikyje, kur kiekviena struktūrinį elementą atitinka unikalus kelias tarkim, iš to, ką paminėjo Emilis, „/darbininkai/kasa/griovi“ butu struktūrinio elemento ID (čia atskirais atvejais elementai su ID „/darbininkai/“ ir „/darbininkai/kasa/“ gali ir neegzistuoti). Tuo tarpu, trumpasis adresas (shortcut arba alias) galėtų būti atskira DB lentelė, rišanti trumpuosius adresus ir struktūrinius elementus (jų ID (slugs)).

    Tai tiek pamąstymų.

  13. man tai /en/… URL’uose atrodo ne i tema. URL’as atspindi kelia puslapio strukturoj, hierarchijoj, o kalba su tuo neturi nieko bendro. tai tik parametras. aisku, viskas paprasciau, jei visom kalbom struktura ta pati (pagal mane, taip ir turetu buti).

  14. Na visom kalbo struktūra tikrai negali būti ta pati. Nes nėra prasmės daryti lietuvių kalbos vartotojams aktualaus turinio būtinai prieinamu anglakalbiams ir pan.

    O kuo blogai /en/pavadinimas. /lt/pavadinimas ? Kiek teko susidurti, tai logiškiausias sprendimas.

    Apskritai dėl url formavimo visiškai pritarius Archat’ui. Tokio modelio laikiėmės kurdami http://www.justpagit.lt, jį įdeigta ne viename šimte svetainių, niekur nebuvo problemų.

    Tik vienas niuansas – įvedinėjant daug tokių alternatyvių ID, sunku išlaikyti struktūrą, nes visą kelią reikia vesti rankomis. Aišku tai galima ir automatizuoti…

    Pakankamai originalus gauminos sprendimas. Savo tvs’e jie formuoja url’ą pagal kelią iki puslapio (pvz.: http://www.almalittera.lt/lt.php/pranesimai_ziniasklaidai/2006_05_12_alma_littera_grupe_per_siu_metu_pirmaji_ketvirti_padvigubino_apyvarta/282)
    tačiau visas tekstas yra panaudotas tik paieškos sistemų palankumui įgauti, nes jei atkreiptume dėmesį į url pabaigą, pamatytume id, pagal kurį atidaroma svetainė :) Jo neperduodant, tekstinis url nieko neatidaro. Žodžiu sistema turinį duoda tik pagal paskutinį kelio elementą.

    Savitiškas abiejų Rimo minėtų variantų mišinys :)

    Dėl ID unikalumo – iš asmeninės patirties galiu pasakyti, kad labai patogu turėti unikalius id absoliučiai visiems tvs elementams (psl, img ir pan), na ir atitinkamai turėti standartizuotą meta dumenų standartą kiekvienam elementui aprašyti. Tokiu būdu pakanka turėti tik id, kad gautu m visą reikiamą info. Atsiranda labai daug laisvės :)

  15. Taip ir nesupratau, kuo blogas Apache Language Negotiation? Nei medžio negadina, nei logikos, visai patogus. Gali rašyti bendrą nuorodą, pvz. http://up.on.lt/ – tada naršyklė atvers tinkamiausią lankytojui iš esančių atmainų (pagal jo kalbų žinojimą, surikiuotą naršyklėje). Arba http://up.on.lt/index.htm.lt, jei nori nurodyti tiksliai. Apache kalbų derinimas tinka ne tik viršeliui – kiekvienam lapui, nesvarbu, kiek kalbinių jo atmainų yra.

  16. Language negotiation, niekuo neblogas. Mano nuomone, tai yra dar vienas būdas defoltinei kalbai parinkti (t.y., jei pats lankytojas kalbos nenurodo). Tačiau turėtų būti patogus būdas tą kalbą perjungti, ar paduoti linką į puslapį konkrečia kalba.

  17. RQ, čia tu įdomią problemą gvildeni. Kai dariau SCARGA, pats nemažai apie tai mąsčiau. Iš tiesų, galima struktūrinių elementų unikalumą tikrinti tik konkrečios kalbos kontekste – čia SCARGA galima nesudėtingai perjungti į tokį režimą. Tik tada kalbos nurodymas būtų privalomas, kadangi konkretus turinys būtų atrenkamas pagal elemento ID, kuris, savo ruožtu, būtų sužinomas pagal elemento pavadinimą konkrečioje kalboje.

    Toks principas, manyčiau, būtų efektyvesnis nei naudojamas dabar.

  18. Na va. Vadinas, jei rankos daeis apskritai ką nors daryti, tai reikės šito dalyko nepamiršt. :)

    O kalbą galima įvairiai tikrinti – gali, pvz, sugalvoti, kad, jei kalba nenurodyta tiesiogiai URL’yje, ji būtų naudojama defoltinė. Arba parenkama pagal Accept-language. Arba dar kaip… Variantų nemažai juk.

Parašykite komentarą

El. pašto adresas nebus skelbiamas. Būtini laukeliai pažymėti *