Új hozzászólás Aktív témák
-
Dromi
tag
válasz
cidalain #7093 üzenetére
Aha arra gondoltam, de ezt hogy kell megcsinálni? Most a tumbrl-ról beszélek, ott meg lehet nyitni ezt a html-s cuccot
Privátban bemásolom megmondot mit kell csinálni?
Galériát, hogy lehet, itt csinálni? azt akarom, hogy a képek ne lefelé menjenek, hanem első kép, katt és utána vízszintesen a többi?
-
-
Panhard
tag
válasz
cidalain #6991 üzenetére
Ez nem tetszés kérdése. Attól, hogy te még nem hallottál erről, van ilyen. Nagyon sok helyen használják. Lényege, hogy a html fájl tartalmának egy része, ahol ez az include van, a php kimenete lesz. Én arra akarom használni, hogy a html fájl megnyitásakor egy listbox-ba betölti adatbázisból a lehetőségeket. Így:
html oldal:
<form name="dtForm">
<select name="startdate">
<?php include 'date.php';?>
</select>
</form>php file kimenete:
<option value="2017-08-17">2017-08-17</option>
<option value="2017-08-16">2017-08-16</option>
<option value="2017-08-15">2017-08-15</option>
<option value="2017-08-14">2017-08-14</option>
<option value="2017-08-13">2017-08-13</option>
<option value="2017-08-10">2017-08-10</option>
<option value="2017-08-08">2017-08-08</option>
<option value="2017-07-25">2017-07-25</option>Eredmény: mire a html oldal betöltődik, már ott a kész lista a formban, mintha az a html oldalban lenne fixen beírva.
-
Panhard
tag
válasz
cidalain #6988 üzenetére
Nem. Nézz utána, nem kell átnevezni semmit. HTML fájlban is lefut, és a php fájl kimenetét írja be a html-be. Ha megnézed a böngészőben a html fájl forrását, ott már nem látod azt az include sort, csak a php kimenetét.
Nekem pl: a gépemen xampp szerver van fennt, ezzel szoktam tesztelni, azon működik, de a szolgáltató tárhelyén nem. Goldolom ez tiltva van. De lehet-e engedélyezni? -
Septum15
aktív tag
-
norbert1998
nagyúr
válasz
cidalain #6964 üzenetére
Az a baj, hogy tényleg nem térhetnek el tőle. Ha azt írják, hogy attól lesz barnás a betű színe, hogy
img{
height: 300px;
}És a diák nem ezt írta, pontlevonás.
Nyilván ég ilyen esetén módosítják, javítják, de ha nem, akkor valóban ez az érvényes. Sarkalatos példa, de a javító kulcs itt jogszabály erejű. -
Panhard
tag
-
-
PoniLoW
csendes tag
válasz
cidalain #6802 üzenetére
[link]
Itt a kódA kisebb felbontású laptopomon egyébként középen van, az asztali gépen viszont balra, gondolom azért, mert nem százalékokban adtam meg a szélesség értékeket, hanem pixelben.
A következő kérdésem az lenne, hogy hogyan lehetneúgy megcsinálni, hogy a felhasználó monitorjának felbontásától függetlenül töltse ki az egész képernyőt, értem ezalatt azt, hogy a footer div ha tegyük fel nincs semmi tartalom akkor is a képernyő alján legyen, ne pedig egyből a header alatt (ez gondolom a content div height:100% tulajdonságával van kapcsolatban).
Köszönöm!
-
boneyard
tag
válasz
cidalain #6651 üzenetére
Köszi a választ. Az a baj, h elég rugalmatlan a nagyker ilyen szempontból.
Közben megtaláltam a neten, h a Selenium WebDriver és a BeautifulSoup segítségével elvileg megoldható. A seleniummal sikerült is definiálni a Firefox-ot, mint drivert, aztán megnyitni a nagyker oldalát és definiálni a felhasználónév és jelszó mezőket, csak mindent google-ből kell vadásznom, mert nem használtam pythont eddig, illetve nem is tudom, h mennyire biztonságos ez a Selenium -
tzimash
őstag
-
Panhard
tag
válasz
cidalain #6562 üzenetére
Arra kellene, hogy van két weboldal ugyanarról a szerverről, és csak akkor tudom mindkettőt megjeleníteni, ha mindkettőt új munkamenetben nyitom meg. Ha csak új lapon nyitom meg, és ha frissítem az egyiket, az átveszi a másik oldal tartalmát.
Az igazi megoldás az lenne, ha egy lapon tudnám a két oldalt megjeleníteni. Ezért gondoltam, hogy keretekbe rakom őket, de így nem működik, mert frissítéskor az egyik átveszi a másik tartalmát. -
martonx
veterán
válasz
cidalain #6554 üzenetére
Plusz tegyük hozzá, hogy őszintén ki tanítanak? MErt aki jó szakember mind elment a tanári fizetés 3-4 szereséért programozni a versenyszférába (más kérdés, hogy attól, hogy valaki jó szakember még nem feltétlenül lesz jó tanár).
Így aztán akik tanítják, azok elképesztően nem értenek hozzá (tisztelet annak az 1-2 kivételnek országos szinten).
De ennél is nagyobb baj, hogy akik a tanterveket összeállítják még annyira sem értenek hozzá, akik pedig nemzeti szinten meghatározzák a főbb irányszámokat, azok meg iskolát is legutóbb akkor láttak közelről, amikor anyu/apu elintézte nekik párt vonalon valamikor a 80-as években, hogy mégse basszák ki őket a suliból, legyenek inkább magántanulók / hagyják őket átcsúszni stb... -
tzimash
őstag
válasz
cidalain #6551 üzenetére
Teljesen igazad van. És ez az összesen 4 (előbb egyel többet írtam, de megnéztem az órarendben) alkalom még átlagon felülinek is mondható. És ez a mindenből egy kicsit, de igazából semmit elv kísér végig a 7 félév alatt. Az is igaz, hogy ez szabadon választható tárgy, de a kötelezőkkel is ez a helyzet. Ahelyett, hogy egy nyelvet tanítanának, de azt alaposan, 3-4-be belekapunk felületesen.
Ha minden igaz ettől az évtől változtatnak rajta, de ez engem már nem érint. -
Chrystall
senior tag
válasz
cidalain #6539 üzenetére
Következetesen mindig, ugyanazokat a betűket, ugyanúgy. A nagy T-t rontja el pl. ha vastagon szedettre állítod. Meg az i-t, abból a kicsit is nagyot is, szintén ha vastagon szedett. A nagy I az kifejezetten ronda, tehát nem az az elnézhető kategória, olyan mint egy felkiáltójel. De mindegy, átállítottam más típusra a címeket, a google forumába pedig írtam egy üzenetet, ha akarnak majd kezdenek vele valamit.
-
Chrystall
senior tag
válasz
cidalain #6537 üzenetére
Nem igazán nyugtat meg, de úgy tűnik elnéztem a dolgot, a Chrome-mal lehet valami gond, mert mikor letöltöm a TTF-et és csinálok egy új oldalt egy sor szöveggel, @font face-szel pedig ráirányítom a TTF-re úgy is elrontja. Azt hittem a Google betűtípus gyűjteményében lehet valami hiba, mert az oldalam arra van linkelve. De úgy tűnik nem. Nem jó hír...
-
zolka95
őstag
válasz
cidalain #6447 üzenetére
Az a kérdésem, hogy hogyan lehet megcsinálni azt hogy ha a fejléc menüjében rákattintok valamire akkor az új oldalon is ott legyen a fejléc. A startlapnál nem így van ez igaz, rosszat linkeltem, de a legtöbb oldalnál így van. Azokra gondoltam. Pl: ez.
Ez az egész egy táblázat lenne? -
honda 1993
senior tag
válasz
cidalain #6348 üzenetére
Sajnos nem stimmel valami.
ez került a head részbe--><div id="fb-root"></div>
<script>(function(d, s, id) {
var js, fjs = d.getElementsByTagName(s)[0];
if (d.getElementById(id)) return;
js = d.createElement(s); js.id = id;
js.src = "//connect.facebook.net/hu_HU/sdk.js#xfbml=1&version=v2.0";
fjs.parentNode.insertBefore(js, fjs);
}(document, 'script', 'facebook-jssdk'));</script>ez pedig oda ahova a boxot szeretném elhelyezni.--> <div class="fb-like-box" data-href="https://www.facebook.com/FacebookDevelopers" data-width="200" data-height="300" data-colorscheme="light" data-show-faces="true" data-header="true" data-stream="false" data-show-border="true"></div>
Ezután cssben .fb-like-box {position: absolute; width: x px; height: y px; }
De sajnos nem akar megjelenni. -
honda 1993
senior tag
válasz
cidalain #6346 üzenetére
Megnéztem és sajnos úgy sem akart működni.
Azon az oldalon amit linkeltem, vannak ezek a menupontok: HTML5, XFBML, IFRAME, URL.Nem úgy kell csinálni hogy az előbb felsorolt menüpontok mindegyikéből kimásolom a forráskódot ugye ?
Mert én úgy értelmeztem hogy lehet "választani" hogy melyik módszerrel akarom megcsinálni.Bár már most érzem hogy ez a kérdés nagyon idióta dolog volt, mert utánanéztem és látom hogy ezek mind kellenek.
-
martonx
veterán
válasz
cidalain #6323 üzenetére
Egy gyors megjegyzés: 320X480-at felejtsd el, szvsz 480X800 a legalacsonyabb igaziból is használt felbontás, amire van értelme optimalizálni.
Mi 480, 720, 1024, 1366 és >1920 képernyő szélességekre szoktunk css-t optimalizálni, pontosabban az ezek közötti intervallumokra, azaz 480-720, 720-1024, 1024-1366, 1366-1920, >1920. -
Zedz
addikt
válasz
cidalain #6323 üzenetére
Mint írtam ezek a határok minden oldalnál mások és mások lehetnek. Lehet egy pofon egyszerű weboldalhoz elég annyi, hogy mondjuk 1000px felett 960px a content szélessége, alatta pedig 80%, és akkor jó lesz az összes telefonra. De olyan is lehet, hogy van egy bonyolultabb oldalad, amin rengeteg minden van, és ezt több breakpointon keresztül szeretnéd rendezgetni. Ekkor mondjuk megfogod a böngésződ, összébb húzod. Ha pl. összeszakad az oldal 950px-nél, akkor oda teszel egy breakpointot. Tovább kicsinyíted az ablakot, összeszakad 850px-nél is, még egy breakpoint. Persze ezt nem kell addig csinálni amíg 100 width-re nincs optimalizálva az oldal.
-
Zedz
addikt
válasz
cidalain #6321 üzenetére
Igazából szerintem sok mindentől függ az amit szeretnél. Ha tiszta struktúrát akarsz akkor egyszerűen csak logikusan és előreláthatóan próbálj meg gondolkodni, majd ez alapján felépíteni a HTML kódod. Kerüld az ad-hoc megoldásokat, a végtelenül mennyiségben egymásba ágyazott diveket.
A reszponzív design kicsit bonyolultabb téma, szvsz nincs olyan aranyszabály, hogyha ezzel meg azzal az értékkel dolgozol, akkor tuti jó lesz. Minden oldaladnál más és más lehet a jó, tesztelni kell és majd látni fogod a helyes megoldást.
Az, hogy ezt 1 vagy több CSS fájlban oldod meg az tőled függ. Én például több CSS fájlban dolgozok. Van egy alapom, amit mindig kiegészítek az aloldalakra specifikusan érvényes stílusokkal. A reszponzív designnál is van egy alap amit az alap CSS fájlba írok, és vannak csak 1-1 részre tartozó változtatások, azok mennek az szétszedett fájlokba.
Persze a weboldal végül mindig csak 1 CSS-t fog berántani a mindig kellő stílussal, de ezt már a SASS és szerver oldja meg.
-
Sk8erPeter
nagyúr
válasz
cidalain #6298 üzenetére
Ezt ne, ez így gusztustalan. Normálisan megírt eseménykezelőkkel csinálja meg, mindenki kerülje az ilyen inline bedobált megoldásokat:
http://www.slideshare.net/fgalassi/refactoring-to-unobtrusive-javascript -
honda 1993
senior tag
válasz
cidalain #6190 üzenetére
Na annak orulok hogy ezt megkerdezted, ugyanis en pont most irtam valamit a php forumba.
A lenyeg hogy nem tudom hogy pontosan hogy is kell ezt elkezdeni.
Pl ha esetleg elmagyaraznad hogy hogy is mukodik az altalad javasolt megoldas, ( forummotor ) segitsegevel. Annak orulnek.
De gondolom valamennyi php kodra igy is ugy is szugseg van nem ?
Mert oszinten szolva szeretnem ha lenne is vele egy kis melo, es nem csak siman fel kellene telepiteni. -
tothjozsi96
addikt
válasz
cidalain #6175 üzenetére
Az a lényege az egésznek hogy eddig úgy volt hogy:
<div id="logo"></div>És css-ben megvolt adva hogy:
div#logo {
background: url('pic/logo.png');
width: 1000px;
height: 130px;
margin: 0 auto;
}És több kinézet volt, minden kinézethez más fejléc volt készítve, na most arra lennék kíváncsi hogy header-rel hogy?
Most úgy van hogy <header><img src="logo.png"></header>Vagy esetleg a header-t úgy hogy css-ben?!
header {
background: url('pic/logo.png');
width: 1000px;
height: 130px;
margin: 0 auto;
}Tudtommal a header csak a fejléc-hez kell mint HTML 5 tag.
(#6176) honda 1993
Mivel a HTML oldal szerintem teljesen lényegtelen a méret. -
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.
-
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
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. -
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.
-
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). -
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. -
martonx
veterán
válasz
cidalain #6051 üzenetére
"rajossz hogy az egyeb programozasi ismeretekkel ketszer annyit kereshetsz mint a webes programozassal. :-)"
Ez szerintem nem feltétlenül van így. Nyílván ha valaki annyira szuper kocka, hogy fejben oszt és szoroz mátrixokat, akkor játék engine programozóként kb. annyit kérhet el, amennyit nem szégyell. De lássuk be világviszonylatban van kb. száz ilyen programozó.
A valóságnak rengeteg árnyalata van, a profi webfejlesztők is simán tudnak bruttó 600-900K között keresni.
Szvsz pont a webfejlesztő az egyik legnehezebb programozás irány, mert kenni-vágni kell a html-t, css, js-t, minimum egy szerver oldali nyelvet, és minimum egy sql típust (mssql, oracle, postgre, mysql, nosql variánsok stb...). -
Aureal
őstag
válasz
cidalain #5985 üzenetére
Nyilván ha ott az opció akkor nem kérdés.
Erre vhol régen láttam vmi megoldást, még talán dragonfly alatt is kell vmit pötyögni nem tudom már. Sajnos nem tudom hova mentettem le azt az oldalt már és fogalmam nincs a neten is kb hol található, de emléxem hogy meg lehetett csinálni vhogy. -
martonx
veterán
-
Sk8erPeter
nagyúr
válasz
cidalain #5877 üzenetére
"Csinálnék egy utcák JS tömböt. Minden eleme egy kételemű tömb lenne: utcanév, telephelyazonosító."
Ez kisszámú cégmennyiségre még működik, de amint növekszik az adatbázisba felvett cégek száma, ki lehet dobni ezt a megoldást, különben durva erőforrásokat igényel a betöltés+keresgélés kliensoldalon minden alkalommal (persze lehet cache-elni, ha mégis nagyon kell). Szerveroldalon kéne inkább tárolni, adatbázisban, aztán autocomplete-tel felajánlani a lehetőségeket. -
martonx
veterán
válasz
cidalain #5653 üzenetére
Sk8erPeter jól megválaszolta helyettem. Igyekszünk itt a fórumban a legjobb gyakorlatokat sulykolni, és nem azért, mert az van leírva a könyvben, hanem mert mindenkinek úgy lesz a legjobb, leghatékonyabb a munkája. Aztán persze mindenki úgy csinálja, ahogy akarja, azt fogad meg belőle, amit akar.
-
Sk8erPeter
nagyúr
válasz
cidalain #5656 üzenetére
Végül is mindkettő jó lehet, sőt, a végtelenségig lehet kombinálni (egy elem el lehet látva akár 5 osztállyal is, aztán még vonatkozhat rá egy id szerinti stílusmeghatározás is, nincs azzal gond, ha épp úgy kívánja a feladat), feladatfüggő, hogy valahol érdemes-e id szerint meghatározni a stílust, vagy érdemes külön osztályt létrehozni rá. Szerintem itt is érvényes a DRY-elv (don't repeat yourself), ha azt látod, hogy valamilyen stílus-meghatározás egy az egyben ugyanaz, mint egy korábban már létező osztálynál, akkor az is lehet, hogy érdemes akár egy harmadikat is bevezetni, és azt az osztályt is ráaggatni arra az elemre. Persze azért ezt is mértékkel.
-
Sk8erPeter
nagyúr
válasz
cidalain #5653 üzenetére
Vegyes a megközelítés, de első az, hogy érdemes általánosan megadni a stílusokat, osztályokkal, hogy adott esetben több elemre is ráhúzható legyen (pl. lehet, hogy rájössz, hogy nem csak egy, hanem mondjuk már akár kettő vagy több doboznál is ugyanilyen stílust szeretnél), aztán persze van a ritkábbik eset, amikor tényleg kifejezetten egyetlen elemre szeretnél ráhúzni valamilyen stílust, mert az teljesen egyedi módon néz ki, meg adott esetben mondjuk akár értelmetlen is lenne általános stílus-meghatározást adni - ilyenkor használható akár az id-s stílus-meghatározás is.
Persze gondolom ez nem újdonság, inkább csak arra szerettem volna rávilágítani, hogy elsődlegesen class-ekben érdemes gondolkodni stílus-meghatározásnál, és csak a tényleg nagyon egyedi esetekben id-re megadni a stílust.Pl. a konkrét feladatnál lehet, hogy nem érdemes id-vel megadni a hátteret, ez totál feladatfüggő, ha mondjuk egy relatíve általános háttér lenne (pl. legyen piros a háttér), akkor azt szerintem osztállyal érdemes megadni.
-
cidalain
veterán
válasz
cidalain #5575 üzenetére
function placeToMap(coords) {
var marker = new google.maps.Marker({
position: coords,
map: mapid,
draggable: true
});
}nem teszteltem egyiket sem, csak ideollóztam. ránézésre jó lesz
hozzá kell tenni hogy a címből koordináta elég érdekesen megy a googlenél, van benne hiba bőven.
rohadt pontosan kell beírni a címet a beviteli mezőbe, mert hamar félremegy a dolog. simán berakja a szomszéd falu ugyanolyan nevű utcáját ha úgy jön ki. bár napról-napra javul egyébként (ezt a szomszéd falusat most már nem tudom eljátszani fél éve még ezzel szoptam...). -
Sk8erPeter
nagyúr
válasz
cidalain #5540 üzenetére
"ja, végülis olyan mintha egy XML exportot dolgoznánk fel."
Vagy akármilyen kimenetet.Itt most csak az API felhasználása a lényeg, lehet annak a kimenete XML, JSON, vagy akármicsoda. Az előbb belinkelt példa mondjuk pont text/html kimenetű, de ugyanennek az oldalnak van XML-kimenetű API-ja is, mint azóta kicsit jobban utánanéztem.
"a linkben mindig csak az utolsó, és a következő rész van, ha full listára lenne szükségünk, akkor ezt még el is kellene mentegetni adatbázisba mindig."
Egy normális API-nál múltbeli adatokat is le tudsz kérdezni. Ez is ilyen.
Szóval ilyenkor csak máshogy kellene használni az API-t, most már elkezdett érdekelni, és kicsit jobban belenéztem, itt leírtam:
http://prohardver.hu/tema/weblap_keszites/hsz_11470-11471.html -
Sk8erPeter
nagyúr
válasz
cidalain #5538 üzenetére
Igazából sztem ez egy nagyon egyszerű feladat.
Van hozzá API, a másik topicban már sok-sok forrás be lett linkelve, itt van egy konkrét példa: [link] - na, ebből a kimenetből kihámozni a kérdéses sort pár sor szerveroldali nyelvben történő kódolással simán meg lehet oldani.
Igazából ez a
Latest Episode@12x16^Herpe the Love Sore^Apr/06/2014
Next Episode@12x17^The Most Interesting Man in the World^Apr/13/2014
az, ami érdekes lehet, ezt kell kikeresni az outputból, és már kész is van. -
Sk8erPeter
nagyúr
válasz
cidalain #5536 üzenetére
Nem erről van szó. Távoli szerverről, valamilyen oldalról kotorná ki valahogyan, hogy az adott sorozatnak pl. mikor jön ki a következő epizódja, ezt frissítgetné (csak egy példa). Pl. ütemezett módon, én így értelmeztem.
Itt közben ment tovább a beszélgetés (ahogy látom, Te csak ebben a topicban tevékenykedszúgyhogy gondoltam inkább belinkelem): [link].
-
-
Sk8erPeter
nagyúr
válasz
cidalain #5461 üzenetére
"Tipikus CMS kód a forrás alapján egyébként."
Hát egyáltalán nem.Ezek szerint nem annyira nézegetted komolyabban CMS-ek kódjait, azokban van legalább valamilyen szintű konzisztencia. Ebben a kódban nincs.
Meg általában a CMS-ek kódjában nincs össze-vissza kutyult angol-magyar elnevezés a class-oknál, id-knál. Ahhoz már komoly erőfeszítés kell, hogy olyan theme-et tákoljon össze valaki, ahol ennyire nem egységes a kód, és hibák is vannak benne. Mármint most nem csak a korábban említett tagek keveredéseiről beszélek, hanem hogy attribútumok értékei előtt, még az idézőjel előtt szóköz, aztán egyik helyen aposztróf, másik helyen sima idézőjel használata, stb. Igaz, pl. az Artisteer élen jár a tákolmány theme-ekben, de annak a végső kimenetében is azért fel lehet fedezni a népszerűbb PHP-s CMS-ek kódmaradványait.
Ha kiderülne, hogy CMS, azon jóóóóól meglepődnék. (Ha valami őskövület darab, vagy egy olyan, amivel ilyen tákolmányt lehet összehozni, akkor legalább megtudjuk, mit kell kidobni az első kukába.)
A népszerűbb CMS-ek manapság már ügyelnek olyasmire is, hogy mondjuk a menü ne egy table legyen már, annak túl sok köze például a reszponzivitáshoz sem lesz."egy szóval sem cáfolta amikor utaltam rá"
Nem tudom, hol utaltál rá, de lehet, hogy nem értette, miről beszéltél."A kódokhoz rohadtul értesz, de néha annyira felmegy nálad a pumpa itt a topicban hogy az hihetetlen
"
Bennem egy pillanatig nem ment fel a pumpa, te valamit benézel.
Amúgy nemcsak belőlem váltottad ki a kényszert, hogy három oldalról magyarázzuk el neked, mi a pálya például a webszerverek kapcsán, ha arra gondoltál.Ha oltogatnak, az nem feltétlenül azt jelenti, hogy a másik dühöng.
Igazából tényleg nem jutunk előrébb, szóval egymás közt nem igazán érdemes vitázni, majd ha leírja a nyűgjét, akkor talán kiderül, mi a pálya, vagy nem. Nem a mi érdekünk, hogy előrébbjusson, mi csak segíteni vagyunk itt, szóval rábízhatjuk a továbbiakat nyugodtan, mi meg átrágtuk a témát.
-
Sk8erPeter
nagyúr
válasz
cidalain #5459 üzenetére
Honnan veszed, hogy CMS-t használ?
Most direkt visszatekerésztem a hsz.-eit egészen az elejéig, és egy szóval nem említette, hogy azt használna.
""Ezeket javítsd ki első körben, így még lesz is esélyed rá, hogy bármi script működjön."
Ez ugyanúgy nem értelmes, mert ahogy leveszem, ő nem fejlesztő, a forráshoz nem tud nyúlni, lövése sincs mit és hogyan javítson."
Mi az, hogy nem értelmes?Hát ember, ez a HTML-szerkesztés topic, ez a tanács értelmes, és leírja a probléma valószínűsíthető okát. Ha nem férne hozzá a forráskódhoz valamilyen módon, nem jött volna ebbe a topicba.
Azzal meg nem tudunk mit kezdeni, hogy képtelen leírni, hogy mi a nyűgje. -
Sk8erPeter
nagyúr
válasz
cidalain #5441 üzenetére
"ne listazodjanak a fajlok ha direktben beirjak egy mappajat, amiben nincs index fajl. Ha igy nezem akkor itt semmifele szerveres problema nincs"
Hogyne lenne már szerveres probléma, ha ezek szerint listázódnak a fájlok, amiknek rohadtul nem kéne? DE, VAN szerveres probléma, mégpedig az, hogy nincs beállítva, hogy ne tudja már akárkicsoda végigturkálni a publikus könyvtár tartalmát, ha ott nincs kezdőfájl.
Most ebből melyik rész nem tiszta?"A user gondoskodjon arrol hogy a publikus feluleten elrejtsen valamit"
Hogy mi van? Most ki a user, ki a fejlesztő? Ha a user alatt azt érted, akinek a fejlesztő elkészíti a weboldalt, akkor nem az ő feladata, hogy bármilyen rejtegetéssel foglalkozzon. Ha a fejlesztő szemszögéből nézzük, akkor pedig az ő felelőssége megoldani, hogy ne lehessen csak úgy kotorászni a webszerver publikus könyvtárában. Tulajdonképpen ezek már korábban is elhangzottak, csak most nem értem a rugózást. -
martonx
veterán
válasz
cidalain #5441 üzenetére
Hű te nagyon kevered a szezont a fazonnal.
Most őszintén, szerinted mennyi nem publikus könyvtárral rendelkezik egy webszerveren futó alkalmazás?
Ráadásul nehogy már a usernek kelljen kamu index.html-ekkel elfednie a webszerver beállításainak a hiányosságait.
Abszolút alap, hogy web szerver soha nem listáz ki semmit. Innen indulunk minden webszervernél. Aztán jöhetnek a kivételek (ftp, webdav, akármi), de mindig ez az alap, hogy könyvtár tartalma soha nem listázható ki.
Bárhogy nézed, ez szerver beállítási probléma. -
Sk8erPeter
nagyúr
válasz
cidalain #5439 üzenetére
"szerintem a rendszer mappájának nincs köze a webszerver rendszer mappájához."
What? Szerinted a publikus könyvtár nem az egyik webszerverkönyvtár?A gond, amiről martonx is beszélt szerintem, hogy "Nem szerettem volna, hogy ennek a mappának a teljes tartalmát láthassák" - eleve ott kezdődik, hogy miért láthatja bárki is bármely könyvtárnak a teljes tartalmát? Erre írta, hogy hibásan van konfigurálva a webszerver.
Apache-szerveren már ez a .htaccess-sor is segítene:
Options -Indexes
Új hozzászólás Aktív témák
Hirdetés
- Óvodások homokozója
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- sziku69: Fűzzük össze a szavakat :)
- Milyen házat vegyek?
- Motorola Edge 50 Neo - az egyensúly gyengesége
- AMD vs. INTEL vs. NVIDIA
- exHWSW - Értünk mindenhez IS
- Magga: PLEX: multimédia az egész lakásban
- Kerékpárosok, bringások ide!
- Nintendo Switch 2
- További aktív témák...
- Kingmax 1x2GB DDR3-1333 RAM
- ÁRGARANCIA!Épített KomPhone Ryzen 7 9800X3D 32/64GB RAM RX 9070 XT 16GB GAMER PC termékbeszámítással
- Telefon felvásárlás! Samsung Galaxy A15, Samsung Galaxy A25, Samsung Galaxy A35, Samsung Galaxy A55
- Honor Pad X8 64GB, Wi-Fi, 1 Év Garanciával
- Apple iPhone 14 128GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest