ugrás a tartalomhoz

Archívum - 2015

január 5

Custom font probléma ékezetes karakterek esetén

Horváth Norbert · 2015. Jan. 5. (H), 21.53
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!
 

MVC outdated?

pythonozok · 2015. Jan. 5. (H), 21.26
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.
 

On PHP Version Requirements

Hidvégi Gábor · 2015. Jan. 5. (H), 19.02
Miért érdemes folyamatosan frissíteni a PHP-t
 

Pitfalls of Callback-Based APIs

Hidvégi Gábor · 2015. Jan. 5. (H), 18.50
A callbackek problémái, megoldási javaslatok
 

Elköltözött a Weblabor

Joó Ádám · 2015. Jan. 5. (H), 17.56

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

szabo.b.gabor · 2015. Jan. 3. (Szo), 09.50
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?
 

január 2

Új áfaszabályozás technikailag

zzrek · 2015. Jan. 2. (P), 13.12
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?
 

átírás htaccess-ben

Blackfriar · 2015. Jan. 2. (P), 07.17
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.
 

január 1

htaccess probléma?

Blackfriar · 2015. Jan. 1. (Cs), 09.33
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.