Archívum - 2015
január 5
Custom font probléma ékezetes karakterek esetén
Van egy problémám az alábbi oldalamon: tarsasjatekwebshop.hu
Az Open Sans nevű font-ot húztam be a google fontok közül amit a css-ben @-rule módszerrel használok. Az a probléma, hogy ha a felhasználó gépére nincs telepítve a font, akkor az őűŐŰ betűket hibásan jeleníti meg. Pl itt látható a dialog címsorában: http://webprog.biz/images/2015-01-05_204526.png
Az érdekes az, hogy ha a felhasználó gépén telepítve van, akkor jól jelennek meg ezek a betűk is. Amúgy az oldalon minden kódolás utf-8.
Van valaki aki esetleg tapasztalt már hasonlót vagy tudja a megoldást? Előre is köszönöm!
■ Az Open Sans nevű font-ot húztam be a google fontok közül amit a css-ben @-rule módszerrel használok. Az a probléma, hogy ha a felhasználó gépére nincs telepítve a font, akkor az őűŐŰ betűket hibásan jeleníti meg. Pl itt látható a dialog címsorában: http://webprog.biz/images/2015-01-05_204526.png
Az érdekes az, hogy ha a felhasználó gépén telepítve van, akkor jól jelennek meg ezek a betűk is. Amúgy az oldalon minden kódolás utf-8.
Van valaki aki esetleg tapasztalt már hasonlót vagy tudja a megoldást? Előre is köszönöm!
MVC outdated?
Blogmarkként talán jobb lett volna, de nem találom, hogy hol olvastam: állítólag az MVC pattern már idejétmúlt, felejtős.
Ez valóban igaz lenne vagy csak véletlenül egy újító hangulatú fejlesztő blogjába botlottam tegnap?
Ha igaz, mi ajánlott helyette?
És itt most nem csak (sőt elsősorban nem) webes fejlesztésben gondolkodnék.
■ Ez valóban igaz lenne vagy csak véletlenül egy újító hangulatú fejlesztő blogjába botlottam tegnap?
Ha igaz, mi ajánlott helyette?
És itt most nem csak (sőt elsősorban nem) webes fejlesztésben gondolkodnék.
Elköltözött a Weblabor
Az év vége a Weblabor körül lázas munkával telt: korábbi szolgáltatónk, a PHPHost befejezte működését, így rendszereinket a nekik új otthont adó szerverekre kellett költöztessük.
január 3
Pár elemes listák
Sziasztok!
Problémám a következő. Vannak egy csomó ~30 elemű listánk, aminek az értékeit aztán tároljuk különböző rekordokban (ott nyilván integerként).
Néha exportálgatunk, ott nem árt ha olvashatóan szerepelnek a dolgok, és néha szeretjük, ha az exportot kiköpi az adatbáziskezelő.
Mi a legoptimálisabb megoldás?
I.
Minden listának külön tábla?
pro
-idegen kulcsok szépen működnek
-minden szép és jó
kontra
-nem overkill?
-a sok hülye tábla, amik között nem találjuk meg a tényleg használt táblákat.
II.
Csinálunk lista_csoport és lista_elem táblákat
#lista_csoport#
-idcsoport (pk)
-csoport (varchar)
#lista_elem#
-idelem (pk)
-idcsoport (fk)
-elem
És az idelem értékeket tároljuk ahol kell.
pro
-kevés tábla
-külső kulcsok részben működnek
kontra
-különböző csoportok pk-i keverednek, a kulcs nem hordoz az ember számára semmiféle értelmezhető információt (ez azért néha nem rossz). esetleg szorozzuk meg a csoport azonosítót százzal és ebben az intervallumban tároljuk a lista elemeit (ez ám a gány, de talán nem is olyan hülyeség)
-olyan kulcs is kerülhet adott helyre, aminek ott semmi értelme (egy totál másik csoporthoz tartozik) (mondjuk ha a csoport azonosító benne van az elem kulcsban, akkor akár lehet rajta egy könnyen megírható trigger)
III.
lista_elembe felveszünk még egy mezőt, ami az adott érték indexét tárolja, de ez még nagyobb butaság, mert vagy két mező lehetne idegen kulcs, vagy nem tudná kezelni az idegen kulcsokat az adatbázis (azért nem baj, hogy nem tudok berakni olyant ami nem létezik)
----------
Csak SQL segítségével lehet ezt normálisan kezelni, vagy van valami értelmes megoldás erre a problémára?
■ Problémám a következő. Vannak egy csomó ~30 elemű listánk, aminek az értékeit aztán tároljuk különböző rekordokban (ott nyilván integerként).
Néha exportálgatunk, ott nem árt ha olvashatóan szerepelnek a dolgok, és néha szeretjük, ha az exportot kiköpi az adatbáziskezelő.
Mi a legoptimálisabb megoldás?
I.
Minden listának külön tábla?
pro
-idegen kulcsok szépen működnek
-minden szép és jó
kontra
-nem overkill?
-a sok hülye tábla, amik között nem találjuk meg a tényleg használt táblákat.
II.
Csinálunk lista_csoport és lista_elem táblákat
#lista_csoport#
-idcsoport (pk)
-csoport (varchar)
#lista_elem#
-idelem (pk)
-idcsoport (fk)
-elem
És az idelem értékeket tároljuk ahol kell.
pro
-kevés tábla
-külső kulcsok részben működnek
kontra
-különböző csoportok pk-i keverednek, a kulcs nem hordoz az ember számára semmiféle értelmezhető információt (ez azért néha nem rossz). esetleg szorozzuk meg a csoport azonosítót százzal és ebben az intervallumban tároljuk a lista elemeit (ez ám a gány, de talán nem is olyan hülyeség)
-olyan kulcs is kerülhet adott helyre, aminek ott semmi értelme (egy totál másik csoporthoz tartozik) (mondjuk ha a csoport azonosító benne van az elem kulcsban, akkor akár lehet rajta egy könnyen megírható trigger)
III.
lista_elembe felveszünk még egy mezőt, ami az adott érték indexét tárolja, de ez még nagyobb butaság, mert vagy két mező lehetne idegen kulcs, vagy nem tudná kezelni az idegen kulcsokat az adatbázis (azért nem baj, hogy nem tudok berakni olyant ami nem létezik)
----------
Csak SQL segítségével lehet ezt normálisan kezelni, vagy van valami értelmes megoldás erre a problémára?
január 2
Új áfaszabályozás technikailag
Sziasztok!
Például itt olvastam, hogy az áfát mostantól a vásárló országa szerint kell kiszámolni mindenféle e-könyv, telefonos applikáció, film vagy zenei album internetes vásárlásakor.
Ezt hogy csinálják majd a cégek, nagyok-kicsik?
Honnan tudják, hogy honnan vásárolok?
Az árat ki kell írni, méghozzá az áfásat.
Alapprobléma, hogy miben bízhatnak a boltok?
A) A felhasználó megadhatja, hogy melyik országból vásárol?
B) Vagy a bankkártyája adja meg ezt az információt?
Milyen árat rakjon ki a bolt? A következő lehetőségeket találtam:
1: Csak regisztrálás után írják ki az árakat.
Ez problémás, mert nem akar mindenki regisztrálni. Az A)B) probléma megmarad.
2. Az IP cím alapján meghatározzák hogy hogy hol vagy. Ez nem megbízható. Mi van, ha valaki épp külföldön jár?
3. A felhasználó választ országot egy legördülőből, de figyelmeztetik, hogy a bankkártyája országa alapján az ár változhat.
Ez furcsa.
Ha a bankkártya országa a meghatározó, akkor érdemes lesz luxemburgi bankszámlát nyitni minden vásárlónak?
Paypalos fizetésnél van további kavarás? A Paypal átadja az országinformációt?
Mi a véleményetek erről? Technikailag hogyan lesz ez megvalósítva?
■ Például itt olvastam, hogy az áfát mostantól a vásárló országa szerint kell kiszámolni mindenféle e-könyv, telefonos applikáció, film vagy zenei album internetes vásárlásakor.
Ezt hogy csinálják majd a cégek, nagyok-kicsik?
Honnan tudják, hogy honnan vásárolok?
Az árat ki kell írni, méghozzá az áfásat.
Alapprobléma, hogy miben bízhatnak a boltok?
A) A felhasználó megadhatja, hogy melyik országból vásárol?
B) Vagy a bankkártyája adja meg ezt az információt?
Milyen árat rakjon ki a bolt? A következő lehetőségeket találtam:
1: Csak regisztrálás után írják ki az árakat.
Ez problémás, mert nem akar mindenki regisztrálni. Az A)B) probléma megmarad.
2. Az IP cím alapján meghatározzák hogy hogy hol vagy. Ez nem megbízható. Mi van, ha valaki épp külföldön jár?
3. A felhasználó választ országot egy legördülőből, de figyelmeztetik, hogy a bankkártyája országa alapján az ár változhat.
Ez furcsa.
Ha a bankkártya országa a meghatározó, akkor érdemes lesz luxemburgi bankszámlát nyitni minden vásárlónak?
Paypalos fizetésnél van további kavarás? A Paypal átadja az országinformációt?
Mi a véleményetek erről? Technikailag hogyan lesz ez megvalósítva?
átírás htaccess-ben
Sziasztok !
Azt szeretném elérni, hogy pl. a www.valami.hu begépelése után az oldalra való érkezéskor a böngésző címsorában a www.valami.hu/akármi jelenjen meg.
Tudom, hogy ezt a htaccess-ben átírással lehet megoldani, csak nekem valamiért nem sikerül.
Ehhez szeretnék segítséget kapni.
■ Azt szeretném elérni, hogy pl. a www.valami.hu begépelése után az oldalra való érkezéskor a böngésző címsorában a www.valami.hu/akármi jelenjen meg.
Tudom, hogy ezt a htaccess-ben átírással lehet megoldani, csak nekem valamiért nem sikerül.
Ehhez szeretnék segítséget kapni.
január 1
htaccess probléma?
Sziasztok !
Az alábbi probléma megoldásához szeretnék segítséget kapni.
Adott egy oldal, aminek URL címe a következő:
www.blank.hu/hu/valami
Értelemszerűen itt magyar tartalom van.
Ha az oldalon angol nyelvre váltok, akkor az URL az alábbira módosul
www.blank.hu/en/something
és persze itt az angol nyelvű tartalom jelenik meg
Aztán ha az URL-t módosítom erre
www.blank.hu/hu/something
akkor mégis a magyar tartalom jelenik meg
Ezek alapján nekem úgy tűnik, hogy itt nem 2 külön fájlról van szó (valami és something), hanem egyről, viszont az URL-ben mégis két különböző dolog jelenik meg.
A megjelenő tartalmat csak a "hu" ill. "en" befolyásolja, a "fájlnév" (ami valószínűleg ténylegesen nem az) pedig nem.
Kérdésem az, ha ez a htaccess-ben oldható meg, akkor azt hogyan lehet megtenni ?
Előre is köszönöm a segítségeteket.
■ Az alábbi probléma megoldásához szeretnék segítséget kapni.
Adott egy oldal, aminek URL címe a következő:
www.blank.hu/hu/valami
Értelemszerűen itt magyar tartalom van.
Ha az oldalon angol nyelvre váltok, akkor az URL az alábbira módosul
www.blank.hu/en/something
és persze itt az angol nyelvű tartalom jelenik meg
Aztán ha az URL-t módosítom erre
www.blank.hu/hu/something
akkor mégis a magyar tartalom jelenik meg
Ezek alapján nekem úgy tűnik, hogy itt nem 2 külön fájlról van szó (valami és something), hanem egyről, viszont az URL-ben mégis két különböző dolog jelenik meg.
A megjelenő tartalmat csak a "hu" ill. "en" befolyásolja, a "fájlnév" (ami valószínűleg ténylegesen nem az) pedig nem.
Kérdésem az, ha ez a htaccess-ben oldható meg, akkor azt hogyan lehet megtenni ?
Előre is köszönöm a segítségeteket.