- Karácsonyfaként világíthat a Thermaltake új CPU-hűtője
- Az USA vizsgálja a RISC-V kínai terjedésének kockázatát
- Kicsit extrémre sikerült a Hyte belépője a készre szerelt vízhűtések világába
- Egészen nagy teljesítményspektrumon fedné le a mobil piacot az AMD
- Kihívás a középkategóriában: teszten a Radeon RX 7600 XT
- Mini-ITX
- Kicsit extrémre sikerült a Hyte belépője a készre szerelt vízhűtések világába
- Piacvezető tandem OLED panellel érkezik az iPad Pro
- A Fractal Design fával díszített toronyházának testvére született
- Gaming notebook topik
- A régi node-okra koncentrál a szankciók miatt Kína
- Egészen nagy teljesítményspektrumon fedné le a mobil piacot az AMD
- Sony MILC fényképezőgépcsalád
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Micro Four Thirds
Hirdetés
-
Az USA vizsgálja a RISC-V kínai terjedésének kockázatát
ph A Kereskedelmi Minisztérium egyelőre csak felméri a helyzetet, egyelőre nem látni, hogy tudnak-e bármit is tenni.
-
Agyi chipes gyártóba fektetett a kriptocég
it A Tether 200 millió dollárt fektet a Blackrock Neurotech agyi chipes vállalatba.
-
Már tudjuk, hogy mikor jön az idei Xbox Games Showcase
gp A showt egy külön Direct előadás követi, ami szinte biztosan az idei Call of Duty lelepelzése lesz.
Új hozzászólás Aktív témák
-
Sk8erPeter
nagyúr
válasz honda 1993 #6100 üzenetére
Ha egyszerűen a korábbi példát módosítod, amit mutattam, csak úgy, hogy nem az img_containerre rakod a bordert, hanem magára az img-re, az nem jó?
Mármint így: http://jsfiddle.net/e4per0nL/2/
Mondjuk fogalmam sincs, konkrétan mit szeretnél, mert nem fejtetted ki, de nekem úgy tűnt az eddigiekből, hogy jó az első példa is, csak a képek köré szeretnél valami keretet rakni (amúgy ebben a formában a keret elég ronda, gondolom nem ilyen lesz élesben, de szemléltetésnek pont jó).[ Szerkesztve ]
Sk8erPeter
-
honda 1993
senior tag
válasz Sk8erPeter #6101 üzenetére
Haaat, ez felig-meddig bevalt. Koszonom
Bar a kozepso kep megint szivat engem, mert most majdnem ugy nez ki mint az altalad linkelt kodban, de most meg alacsonyabb lett a kozepso kep,mint a ket szelso.
Annak ellenere hogy ugye meg van adva a magassag es a szelesseg is.
Raadasul direkt ossze is hasonlitottam a te kododdal a sajatomat, es nincs is kulombseg a ketto kozott.Lehet hogy az lesz a baj hogy annak a kepnek mas a felbontasa mint a masik kettonek ?
Mert mar tenyleg nincs mas otletem.Tehat megegyszer, igen jol gondolod. Es a jsfiddle peldaban talalhato kod pont olyan ami nekem kell, tehat eltalaltad. XD
A masik kerdesedre valaszolva, a keret termeszetesen nem a vegleges formaban jelent meg a linkelt kodban.
[ Szerkesztve ]
XD alias IKSZDé
-
honda 1993
senior tag
HAHHHAHAAHAHAAAAAAAAA
Es vegig az volt a baj hogy annak a kepnek mas volt a felbontasa.
Csak most jottem ra, hogy rapillantottam az images mappaban levo kepre.
Koszi a segitseget. Mostmar mukodik ( ahogy Fekete Pako mondana ).
[ Szerkesztve ]
XD alias IKSZDé
-
PumpkinSeed
addikt
válasz honda 1993 #6103 üzenetére
Bocs, hogy beleszólok, de lehetne legközelebb kevesebb ugráló, tapsoló, guruló fejjel elküldeni valamit?
"Akinek elég bátorsága és türelme van ahhoz, hogy egész életében a sötétségbe nézzen, elsőként fogja meglátni benne a fény felvillanását." - Kán
-
Sk8erPeter
nagyúr
válasz honda 1993 #6103 üzenetére
Örülök, hogy sikerült, bár ha megfelelően meg vannak adva a képdimenziók (szélesség x magasság), akkor nem kellene ilyen problémának előfordulnia, hogy kitolja valamelyik elemet egy eltérő méretekkel rendelkező kép.
(#6104) PumpkinSeed : Hadd örüljön.
Sk8erPeter
-
honda 1993
senior tag
válasz Sk8erPeter #6105 üzenetére
Hat en sem ertem hogy miert, es hogy hogyan, de ez volt a problema.
PumpkinSeed Nem is volt olyan sok.
[ Szerkesztve ]
XD alias IKSZDé
-
Carasc0
őstag
Sziasztok!
Abszolút kezdőként érdeklődök egy adott egyszerű probléma megoldása ügyében. A feladat roppant egyszerű. Adott egy szimpla JPEG kép amit szeretnék a weboldal hátterébe berakni. Ez még megy is, de hogyan tudom úgy beállítani, hogy ha az oldalt tetszőleges felbontásban lévő monitoron nézik meg, illetve tetszőlegesen nagyítják az oldalt, akkor a kép igazodjon ezekhez az átméretezési paraméterekhez.
Előre is köszönöm!
Gondolkodj globálisan és tegyél lokálisan!
-
tothjozsi96
addikt
Van egy üzenőfalam ami jelenleg iframe-es megoldás.
Nekem viszont realtime kéne, de ha jquery-vel vagy ajax-al frissítem akkor az bizony terheli a memória használatát egy usernek.Valaki használt már real time-ot vagy felhasználó barát üzenőfal frissítést/módszert?
-
pumatom
aktív tag
Sziasztok!
Elsősorban azokhoz szólna a kérdésem, akik pénzért csinálnak weboldalakat.
A képeket, amiket felhasználtok, azokat Ti honnan szeditek le, veszitek meg( )?
A kérdés a különböző szerzői jogok miatt fogalmazódott meg, nem tudom, hogy jelenleg mi erre a hivatalos törvény, stb... ?
Szerk.: Nem a free vector images, és satöbbi oldalakra gondolok, hanem a rendes felismerhető arcokat, tájakat, stb.-t ábrázoló képekre.
Ti hogy csináljátok?
[ Szerkesztve ]
-
cidalain
veterán
válasz pumatom #6110 üzenetére
Kinosan ugyelek ra, hogy a fotokat a megrendelotol kapjam, azokkal dolgozom. Pl o a sajat termekeit lefotozza, es azokat hasznalom fel.
Nyilvan ha jogvedett fotot kuld, akkor az nem az en dolgom kideriteni, hogy azt o joggal birtokolja e vag sem...>> GearBest Club Veszprém << >> https://www.facebook.com/gbc.veszprem <<
-
martonx
veterán
válasz tothjozsi96 #6109 üzenetére
"Nekem viszont realtime kéne, de ha jquery-vel vagy ajax-al frissítem akkor az bizony terheli a memória használatát egy usernek." - tényleg terheli, és vajon mennyivel?
Viccet félretéve valóban nem elegáns megoldás pollozni a szervert, mégha ez egy bevált módszer is.Egyébként igen, én használok real time ózenetküldést per pillanat is, bár én ASP.NET vonalon mozgok, ott pl. a SignalR erre tökéletes. Biztos PHP vonalon is megvannak a HTML5-ös push notification API kihasználásra épülő komponensek.
Én kérek elnézést!
-
Zedz
addikt
válasz tothjozsi96 #6115 üzenetére
Websockethez kell szerver oldal is igen, viszont ezzel real-time lehet csodákat művelni.
-
tothjozsi96
addikt
Igen, csak kíváncsi lennék a használatára.
Mert doksit és hasonlókat nem nagyon találtam róla, tehát a pontos működéséről.
Azért érdekelne, mert egy real-time üzenőfalat akarok írni, gyakorlatilag most is az üzenetek memóriában vannak tárolva, szóval ezért még jó lenne egy realtime is mellé. -
pumatom
aktív tag
válasz cidalain #6111 üzenetére
Értem.
A termékek még egy dolog, mert ha árulhatja, akkor jó eséllyel valami joga már van a megjelenítéshez.
A másik esetnél tudsz arra hivatkozni, hogy Ő küldte.
Viszont, ha teljesen rád van bízva, hogy milyen legyen a weboldal, akkor hogy csinálnád?
fordfairlane:
Egy képért akarnak kérni 1665€ -t, a weblapért nem adnak annyit.[ Szerkesztve ]
-
cidalain
veterán
válasz pumatom #6118 üzenetére
szerencsére ritkán csinálom én a designt, így ilyen jellegű problémám még nem volt.
ha meg én csinálok designt, akkor ott nincs kép a design részeként ami fix lenne, tartalomkezelővel tölthető a fejléckép is pl. a tartalomkezelőt meg a tulaj tölti...ilyen hogy ikon, vagy mini ábra ami esetleg kellene valamihez (mittudomén pl nyilak, email ikon, vagy nemtudom), azt általában lenyúlom valahonnan, bár itt is inkább free ikonok között keresek elsősorban, és max alakítok rajta kicsit.
ilyen istockphoto szerű oldalaknál képenként is lehet fizetni, 10-20 dollár körül van egy kép.
a getty elég húzósnak tűnik árban így elsőre[ Szerkesztve ]
>> GearBest Club Veszprém << >> https://www.facebook.com/gbc.veszprem <<
-
martonx
veterán
válasz tothjozsi96 #6115 üzenetére
Igen websocket-ről beszélünk. Én ugyan csak ASP.NET vonalról, és MS Serverről tudok nyilatkozni, ott semmit nem kell telepíteni.
Én kérek elnézést!
-
cidalain
veterán
Nem annyira HTML, de talán belefér.
Mi a különbség, és melyik XML struktúra javasolt
<product>
<id>ágy123</id>
<name>ágymelegítő</name>
</product>vagy
<product id="ágy123" name="ágymelegítő" />
Olvastam hogy ez a kettő megoldás elvileg teljesen ekvivalens egymással.
Van e olyan szituáció amikor ajánlott valamelyik felállást alkalmazni.
Mostanában volt dolgom több adatátpasszolós XML oldallal, és az egyik így használja, a másik amúgy, de van olyan is aki egy XML fájlon belül mindkét módszert alkalmazza.Nekem most viszonylag nagy mennyiségű adatot kellene átadnom adatbázisból egy javascriptnek, így a második megoldást választanám, mert ott kevesebb lenne az egyéb sallang, kisebb lenne az XML mérete.
>> GearBest Club Veszprém << >> https://www.facebook.com/gbc.veszprem <<
-
cidalain
veterán
válasz fordfairlane #6125 üzenetére
És ha ezt az adathalmazt később egy külső forrásnak is ki kell szolgáltatnom, akkor a JSON oda is ajánlott?
Mi az előnye a JSON-nak az XML-lel szemben? Javascripttel tökmindegy, max kicsit gyorsabb a feldolgozási idő, nem?
Külső programokkal le lehet kezelni rendesen a JSON fájlokat (mittudomén mondjuk Androidos szoftver ha lehívja az adatot a weboldalról)>> GearBest Club Veszprém << >> https://www.facebook.com/gbc.veszprem <<
-
fordfairlane
veterán
-
martonx
veterán
válasz cidalain #6126 üzenetére
"És ha ezt az adathalmazt később egy külső forrásnak is ki kell szolgáltatnom, akkor a JSON oda is ajánlott?"
Mi az hogy, nagyon is. Az XML így 2014-ben már sehova nem ajánlott."Mi az előnye a JSON-nak az XML-lel szemben?"
Tömörebb, s minden nyelv kb. natívan át tudja fordítani a saját objektumaivá. Én C#-ról tudok nyilatkozni, ott pl. XML-t parse-olni pár nagyságrenddel nagyobb szopás, mint Json-ből kapni egy megfelelő erősen típusos osztályt (Java vonalon tudtommal dettó ugyanez a helyzet).Én kérek elnézést!
-
cidalain
veterán
válasz martonx #6128 üzenetére
Értem, köszönöm.
Igazából most tökmindegy nekem hogy mit rakok össze PHP-val, kb ugyanannyira egyszerű egy XML meg egy JSON outputot is elkészíteni.
Hallottam már a JSON-ról korábban is, de valahogy eszembe sem jutott ez az opció most, automatikusan az XML ugrott be. Közben persze most én is elkezdem utánanézni, és több az előnye ha ilyet használnék. Nem tudom miért nem promózzák ezt jobban... (vagy csak én nem forgatom elég mélyen a szakirodalmat?)>> GearBest Club Veszprém << >> https://www.facebook.com/gbc.veszprem <<
-
martonx
veterán
válasz cidalain #6129 üzenetére
"Nem tudom miért nem promózzák ezt jobban"
A csapból is JSON folyik. Én azt nem értem, hogy juthat még bárkinek is eszébe az XML manapság (mondom én, aki nem győzök XML-t visszaadó service-ekhez fejleszteni online felületeket, de egyszer csak kikopnak a köztudatból a régi szarok).
Anno 2012-ben a kedvencem a KHR (Központi Hitelnyilvántartó Rendszer) volt, ahol anno hihetetlen nagy dérrel-dúrral jelentették be a rendszer totális megújulását. A régi rendszer sajátosan formázott txt file-ok ftp-n küldözgetésével működött (na jó, nem pont ftp, de fejlesztői szemmel nézve pont úgy működött, a GIRO-sok meg napokig tudnának beszélni a különbségről).
Gondoltam, na milyen király lesz, végre lesz egy normális REST API a KHR-hez is, és JSON-ban jönnek-mennek majd az adatok.
Ezzel szemben az újítás abban merült ki, hogy már xml file-ok ftp-n küldözgetésével működik a KHR
Ráadásul komolyan brutál nagy XML-eket képzeljetek el, a legapróbb adat változás is több száz kbyte-os körítésekben utazik.
Anno, amikor az OTP elkezdte az ősfeltöltést, napokig elérhetetlen volt a KHR szolgáltatás
Egyszer véletlenül mi is kifektettük fél napra, pedig csak valami korrekciókat akartunk feltolni.Ah, de jó hogy nem dolgozok már az őskövület pénzügyi szektorban.
Én kérek elnézést!
-
Sk8erPeter
nagyúr
válasz cidalain #6129 üzenetére
Ahogy a többiek már elég meggyőzően elmondták, mindenképpen a JSON-t válaszd az XML-lel szemben. Azt meg nem értem, hogy nem találkoztál még vele, hogy mennyire nyomatják (nem véletlenül) a JSON-t, minden tisztességes és említésre méltó dokumentáció/tutorial/e-book/könyv/fórumhozzászólás a JSON-t javasolja manapság (például nagyon kényelmes is kezelni mondjuk AJAX-os kliens-szerver kommunikációnál). Főleg, ha azt írod, hogy elsősorban JavaScript-kódban használnád a szerverről fogadott adatokat... szerintem már az is elég beszédes, hogy a JSON a JavaScript Object Notationből készített mozaikszó.
A JSON-nek nagyon széleskörű a támogatottsága, ma már csak kb. a nem "karbantartott" programozási nyelvekhez nincs JSON-támogatás.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz cidalain #6121 üzenetére
Bár ahogy megbeszéltük, úgyis JSON-t kéne választanod, de akkor már beszéljük meg az XML-t is az érdekesség kedvéért.
Ennél a példánál, amit mutattál, teljesen egyértelmű, hogy az utóbbi, attribútumokkal ellátott formát kell választani. De szerintem a példa is rossz, mert ez annyira magától értetődő, ebben az esetben nem kérdés, melyiket kéne választani: egyrészt az utóbbi láthatóan jóval tömörebb (nemcsak olvashatóbb, de kisebb hálózati forgalmat is jelent, ami nagy mennyiségnél már nem mindegy), másrészt az előbbi forma esetén az azt feldolgozó kód felesleges terjengőssége is problémát jelenthet, mivel be kell járni az adott csomóponthoz tartozó gyerekelemeket, ez plusz metódushívásokat és overheadet jelent, míg az utóbbi forma esetén csak az adott tag attribútumainak értékeit kérdezgeted le, és megvagy. Szóval több szempont is az utóbbi mellett szól.
Abban az esetben lenne max. indokolt az előbbi forma, ha valami komplexebb adatstruktúrát kellene tárolnod gyerekelemekként, ahol mondjuk pont az attribútum-érték páros szerinti leírás lenne már undorítóan olvashatatlan és/vagy erőltetett (mert mondjuk kényszerből iszonyú hosszú neveket kell adnod már az attribútumoknak, hogy megkülönböztethető legyen, az most micsoda is).Sk8erPeter
-
cidalain
veterán
válasz Sk8erPeter #6132 üzenetére
Az XML szintaxis leírásánál mindenhol kivétel nélkül a terjengősebb forma van, majd a végén 1 sorban megemlítik a másikat is. Ezért kérdeztem itt hogy mi a véleményetek, mert gyanúsan a jobbnak tűnő megoldás volt elintézve egy sorban.
Nekem nem kellett még ilyesmit csinálni így nagyon nem mentem bele, hogy mi az elterjedtebb. Viszont ügyfelek már kerestek meg akiknek kellett XML feldolgozót készíteni: pl a használtautós oldal is XML-be exportálja ki egy adott kereskedés cuccait, illetve volt már dolgom ilyen kuponos oldalak ajánlatainak átvételéről, azok is kivétel nélkül XML-ben adják ki az adatokat. JSON-t eddig sehol sem láttam ilyenre, de mondom, nem is kerestem
>> GearBest Club Veszprém << >> https://www.facebook.com/gbc.veszprem <<
-
Sk8erPeter
nagyúr
válasz cidalain #6133 üzenetére
"Az XML szintaxis leírásánál mindenhol kivétel nélkül a terjengősebb forma van, majd a végén 1 sorban megemlítik a másikat is."
Ez a "kivétel nélkül" talán egy kicsit erős, nem?
Melyik leírás volt ez?A másikra: nézd meg martonx példáját, ebből jól látható, hogy attól még, mert valamit sokan igényelnek vagy használnak, az attól még nem biztos, hogy a megfelelő technológia a feladat kivitelezésére. De lehet, hogy nagyon sokan vannak olyanok is, akik meg a célra megfelelőbb technológiát ajánlanák. Van, ahol őskövületek dolgoznak, és ők döntenek bizonyos dolgokról, vagy épp az a helyzet van, hogy rettentő komplikált vagy pénzigényes lenne a teljes átállás, és ilyen módon csomó mindent sikerül jópár évig bebetonozni.
[ Szerkesztve ]
Sk8erPeter
-
tothjozsi96
addikt
HTML-ben mit érdemes használni mint táblakezelőt?
Vagyis több értelme van a DIV-nek? -
Jim-Y
veterán
válasz Sk8erPeter #6134 üzenetére
Egyebkent szerintem nem ilyen egyszeru a dolog, hogy az inline property-s verzio az jobb, es kesz.
cidalain:
Szerintem van amikor az elso verzio a jobb, es van amikor a masodik. Ha peldaul sok repetitiv elem lenne az XML fajlomban, peldaul
<product>
<id>ágy123</id>
<name>ágymelegítő</name>
</product>
<product>
<id>ágy123</id>
<name>ágymelegítő</name>
</product>
<product>
<id>ágy123</id>
<name>ágymelegítő</name>
</product>Akkor en is a rovidebb, tomorebb verziot hasznalnam. Ellenben ha mar ez az XML pl egy build.xml lenne, akkor az elso verzio -szertintem- sokkal atlathatobba tenne a fajlt. Egzebkent pedig pfuj XML, tessek mar JSON-t hasznalni!
-
Sk8erPeter
nagyúr
Ezek szerint eléggé félreértetted, nem állította senki, hogy minden esetben ilyen egyszerű, de amúgy igen, a jelen helyzetben ilyen egyszerű, hogy az attribútum-érték párosokkal ellátott verzió jobb, és kész. Eléggé kifejtettem az okát az előző hsz.-emben. Mert szerinted a példában mégis mi szól a másik mellett? (Nem láttam tőled indoklást. )
"Ellenben ha mar ez az XML pl egy build.xml lenne, akkor az elso verzio -szertintem- sokkal atlathatobba tenne a fajlt."
Ez így nem túl értelmes állítás, mivel ha megnézel egy Ant-es build.xml-t, akkor az tele van ilyen vagy olyan megoldásokkal (van, ahol az egyik formátumot, van, ahol a másikat használja), épp attól függően, hogy hol melyik praktikusabb/logikusabb (kb. azon szempontok szerint is, amiket írtam).(#6135) tothjozsi96 :
"HTML-ben mit érdemes használni mint táblakezelőt?
Vagyis több értelme van a DIV-nek?"
Ennek a kérdésnek ebben a formában semmi értelme. Ha táblázatot akarsz megjeleníteni (tehát indokolt a <table> használata), akkor használj táblázatot, ha pedig a layoutról van szó, akkor azt ne táblázatos formában készítsd, mert az rendkívül rugalmatlan. De ha átfogalmazod a kérdést valami értelmes változatra, akkor még talán tudunk is válaszolni arra, amire kíváncsi vagy.[ Szerkesztve ]
Sk8erPeter
-
tothjozsi96
addikt
válasz Sk8erPeter #6137 üzenetére
Igazából én egy P2P oldalt akarok megírni, azért kérdeztem a PHP topicban hogy cookie vagy session ...
De szerintem a <table> használata lehet ajánlottabb lenne, mert nagyon kevés helyre kellene ez a layout.
És table-n belül a div működik úgy is ha csak bizonyos helyre kell. -
Kommy
veterán
Sziaszatok,
phpbb fórumba akarok egy oldalt csinálni, amiben html oldalt kell kreálnom, viszont az adatokat csak php-val tudnám megoldani. Jelenleg iframe-el van berakva a megjelenitendő adat (jelenlegi oldal).
A kockák egyetlen php fájl, ami paraméterben kap egy számot és e szerint írja ki az adatokat, a legnagyobb bajom ezzel a megoldással, hogy a méretet állandóan át kell írogatni az egyes iframekre, hogy látszódjon minden adat, jó lenne ha ez automatikus lenne.
-
Sk8erPeter
nagyúr
válasz tothjozsi96 #6138 üzenetére
"De szerintem a <table> használata lehet ajánlottabb lenne, mert nagyon kevés helyre kellene ez a layout.
És table-n belül a div működik úgy is ha csak bizonyos helyre kell."
Mi van?! Sokszor egyszerűen nem értem a mondataidat. Mi az, hogy "kevés helyre kellene ez a layout"? Én a page layoutról beszéltem, abból egy van, ez határozza meg a látható elemek elhelyezkedését. Na, erre mondtam, hogy NAGYON NEM ajánlott a <table>, nem véletlenül nem divat, hanem azért, mert rettentően rugalmatlan tud lenni, nem tudod szabadon pozicionálni az elemeidet, táblázatba ágyazott táblázatokkal kell helyenként szenvedni, ha ilyen megoldáshoz folyamodsz, köze nincs a reszponzivitáshoz, és még számtalan potenciális problémát vet fel.
Az eredeti kérdésed is elég értelmetlenül hangzik, nem pontosítottad, az ezelőtti válaszomban arról beszéltem, hogy ha valóban táblázatról van szó (pl. adatok sor-oszlopszerű megjelenítése a cél), akkor nyilván <table>-t használj, ha a lap alapvető megjelenéséről van szó, akkor <div>-eket, sőt, a HTML5-ös elemeket is (<header>, <nav>, <main>, <section>, <aside>, <footer>, stb.).(#6139) Kommy :
És akkor miért a HTML topicba írsz, és miért nem oldod meg PHP-val? Jól érzed, ez így elég durván gány.[ Szerkesztve ]
Sk8erPeter
-
Kommy
veterán
válasz Sk8erPeter #6141 üzenetére
Mivel e szerint csináltam a saját oldalt: [link], de ha php fájlt adok meg neki akkor nem fut le semmi.
-
qfm
senior tag
Sziasztok!
Tudtok valamilyen grafikus programot, amibe kialakítható a divek struktúrája/elhelyezkedése? Régen láttam már valamilyen felosztás kialakító programot, de mivel nem használtam végül, el is felejtettem mi volt az.
Nem teljesen ide tartozó téma:
Ha valakinek van valami jól bevált módszere több nyelvű program készítésére, az egy linket küldhetne privátban, vagy akár itt is. Az általunk kialakított koncepció kicsit talán túlbonyolított, érdekelne egy bevált megoldás is.
-
qfm
senior tag
Igazából mindkettő, de a problémát az adatbázis jelenti. Az egyszerűség kedvéért egy példa, és a koncepció:
Van egy termékeket forgalmazó program/honlap, amire feltöltenek adott paraméterekkel rendelkező termékeket. A feltöltő magyar nyelvű, így létrehoz egy adott objektumot, aminek a nevét magyar nyelven adja meg. Van ugyanebben a cégben egy másik feltöltő, aki használni akarja ugyanezt az objektumot, de angol nyelven. Ilyen jellegű problémára hasonló elképzelés született:
Van egy objektumot tartalmazó tábla, mely a nevet nem string formátumban, hanem azonosítóként tárolja.
Van egy szótár tábla amiben az elsődleges kulcs mellett van egy név azonosító mező, valamint egy nyelv. Erre a név azonosító mezőre hivatkozik az objektum, és mindig a megfelelő nyelven kéri le.
Pl.:
Termék (azonosító, név_azonosító, további_attribútumok)
1, 3, "bármilyen további mező"
Szótár (azonosító, név_azonosító, nyelv, fordítás)
1, 3, "magyar", "kalapács"
2, 3, "angol", "hammer"Ekkor a nevek közül az kérdeződik le, amelyik a programban kiválasztott nyelven van. A helyzet ott bonyolódik, hogy ebben a programban mind a neveket, mind a nyelveket dinamikusan a felhasználók töltik fel. Ezért érdekelne valamilyen optimálisabb megoldás, ha létezik. (a példa egy leegyszerűsített kivonat csak)
Elnézést a hosszú házzászlósáért, és köszönöm a válaszokat a másik kérdésemre, megfogom őket nézni.
Ui.: fontos kritérium, hogy nem hozhatok létre annyi példányt az adatbázisban ahány nyelv van, hisz az adathalmaz csupán 10%-át teszik ki a dinamikusan változó nevek, és nagyon nagy pazarlás lenne.
[ Szerkesztve ]
-
cidalain
veterán
"Ui.: fontos kritérium, hogy nem hozhatok létre annyi példányt az adatbázisban ahány nyelv van, hisz az adathalmaz csupán 10%-át teszik ki a dinamikusan változó nevek, és nagyon nagy pazarlás lenne."
Akkor vedd két részre a táblát:
-dinamikusan változó nevek
-90%-nyi egyéb adathalmazA dinamikusanból csinálj annyit ahány nyelv van. Ebben az esetben nincs pazarlás, mert minden adat csak 1× van meg, viszont nem kell szótártáblákkal szarakodni.
Termék univerzális adatai tábla
Termék id | további attribútumok amik nyelvfüggetlenek
1 | 13 kg | 12×33×44 mm | 1234 FtTermék nyelvfüggő szöveges adatai tábla
Termék id | nyelv id | termék név | termék leírás | termék egyéb fordítandó szöveges cuccai
1 | HU | Kalapács | kéziszerszám
1 | EN | Hammer | hand toolVagy ez nem járható?
[ Szerkesztve ]
>> GearBest Club Veszprém << >> https://www.facebook.com/gbc.veszprem <<
-
martonx
veterán
Már volt itt vita a fórumon arról, hogy szvsz nem hatékony (kód futási szempontból) adatbázisban tárolni a fordításokat. PHP esetében ott vannak a .po file-ok, ASP.NET vonalon .resx fileok (amik dll-be fordíthatók, így még a fordítás file IO erőforrása is minimalizálható, mert elinduláskor egyszer beolvasódnak és utána már csak használni kell memóriából).
Én kérek elnézést!
-
tothjozsi96
addikt
Olyan kérdésem lenne hogy van egy <div>-ekből álló menüm.
És úgy szeretném hogy legyen rajta border-left is, tehát elválasztó vonalak.
De az a baj hogy a szöveget nem tudom középre helyezni.
Próbáltam már text-align:center-rel is, de nem megy.Mutatom.
HTML:
<div id="menu">
<ul>
<li><a href="login.php">Bejelentkezés</a></li>
<li><a href="signup.php">Regisztráció</a></li>
<li><a href="recover.php">Jelszó emlékeztető</a></li>
</ul>
</div>CSS:
div#menu {
width: 100%;
background: #DADAD3;
border: 1px solid #AEAEA9;
}
div#menu ul {
height: 20px;
margin: 0;
padding: 0;
list-style: none;
}
div#menu li {
float: left;
display: inline;
} -
PumpkinSeed
addikt
válasz tothjozsi96 #6149 üzenetére
Paddinggal tudod szabályozni.
"Akinek elég bátorsága és türelme van ahhoz, hogy egész életében a sötétségbe nézzen, elsőként fogja meglátni benne a fény felvillanását." - Kán
Új hozzászólás Aktív témák
- Honor Magic V2 - origami
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Politika
- Mibe tegyem a megtakarításaimat?
- Android alkalmazások - szoftver kibeszélő topik
- Huawei Mate 10 Pro - mestersége az intelligencia
- gban: Ingyen kellene, de tegnapra
- Realme 8 - az igazi nyolcas
- Mini-ITX
- Kerékpárosok, bringások ide!
- További aktív témák...