- A Micron újszerű módszerrel javítja QLC-s SSD-jének sebességét
- Mini-ITX
- Azonnali informatikai kérdések órája
- Nagyon erős ajánlattá kezd válni a SteamOS
- Milyen belső merevlemezt vegyek?
- HiFi műszaki szemmel - sztereó hangrendszerek
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Milyen videókártyát?
- Kormányok / autós szimulátorok topikja
- Házimozi haladó szinten
Új hozzászólás Aktív témák
-
Soak
veterán
válasz
trisztan94 #2261 üzenetére
Meg tudod indokolni hogy miert "gyulolod" a php-t?
-
martonx
veterán
válasz
trisztan94 #2263 üzenetére
Ha már felhőkben keresel, és .Net kedvelő vagy, akkor nézz már rá az Azure-ra...
-
martonx
veterán
válasz
trisztan94 #2261 üzenetére
Miért kerül többe egy .Net-es tárhely, mint egy PHP-s?
Ha gondolod mutatok ingyenes .Net-es tárhelyet is neked (per pillanat kettő ilyen hoszting cég közül is választhatsz), cserébe mutass ezeknél olcsóbb PHP-s tárhelyeket -
Sk8erPeter
nagyúr
válasz
trisztan94 #2263 üzenetére
Ha rákeresel úgy, hogy "content slider" vagy hasonló, akkor milliónyi találat lesz.
Ilyesmik.Amiket linkeltél, azok biztos jók, de csak külföldi szerverek, meg ha jól értettem gyors rápillantás alapján, havi díjak, és annyiért pedig kapsz ASP.NET-es tárhelyet is havonta, PHP-s tárhelyet meg főleg.
"Arra értettem, hogy aki tényleg tudatlan és azzal csinálja, és "ő már webszerkesztő"-nek titulálja magát, na az a gáz"
Ebben természetesen egyetértünk, de az előbb még amellett érveltél, hogy neked nem tűnnek túl profinak "a CMS-es megoldások". Erre reagálva mondtam, hogy ne pár vérjani (a vérpisti már unalmas) munkája alapján ítélkezz.
-
cucka
addikt
válasz
trisztan94 #2261 üzenetére
A node.js tök jó http api-k fejlesztésére. Ha csak sima weboldal backend-nek használnád, arra nem igazán alkalmas, oda a php sokkal jobb választás.
-
Sk8erPeter
nagyúr
válasz
trisztan94 #2261 üzenetére
Hát szerintem a JavaScript sem az a kifejezetten szép nyelv, és akkor finoman fogalmaztam...
"A node.js-es tárhelyek pedig kb egy árban vannak a php-sokkal"
Tudsz mutatni konkrét példát?Milyen animációt kell nézni a belinkelt oldalon?
Hogy jobbra-balra lehet lapozni? Ebben mi a különleges? Bármelyik jQuery slider plugin tudja ezt.
-
Sk8erPeter
nagyúr
válasz
trisztan94 #2257 üzenetére
Nem, nincs olyan szó, hogy "inprofi"...
Pedig nagyon komoly oldalak is készülnek CMS-ekkel, pl. konkrétan én a Drupalra gondolok. A Joomla személyes véleményem szerint egy fostalicska, próbáltam, nem győzött meg, de nyilván ebben is készülnek elég komplex oldalak, ebben sem szabad általánosítani. A WordPress-t legtöbbször blogolásra használják (nyilván vannak más célok is). A Drupalt meg mindenfélére.
Amúgy biztos a White House hivatalos oldalának fejlesztői is úgy gondolták, hogy a CMS-ek nem profik, ezért választották a Drupalt az oldaluk motorjául...
Csak futólag kukkants rá a cikkre:
http://www.whitehouse.gov/blog/2012/11/20/open-source-and-power-community
Leírják, merre, miért, hogyan esett a választás a Drupalra. Lényeg: hatalmas fejlesztői közösség, dinamikus fejlődés, folyamatos változások. Amúgy most már a Symfony framework a Drupal 8 alapmotorja.
Az oldal forráskódján is látszik amúgy, hogy tipikus Drupalos (/sites/default/files/... elérési utak, stb.).
Tevékenykednek a fejlesztői a drupal.org oldalon is:
http://drupal.org/user/2356044
vannak hozzájárulásaik modulokhoz (commit), meg vannak saját moduljaik.A lényeg: az, hogy valaki CMS-t használ, nem azt jelenti, hogy egy vérf@szjankó is össze tudná kattintgatni azt az oldalt. A CMS-hez a modulfejlesztésnek is megvan a maga komoly befektetési ideje, de a többedik oldal után bőven megtérül, hogy nem kell ugyanazokat az ismétlődő folyamatokat újból és újból végigszopni.
Ahogy igaz ez egy framework használatára is.
De manapság a Drupalra amúgy is azt mondják, hogy nemcsak CMS, hanem framework is, és másik irányból nem csak framework, hanem CMS is. -
fordfairlane
veterán
válasz
trisztan94 #2257 üzenetére
Node.js-szel van valakinek tapasztalata? Mindig is jobban szeretttem a Frontend scriptelést, mint a backend-et, ez úgy néz ki pont ideális nekem
A node.js egy javascript backend.
-
Sk8erPeter
nagyúr
válasz
trisztan94 #2253 üzenetére
"Amúgy is, a srác azt mondta, ha ez jól alakul akkor lesz több melója is nekem, szóval ezért is mentem egy "kicsit" ár alá."
Ja, aztán abból indul ki, hogy ha már múltkor is "jutányos" áron vállaltad, akkor miért nem vállalod a többit is olyan occssón.Szerintem ha egy lélektani határnál többet nem hajlandó megfizetni, akkor el kell küldeni a francba.
Egyébként mondom, az elején nem is vágtam, hogy az egész oldal úgy, ahogy van, 15k, ha ezt előre tudom, nem is mondok ilyeneket, mint hogy SEO, meg hasonlók.
De az egészet ki lehetett volna kerülni úgy, hogy pont az AJAX-ozást szarod le, és akkor legalább könyvjelzőzhetők az oldalaid (akkor statikus, és nem kellett volna plusz időt (igaz, nem túl sokat) töltened a HTML5 history-zással és hasonlókkal).
"Azért annyira nem volt bonyolult az a JS API-n keresztüli dolog, de nem is tudtam, hogy van iFrame-es megoldás. Azt honnan lehet szerválni?"
[link]
Ettől még amúgy nyilván sokkal szebb az a megoldás, amit Te választottál, hogy a JS API-t használod, tehát ne szokj át az iframe-es megoldásra, csak említettem.Amúgy én ilyen statikusnak induló weboldalaknál is jobbnak látom egy CMS vagy valami framework használatát, a franc tökölne a menü hierarchiájával és hasonlókkal, meg választanék egy igényes template-et, szép kóddal, ami könnyen átszabható, és ami cross-browser működést lehetővé tesz (Drupalnál kedvencem a Zen).
-
Jim-Y
veterán
válasz
trisztan94 #2253 üzenetére
Azért annyira nem volt bonyolult az a JS API-n keresztüli dolog, de nem is tudtam, hogy van iFrame-es megoldás. Azt honnan lehet szerválni?
-
cucka
addikt
válasz
trisztan94 #2234 üzenetére
Nagyon sok minden el van csúszva firefoxban sajnos, a fő layout elemek nem ugyanakkorák, betűméret, pozicionálások.
Ez nincs így. Két dolog van:
- Minden böngészőnek van egy default stíluslapja, amelyek eltérhetnek egymástól. Lehet találni a neten mindenféle reset css-eket, ami lenullázza ezeket az alapértelmezett értékeket.
- A különféle böngészők eltérően renderelik a szövegeket, tehát itt egész egyszerűen nem lehet pixelpontos megjelenésre számítani. Ha a weboldalad kinézete bárhogy is függ attól, hogy hogyan rendereli a szövegeket a böngésző, akkor rosszul építetted fel a layout-ot.15.000-ért nem fogok mindent támogatni.
Szerintem örülhet, hogy ennyi pénzért valaki elvállalta a munkát. Egy tapasztalt fejlesztő, aki ebből él, 15 ezerért a szövegszerkesztőt sem fogja elindítani neki.Hát sajnos ezt nincs módomban tesztelni. Nem lehet valahogy azt is felrakni a 9 mellé? Esetleg még a hatot?
Hozzávetőleges eredményekért használd az Explorer kompatibilitási módját.
A legjobb megoldás pedig, ha virtuális gépen tartasz egy másik Windowst, régi Explorerrel. A Win nem tud egy időben több különböző verziójú Explorert futtatni.Egyébként sanszos, hogy valamit rosszul csinálsz, ha ilyen böngésző inkompatibilitásokkal küzdesz. A weboldalak 99%-ához nincs szükség semmilyen böngészőspecifikus dologra. Ha okosan írod meg a CSS-t, akkor még az IE6-IE7 specifikus dolgoknak sem kell külön böngészőfüggő stíluslap, Javascriptnél meg behúzod a jQuery-t (vagy mást), ami lényegében elsimítja az összes eltérést a böngészők között.
-
martonx
veterán
válasz
trisztan94 #2234 üzenetére
"Mondtam is a megrendelőnek, hogy js-heavy oldalt csinálok, így aki nem használ js-t az vessen magára, 15.000-ért nem fogok mindent támogatni." - amennyire én látom, ez egy 4 lapból álló szimpla bemutatkozós portál.
Minek ide js-heavy, meg PHP? Ez 4 darab statikus html, plusz 1 js file, meg 1 css file.
De ha mondjuk ajax-ozunk, akkor legyen másik 4 statikus html, amiket be tudsz húzni a főoldalba. 15K-ért minek ezt túlbonyolítani? -
Sk8erPeter
nagyúr
válasz
trisztan94 #2236 üzenetére
"Esetleg ha átírnám a függvényt amit küldtél arra, hogy a <head> legelejére rakja a css fájlt akkor jobb lenne?"
Jaja, de akkor már document.write-tal kéne kiíratni a <link> taget (nem a fv.-nyel), ha nagyon muszáj, de még mindig nem indokolt, hogy kiszedd a webkites meg többi előtagot, ugye vágod, hogy a böngésző egyszer betölti a CSS-fájlt cache-be, és aztán onnan szedi, magyarul tök mindegy, hogy akár párszáz kilobájttal több a fájl...?!
Egyébként akkor már jobb lenne - ha már ennyire muszáj - szerveroldalon detektálni a böngészőt, és úgy hozzácsapni még egy "firefox" class-t a body-hoz, vagy hasonló, és a stílusfájlba úgy berakni a meghatározásokat, hogy .firefox #mydiv { ... }, de mondom, ez mindenképp gány megoldás így...Most nem nagyon néztem meg, az általad linkelt SEO-s kiegészítés pontosan hogyan működik úgy, hogy nem kell módosítanod az oldalad kódját, de én nem is komoly keresőoptimalizálásra gondoltam, hanem legalább valami alapvetőre...
Pl. ha megnyitom az oldalakat új lapon, akkor működjön már úgy is... úgy értem, rendesen, ne csak azt az oldaltöredéket kapjam meg, amit az AJAX-kommunikáció során igényelsz. Nem egy nagy valami arra külön módszert kreálni, pl. akkor nem a galeria.php-ra küldesz kérést AJAX-szal, hanem az ajax/galeria.php címre, most csak mondtam valami hasraütésszerűt. Vagy szerveroldalra beteszel AJAX-detektálást (pl. PHP-vel így néz ki). Gondolj bele, a Google robotja is azt a töredék tartalmat kapja csak meg, amikor bejárja az oldaladat. Plusz nem ártana, ha az egyes aloldalak könyvjelzőzhetők, elküldhetők lennének. De ez még alapvető igényesség körébe tartozik sztem, nem a megrendelő által extrán megfizetendőbe.
No mindegy, nem az én dolgom, ezek csak tanácsok.
"Pont ilyet kerestem Köszönöm!"
Szívesen! Ja, annak idején, amikor szarakodtam Chrome-extension fejlesztésével, akkor én is ilyet kerestem, aztán meglett a megoldás.De mivel belinkelték ezt a kiegészítést, ezért a franc sem akart szenvedni vele, hogy feltaláljam a spanyolviaszt, és én is megírjam a saját változatomat.
Ez működik, teszi a dolgát, ahogy kő'.
-
Sk8erPeter
nagyúr
válasz
trisztan94 #2234 üzenetére
Na és azóta sikerült a módosított fv.-nyel?
"Meg ha már külön css-t töltök be firefoxra akkor a gradienteket is átírom abban a stylesheet-ben csak -moz*-ra, ne lassítsa feleslegesen a böngészőt a többi. Ugyanez a -webkit*-es stílusnál, onnan meg a -moz* dolgokat szedtem ki.."
Mi? Nem értem. Most olyan CSS3-as dolgokra gondolsz, amik nem működnek jól -moz, ill. -webkit-előtagok nélkül? Melyek ezek?
Az meg nem érv, hogy "ne lassítsa a böngészőt", nem pont a stylesheet fog lassítani... rengeteg stíluselemet tölt be egy CMS is, aztán mégsem lassul be a böngésző tőle.
Eleve ott kezdődik, hogy miért böngészőspecifikusan adod meg a stílusokat?NAGYON kerülendő, de ha így is van, akkor úgy szokás, hogy egymás alá írod a fallback-eket, hogy minden böngészőnél jól jelenjen meg.
Sokszor érdemes ezekre valami generátort használni, hogy ne neked kelljen baszkodni ezek megírásával. Csak egy példa a számtalanból:
http://www.css3maker.com/css3-transition.html
Csak bekattintod a megfelelő opciót, aztán odarakja neked a mindenféle potenciálisan szükséges előtagot. MINDET másold be a stílusfájlodba, és ne korlátozd webkites vagy más motorra. Működjön lehetőleg a legtöbb böngésző alatt. Attól még, hogy az IE-t kevésbé támogatod, nem jó hozzáállás egyre jobban szűkíteni a támogatott böngészők körét.
Szóval ne csinálj külön FF-stílusfájlt, meg külön Webkiteset, semmi értelme, az ilyen előtagos dolgok is legyenek egy helyen, így egyből látszik a cross-browser kompatibilitás is, meg könnyű módosítani."Mondtam is a megrendelőnek, hogy js-heavy oldalt csinálok, így aki nem használ js-t az vessen magára"
Azért ez nem ilyen egyszerű.
Sokszor érzem azt, hogy manapság az emberek átesnek a ló túlsó oldalára, túlzottan elkényelmesednek. Nem értek egyet azzal a hozzáállással, hogy elég a csak JS-alapú felület. Például a SEO-val mi lesz? Nagyon nem mindegy, a Google keresőrobotja mit lát.
Chrome-hoz itt van egy nagyon jó extension a JS ki-bekapcsolgatására oldalspecifikusan (nem globálisan!):
https://github.com/maximelebreton/quick-javascript-switcher
De a lényegre visszatérve az teljesen degenerált dolog, hogy komplett stílusfájlokat JS-sel töltesz be.
Eleve a CSS-fájloknak a headben elöl kell lenniük, mindenféle script előtt (az sztem kábé tök mindegy a renderelés szempontjából, hogy meta-tagek előtt vagy után van).IE-tesztelős móka:
http://my-debugbar.com/wiki/IETester/HomePage"IE alatt csak, nem?"
NEM, Chrome: http://i.imgur.com/oMh3ZM9.png. Ja de most jövök rá, hogy nem is elcsúszva van, hanem az a baj, hogy egy miniatűr pici fos csík.Gondolom emiatt a méretmegadás (em) miatt:
#kapcsolatokTerk {
width: 100%;
height: 11em;
}"Szerintem inkább a console.log-ot kiveszem, így nincs para vele, amúgy is csak debug szerepe volt."
Persze, ezt mindenképp érdemes, csak ha neadjisten IE8 alatt kell tesztelni, akkor rohadt idegesítő, hogy ott pattog a console hiánya miatt, ezért jó ez a workaround. De ez tényleg a legkevésbé fontos.
Inkább a fentieket oldd meg. -
spammer
veterán
válasz
trisztan94 #2231 üzenetére
Melyik Sublime Text színsémát használod? Ez a Monokai?
-
Sk8erPeter
nagyúr
válasz
trisztan94 #2231 üzenetére
De bakker, miért csodálkozol ha nem működik az a függvény, amit küldtem neked, ha nem változtattad meg az eredeti koncepciódat, ahogy mondtam?
1. nem szedted ki az .each()-et, pedig felesleges
2. az én módosított loadURL függvényem csak egy STRINGET vár paraméterként, NEM pedig egy jQuery-objektumot, ahogy a tiéd! Ahogy írtam korábban, ott is tök felesleges jQuery-objektumot átadni, mivel csak egy URL az érdekes abban a függvényben, tehát ne egy this-t adj át, hanem CSAK a href-attribútumot.Egy függvény csinálja mindig pontosan azt, ami a dolga, ne többet, ne kevesebbet!
Miért töltöd be JS-sel a CSS-fájlt? Korábban azt hittem, csak apróbb módosítás kell valamiért, de a teljes layoutot JS-sel betölteni?
Kipróbáldtad már, hogy néz ki az oldalad JS nélkül?
A videódon kapásból feltűnt az a ronda villódzás, ami pont amiatt van, hogy később töltöd be a stylesheetet. Ez ugyanígy jelentkezne, ha a <link> taggel az oldal forráskódjának legvégére pakolnád be a stylesheetet. Ezt mindenképp oldd meg, mert ez szerintem nem csak nálam b@ssza ki a biztosítékot.De azért az gáz, hogy a stylesheeted IE8 alatt még csak be sem töltődik, akármennyire is nem tartjuk azt normális böngészőnek. FOGJÁK IE8 alól böngészni az oldaladat, számíts arra. Még rosszabb, ha a megrendelőd látja meg IE8 alól.
Ja, és a console.log()-os hibát én annak idején így oldottam meg, hogy olyan böngészőben se "szálljon el" a console.log-olás, ahol nem működőképes ez a függvény:
var alertFallback = false;
if (typeof console === "undefined" || typeof console.log === "undefined") {
var console = {};
if (alertFallback) {
console.log = function (msg) {
alert(msg);
};
console.error = console.trace = console.log;
} else {
console.log = function () {};
console.error = console.trace = console.log;
}
}Az alertFallback változóval azt tudod beállítani, hogy ha nem működik a console.log(), akkor helyettesítődjön alert()-re - ezt defaultból false-ra raktam, nekem ne dobáljon alert()-ablakokat.
Nem tűnt fel még amúgy az a PHP-s hiba, ami a galéria betöltésekor jól látszik a videódon is?
Előbb talán azt kéne megoldani.
Amúgy a térképed erősen el van csúszva.
-
Sk8erPeter
nagyúr
válasz
trisztan94 #2228 üzenetére
"Azért elég gáz lenne, ha benne hagyták volna"
Miért, Te még ott tartasz, hogy nem tudsz elképzelni mindenféle rosszat az IE fejlesztőitől?"nekem elszáll tőle az ajax"
Mi az, hogy "elszáll" az AJAX?Az milyen? Mindenesetre nem derült ki túl sok abból, hogy mi az oka, meg debuggoltál-e, meg létrehoztad-e a var $goldStuff változót (elég gyökér név lett, de nem tudom, mi nálad az a .gold
), és így tovább. Amúgy most jövök rá, nem igazán értem, az index.html"-nél minek kell neked a plusz selector, de gondolom ha működik más böngészőben, akkor működik, azt jóvan.
Ja, és elb@szarintottam, most látom, a szolgaltatasok.html-ben benne maradt a load()! Azt szedd ki onnan a francba, az biztos, hogy hiba. Hát igen, éjfélkor ilyenek már nem nagyon tűntek fel."Igazából még nem sikerült rájönnöm, hogy hogy tudnám előre betölteni ezeket egy még jelen esetben nem létező div-re"
Nem arról beszéltem, hogy töltsd be a térképet és a többit is előre egy divbe, aztán rejtsd el, hanem arról, hogy a szükséges fájlokat csak EGYSZER töltsd be. A FÁJLOKAT. A google.load() elvileg lazy loadra való, tehát aszinkron betölti a fájlokat, de ezt csak egyszer kéne betöltenie. Erre mondtam, hogy lehet, hogy beépítették a google.load()-ba az ellenőrzést, hogy ne töltődjön be többször, nem néztem utána.SZERK.:
na, most utánanéztem:
https://developers.google.com/loader/"Subsequent calls to load the Maps API will immediately execute the provided callback, so you don't have to worry about loading the same API more than once"
Szóval nem para!
Egyből a callback fog meghívódni a következő google.load()-nál, tehát ha valaki még egyszer rákattint arra a menüpontra. -
Sk8erPeter
nagyúr
válasz
trisztan94 #2224 üzenetére
Várj, és a debugger konzol minden esetben meg volt nyitva? Mert az IE8 pl. azt írja, hogy "'console' is undefined", amennyiben nem nyomtam F12-t az oldal betöltése előtt. (Ha nyomtam, akkor okés.) De lehet, hogy rohadtul nincs semmi összefüggés, de próbáld már ki, mi van, ha azt kikommentezed. Bár feltételezem, IE9-nél ezt már megoldották.
Csak hogy megmutassam, mire gondolok:
A többit most látni kéne, mert így nem vágom.Nesze, megfelelő regexppel plusz némi manuális buzerálással úgy 30 másodperc volt átírni
amúgy konkrétan úgy, h Notepad++-ban regexp: \} else if \(url == (\".+\")\) \{
csere erre: case \1:
aztán breaket kimásoltam, majd a megfelelő sorokba bedobáltam Ctrl+V-vel, aztán jsFiddle-lel formáztam.
A loadot meg felesleges mindegyik esetben ismételgetni, így egyszerűbb sztem (kiszedtem a hrefes szarságot, meg az eachet):function loadURL(url) {
var $goldStuff = $('.gold');
if (window.console) {
console.log("Ajax kérés:" + url);
}
if (url === "index.html") {
url += " #content";
}
$('#content').load(url, function () {
switch (url) {
case "index.html":
$goldStuff.css('left', '1.5em');
break;
case "szolgaltatasok.html":
$('#content').load(url, function () {
$goldStuff.css('left', '18.5em');
});
break;
case "galeria.php":
$goldStuff.css('left', '35.5em');
// ha a galeria.php-ra többször is kattintasz, mindig betöltődik, vagy van erre megoldás a pluginben?
Galleria.loadTheme('galleria/themes/classic/galleria.classic.min.js');
Galleria.run('#galeria');
break;
case "kapcsolat.html":
$goldStuff.css('left', '50.5em');
// ez itt minden ráklattyolás esetén betöltődik, jó az??!
google.load("maps", "3", {
other_params: 'sensor=false',
callback: function () {
var mapOptions = {
center: new google.maps.LatLng(47.501272, 19.064841),
zoom: 16,
mapTypeId: google.maps.MapTypeId.ROADMAP
};
var map = new google.maps.Map(document.getElementById("kapcsolatokTerk"),
mapOptions);
}
});
break;
case "gyik.html":
$goldStuff.css('left', '65em');
break;
}
});
}beleraktam egy if(window.console)-t, hogy ellenőrizve legyen, van-e egyáltalán olyan
(pl. IE8-ban b@szik működni a kódod, ha ez bent marad)
Belekommenteltem a kódba, hogy biztos jó az, hogy minden alkalommal, amikor a kapcsolat.html-re kattintanak, akkor a google.load()-dal betöltődik a fájl? Vagy a google.load() tartalmaz ellenőrzést, hogy be vannak-e töltve már a megfelelő dolgok? Ezt nem vágom.
Aztán ott a Galleria.loadTheme - ezt megoldották, hogy ez ne töltődjön be többször?
Amúgy konkrrétan melyik menüpontokra kattintva fordul elő a para? -
Sk8erPeter
nagyúr
válasz
trisztan94 #2222 üzenetére
Szívesen!
Ezt most nem értem, miért kell ide az .each()? Szerintem itt tök felesleges, szedd ki.
Másik, hogy itt a loadURL()-en belül neked egyedül az URL-re van szükséged, amit a href-attribútumból szedsz - akkor miért nem csak azt passzolod át a függvénynek?
Harmadik, hogy a sok-sok okádék if-else helyett cseréld le switch-case-ekre az eseteket, máris átláthatóbb lesz a kód.
Most hirtelen nem látom a parát, IE9-em sincs (direkt meghagytam a fostos szar IE8-at tesztelés céljára, úgyse használom soha, ha nem kell tesztelni), de egész pontosan mi történik? Nem jelez hibát, de nem történik semmi? Ha debuggolás céljára a callback-ekbe beleraksz valami kiíratást, akkor mi történik? Próbáltad már a sima $.get() vagy $.ajax() fv.-ekre lecserélni próba erejéig? -
Sk8erPeter
nagyúr
válasz
trisztan94 #2220 üzenetére
Még régebben létrehoztam 3 függvényt ilyesmire, most előkotortam:
/**
* Inject a stylesheet
*/
function injectCssFile( css_filename ){
var
headID = document.getElementsByTagName("head")[0],
cssNode = document.createElement('link');
cssNode.type = 'text/css';
cssNode.rel = 'stylesheet';
cssNode.href = css_filename;
cssNode.media = 'screen';
headID.appendChild(cssNode);
}
/**
* Load external CSS file with jQuery
*/
function loadCssFile ( css_url ){
$('head').append( $('<link rel="stylesheet" type="text/css" />').attr('href', css_url) );
}
/**
* Inject some inline CSS
*/
function injectInlineCss( inlineCssContent ){
var head = document.getElementsByTagName('head')[0],
style = document.createElement('style'),
rules = document.createTextNode( inlineCssContent );
style.type = 'text/css';
if(style.styleSheet){
style.styleSheet.cssText = rules.nodeValue;
}
else {
style.appendChild(rules);
}
head.appendChild(style);
}A második nem emlékszem, működőképes-e, a többi viszont úgy rémlik, jól működött.
Az injectCssFile() és a loadCssFile() tehát bepakol egy új CSS-fájlt, az injectInlineCss() pedig egy <style>-tagen belülre bepakol egyéb stílusokat, amiket átadsz neki (sringként kell átadni, <style> tag nélkül).
.appendChild()-ot használok, tehát a <head> legvégére rakja, így garantált, hogy utolsó csomópontként fog szerepelni, amíg hozzá nem adsz újat.Az AJAX-os problémához látni kéne a kódot.
-
Sk8erPeter
nagyúr
válasz
trisztan94 #2183 üzenetére
Most volt egy kis időm, megnéztem jobban, szerintem pont nem szar a dokumentációja. Legalábbis ahogy elnéztem, pont leírja, mi mire való, és példát is mutat rá. Demóoldal is van külön.
$.address.change(function(event) {
// do something depending on the event.value property, e.g.
// $('#content').load(event.value + '.xml');
});
$('a').click(function() {
$.address.value($(this).attr('href'));
});======
(#2198) martonx : hát azt tudom.
Amúgy teljesen jogos is, én meg tudod, hogy egyetértek.
Ha tehetném. a neten lévő összes oldalra kiraknék IE9 alatti böngésző detektálására scriptet és szerveroldali kódot is, és egyik oldalon sem biztosítanék outputot annak, aki ilyen retket használ.(Csak olyat, amiben egy-két kedves szóval illetem a böngészőjét.) Hadd legyenek ösztönözve egy kicsit a felhasználók és a fejlesztők egyaránt...
-
Sk8erPeter
nagyúr
válasz
trisztan94 #2196 üzenetére
ha a "az urlt rendesen irja ki" azt jelenti, hogy hash nélkül, akkor jogos, vhogy úgy emlékeztem, hogy ennél a modern böngészőkben ahhoz hasonlóan változtatja az URL-t, ahogy Te elvárnád, viszont van fallback hash fragment segítségével...
Akkor bocsánat, tévedtem, rosszul emlékeztem...Viszont most néztem meg IE8-ban, és az általad preferált Address plugin pont úgy működik, ahogy fentebb vakerásztam a másik pluginről, de ezek szerint pedig akkor az általam ajánlott ezt mégsem tudja, mert ott mindenképp hash fragmentekkel dolgozik.
My bad, akkor visszavonom.
Szóval használd ezt, ja.
Tehát pl. ez a cím jelenik meg Chrome-ban oldal-újratöltés nélkül, ahogy kell, ráklattyintáskor:
http://www.asual.com/jquery/address/samples/express/about
de ez IE8-ban:
http://www.asual.com/jquery/address/samples/express/#/aboutMost jó sokat dumáltam úgy, hogy végül kiderült, hogy nincs is igazam.
Hát érted, néha ilyennek is kell történnie.
-
Sk8erPeter
nagyúr
válasz
trisztan94 #2192 üzenetére
Ja, sehol nem írták, hogy jobb lenne...SŐT, pont az általad harmadikként linkelt topicban írták buzinagy betűkkel, hogy "THIS PLUGIN IS NO LONGER MAINTAINED! (2012-02-25) Please use other plugins like jQuery hashchange. – Xitcod13 Aug 13 '12 at 22:20"
Ja, meg az sem mindegy, hogy majd' egy évvel korábban született az a hsz., amiben azt ajánlják.
"Ja, meg itt is a harmadik helyen van"
Most ez komoly?És akkor mi van?
(#2193) martonx :
az azért nagyon nem mindegy, hogy van-e fallback, már ha jól értem, amit mondasz, hogy a szutykos IE-kben is működjön. -
martonx
veterán
válasz
trisztan94 #2192 üzenetére
Én valamelyik jquery history plugint használom, de annyira nem vagyok elégedett vele. Ráadásul manapság semmibe nem kerül megírni azt az 1-2 sornyi js-t, ami ugyanezt csinálja.
-
Sk8erPeter
nagyúr
válasz
trisztan94 #2185 üzenetére
Na, linkeld már be plíz, ahol írják stackoverflow-n, hogy ez jobb, kíváncsi vagyok az indokokra. Kösz!
(#2186) Muton :
a .live() deprecated. .on()-t érdemes helyette használni.
Amúgy a callback-be tett sima return false; is megoldja:
http://prohardver.hu/tema/jquery_kerdesek/hsz_2110-2110.html -
Muton
addikt
válasz
trisztan94 #2187 üzenetére
thx! közben sikerült megoldani, méghozzá úgy, hogy a belső.click-be tettem egy event.stopPropagationt, úgyhogy nem hívja meg a külső.clicket
-
Sk8erPeter
nagyúr
válasz
trisztan94 #2183 üzenetére
Tulajdonképpen egész konkrétan mit szeretnél megvalósítani?
Hasonló itt van:
http://benalman.com/code/projects/jquery-bbq/examples/fragment-basic/
http://benalman.com/code/projects/jquery-bbq/examples/fragment-advanced/
http://benalman.com/code/projects/jquery-bbq/examples/fragment-jquery-ui-tabs/
http://benalman.com/code/projects/jquery-bbq/examples/deparam/Ben Alman elég igényes cuccokat szokott írni, pl. a fenti plugin bekerült a Drupal 7 core-ba is az overlay-ek kezelésére, azért az már jelent valamit.
-
szmegma
aktív tag
válasz
trisztan94 #2109 üzenetére
Ertem, koszi szepen a leirast.
Az egybe pakolasnak majd neki latok a heten. -
Sk8erPeter
nagyúr
válasz
trisztan94 #2109 üzenetére
Itt volt erről szó, ott linkeltem egy témában releváns topicot:
http://prohardver.hu/tema/javascript_topic/hsz_3365-3369.htmlNémi pontosítás az általad írtakhoz:
"A return false annyit csinál, hogy az alapértelmezett eseményt nem engedi lefutni."
Pontosítva: jQuery-ben az eseménykezelőkbe tett return false; ekvivalens az event.preventDefault() ÉS event.stopPropagation() hívásokkal. Tehát a böngésző alapértelmezett műveletének végrehajtását akadályozzuk meg ezzel, ÉS megakadályozzuk az esemény buborékként való felúszását a DOM-fában, megakadályozva egyúttal azt, hogy a szülők eseménykezelői értesítve legyenek az eseményről.
Stimmel, amit írtál, csak ezzel a kiegészítéssel lesz teljesen igaz."Ha ki van töltve minden akkor return true (bár mondjuk ez az alapértelmezett, de én szeretem kiírni)"
Ez mondjuk így ebben a formában nem teljesen helytálló, mert nincs "alapértelmezett return true", hanem mivel nem tértünk vissza false-szal az eseménykezelőből (vagy hívtunk event.preventDefault()-ot és event.stopPropagation()-t), ezért engedjük, hogy a böngésző alapértelmezett művelete lefusson (ami - ebben már teljesen igazad volt - a form elküldése).Alapvetően jókat írtál, csak pici korrekcióra szorult, hogy teljes legyen a kép, hátha hasznos valakinek.
-
Jim-Y
veterán
válasz
trisztan94 #2053 üzenetére
Az egész zavaros, szerintem egyszerűbb lenne, ha leírná, hogy alapból mit szeretne, és akkor arra adnának az okosok választ, példakódot, etc...
-
Peter Kiss
őstag
válasz
trisztan94 #2050 üzenetére
$_POST[action] => $_POST['action'] !!! E_NOTICE különben
Ha egy string értéke egy meghívható függvényé, már működik (simán: $action()). Ha mondjuk visszamegy kettő, akkor pl. meg lehet oldani egy statikus metódushívást is, de akár elő lehet szedni egy megfelelő objektumot is, majd instance szintű metódust lehet hívni (call_user_func vagy call_user_func_array), gyakorlatilag így tud működni pl. egy MVC keretrendszer routing-ja is, egyszerű konvención alapszik.
Igen, ASP.NET-ben is így van, de konvenció szerint az action az egy (MVC-ben ActionResult-ot visszaadó) metódus neve.
-
Jim-Y
veterán
válasz
trisztan94 #2048 üzenetére
Én nem így gondoltam.. csak rosszul írtam le, kicsit érthetetlenül :/
Szóval én úgy csinálnám, hogy a az ajax, data mezőjében egy action-t küldenék csak, ugye az php oldalon, ha jól emlékszem a $_POST[action]-be kerül, majd php oldalon ezen $_POST[action] függvényében hívnám meg a szükséges függvényt, ami csak azt adná vissza, amire szükség van, ergo nem mindent küldenék vissza, csak azt a darab kódrészletet amire szükség van.. -
szmegma
aktív tag
válasz
trisztan94 #2045 üzenetére
Azt hogyan lehet?
$.ajax({
type:"POST",
url:"pages/sablons.php",
dataType:"html",
data:"pg="+output,success:function(returned_data){
}
}Ez a resz, az egesz sablon.php tartalmat elkuldi. Hogyan lehet szabalyozni, hogy CSAK a <div id="sablon-tartalom"></div> tartalmat kuldje el es ami visszater, azt a <div id="sablon-tartalom"></div> objektumba toltse bele?
-
martonx
veterán
válasz
trisztan94 #2028 üzenetére
Ehhez minek jquery? Sima CSS csinál neked olyan tooltipet, hogy öröm nézni.
-
Sk8erPeter
nagyúr
válasz
trisztan94 #2033 üzenetére
"TypeError: $(...).tooltip is not a function"
Magyarul nem a sima jQuery-kódnál vérzett el, hanem amikor a Tooltipet akartad használni, nyilván akörül kellene keresgélni a problémát... -
Jim-Y
veterán
válasz
trisztan94 #2033 üzenetére
nem tudsz egy hosszabb kódrészletet megosztani? Esetleg JSfiddle?
-
Jim-Y
veterán
válasz
trisztan94 #2028 üzenetére
Pedig amit írtál az működik, tehát elképzelhető, hogy mégiscsak a JQuery linkelésével lesz gond...
-
Sk8erPeter
nagyúr
válasz
trisztan94 #2028 üzenetére
Ennyiből nehéz mit mondani. $(document).ready() eseményre kötötted?
-
cucka
addikt
válasz
trisztan94 #2029 üzenetére
A javascript kódot a kliens böngészője futtatja.
Tehát akárhogy csűröd-csavarod, mindenképp el kell jusson a kód a kliens böngészőjébe, ha pedig ez megtörtént, akkor már szabad préda.Firebugot nem lehet blokkolni. Ugyanaz a történet, mint az előbb: amit egy weboldalon a júzer lát, azt onnan látja, hogy a szervered elküldte a böngészőnek. A firebug csak egy eszköz arra, hogy könnyebben tudd kezelni azt a csomó mindent, amit a szerver elküldött.
Inkább valamilyen videós megoldásban tudnék gondolkozni, esetleg animált gif
. Mondjuk az jó kérdés, hogyan lehetne ezek elkészítését automatizálni.
-
martonx
veterán
válasz
trisztan94 #2010 üzenetére
Próbáltad már itt PH-n belül a C#-os topik-ot? Kérdezz bátran, szerintem semmi baj nincs az ASP.NET-es közösséggel. Aztán ott van még a Devportal-os szintén MS érintett topik, ott is szoktak segíteni.
Illetve szerintem ami még gond tud lenni, hogy ugyan létezik ez az ASP.NET Web Pages is mint egy választható lehetőség az ASP.NET ökoszisztémán belül, de szvsz az ASP.NET programozók 99% vagy Web Forms-t, vagy MVC-t használ, szóval inkább ez lehet az oka annak, hogy nehezen kapsz választ. -
Sk8erPeter
nagyúr
válasz
trisztan94 #2001 üzenetére
Nem, nem erre gondoltam, és egyáltalán nem felesleges a státuszváltozó. Miért lenne már az? Baj, ha a szervertől visszakapott válaszból értelmes adat is kinyerhető a konkrét állapotról?
Több eset is elképzelhető, amikor szükséged lenne a státuszra vonatkozó változóra. Például ha keletkezik egy exception az adatbázissal való kommunikáció során, akkor ezt le kell kezelni, felhasználóbarát üzenet formájában jelezni, hogy para volt, próbálja később, satöbbi. Ettől még az AJAX-kommunikáció során a success callback-be (!!) kell, hogy lépjen a script, mert attól még a válasz 200 OK HTTP-kóddal, gond nélkül lefutott, az már másik kérdés, hogy nem azt a választ kapta a júzer, amire kíváncsi lett volna. Például ebben az esetben lehet, hogy az a feladatod, hogy ha ilyen jellegű hiba volt, akkor legyen valami ilyesmi kódod:
... function(data){ // success callback...
if(data.status === "error") {
szálljon_el_egy_vörös_sárkány_a_képernyőn();
jelenjen_meg_egy_óriási_hibát_jelző_div_a_felhasználó_arcába_tolva();
szólaljon_meg_egy_drámai_hatást_keltő_zene();
most_kezdjünk_valamit_a_hibakóddal(data.code);
return;
}
// egyébként meg fusson le a sikert jelző kód
// ...
}...Remélem nagyjából érthető, hogy mi a lényege az egésznek... (az olvashatóság érdekében nem camelCase-zel írtam
)
Igenis szükség van a státuszt jelző változóra, szükség lehet konkrét hibakódra is, mint a pszeudokódban is látszik, és ha már elkezdesz ezzel foglalkozni, akkor kezdd el igényesen, később is felhasználható módon.A PHP-t ne sírd vissza sztem, ha ASP.NET-ezel, mert akkor valahol az igénytelenséget sírod vissza.
-
martonx
veterán
válasz
trisztan94 #2002 üzenetére
Akkor már inkább $("#valami").html("script....") és kész is, és pont ott van ahol kell.
-
martonx
veterán
válasz
trisztan94 #2001 üzenetére
A C# tömbök faék egyszerűségűek, és kizárólag számmal indexelődnek. Ez már csak a nyelv tipikussága miatt is így van. Ellenben ha te string-gel akarsz indexelni, akkor arra meg ott van a Dictionary típus, és van még pár egyéb kollekció típus.
PHP-ben meg van egy szál tömb, amit úgy gyurmázol ahogy akarsz. Ez nagyon nagy előnye a nem típusos PHP-nek, egyben talán a létező legnagyobb hátránya. De nem szeretnék itt offolni, meg hitvitákat kirobbantani.Viszont javaslom, hogy lépj tovább Web Pages-ről, MVC-re.
-
Sk8erPeter
nagyúr
válasz
trisztan94 #1972 üzenetére
"Mi az a Dictionary, class, stb dolog?"
Hát a class-t (osztály) gondolom csak nem kell már magyaráznom...Erre már azóta példát is adott martonx. Na, például itt lehetne egy status változód is, aminek az értékét a query lefutásának sikerességétől teszed függővé.
Ez az egész lesz aztán JSON-né konvertálva, ezt pedig kényelmesen feldolgozod jQuery-vel a válaszban.A korábbi asszociatív tömbös megoldást azért említettem, mert először abból indultam ki, hogy PHP-vel dolgozol. Egyébként alapvetően ez PHP-ben is szebb egy ilyen célra szánt osztállyal megvalósítva.
Olyasmiről beszéltem előtte, amit Jim-Y mutatott, de az helytelen szerintem, hogy result.0.name, mivel ez eleve nem is kifejező, meg nem túl szépen olvasható, akkor ebben az esetben inkább így a jó: result[0].name - így egyből látszik a tömbös megközelítés is.A Dictionary-ről:
http://msdn.microsoft.com/en-us/library/xfhwa508.aspx
De egyébként ezt csak lehetséges példaként említettem. -
martonx
veterán
válasz
trisztan94 #1976 üzenetére
C# - ha nem tévedek - csak számokkal enged tömböt indexelni.
C#-ban mint a klasszikus objektum orientált nyelvekben, a JSON-hoz (is) osztályokat érdemes használni.Egy C# példa :
public class Pelda
{
string name { get; set; }
string value { get; set; }
string description { get; set; }
}
//Aztán értéket adsz az osztályodnak
Pelda product = new Pelda();
product.name = "Apple";
product.value = 1;
product.description = "teszt szöveg";
string json = JsonConvert.SerializeObject(product);Természetesen a Pelda osztályodból csinálhatsz tömböt, List-et, akármit, és a végén meg azt szerializálod.
-
Jim-Y
veterán
válasz
trisztan94 #1976 üzenetére
Sajnos nem ismerem a C#-ot
-
Jim-Y
veterán
válasz
trisztan94 #1974 üzenetére
Annyi a lényeg, hogy name.value szintaktikával eléred javascripttel a json objektum tulajdonságait.
Maga a JSON szintaktika végtelenül egyszerű, referenciát 2 perc alatt el lehet olvasni http://www.json.org/
JS-ben pedig így tudod használni: http://www.json.org/js.html
-
Jim-Y
veterán
válasz
trisztan94 #1972 üzenetére
PHP-ben írsz például egy ilyet:
<?php
$response = array();
for($i = 0; $i < 10; ++$i){
$response[$i]['name'] = "name number ".$i;
$response[$i]['another_field'] = "field number ".$i;
}
$response['status'] = "siker";
$result = json_encode($response);
echo $result;
?>Itt a $result egy json objektum lesz, amit visszaküldesz az ajax hívásnak, majd a JS oldal ezt látja belőle:
{
"0": {
"name": "name number 0",
"another_field": "field number 0"
},
"1": {
"name": "name number 1",
"another_field": "field number 1"
},
"2": {
"name": "name number 2",
"another_field": "field number 2"
},
"3": {
"name": "name number 3",
"another_field": "field number 3"
},
"4": {
"name": "name number 4",
"another_field": "field number 4"
},
"5": {
"name": "name number 5",
"another_field": "field number 5"
},
"6": {
"name": "name number 6",
"another_field": "field number 6"
},
"7": {
"name": "name number 7",
"another_field": "field number 7"
},
"8": {
"name": "name number 8",
"another_field": "field number 8"
},
"9": {
"name": "name number 9",
"another_field": "field number 9"
},
"status": "siker"
}ajaxon belül:
success: function(result){
if(result.status === "siker"){
// TODO
}
result.0.name //name number 0
}Látszik, hogy a json azért jó, mert a javascriptes objekt notációval tudod elérni a json fieldjeit. A példában result.0.name
-
Sk8erPeter
nagyúr
válasz
trisztan94 #1964 üzenetére
Javaslom, hogy teszteld: alakítsd át szerveroldalon JSON-né a választ (tömb, Dictionary, class, stb.), majd kliensoldalon, a megfelelő $.ajax() függvény success callback-jében egyszerűen egy console.log(data) segítségével írasd ki a callback function argumentumát, és meglátod, milyen egyszerű lesz kezelni.
Pl. tudod vizsgálni, hogy
if(data.status === "success"){
// ....
}
ha korábban, szerveroldalon beállítottad a status property-t is. Tényleg egyszerű kezelni, próbáld ki. -
martonx
veterán
válasz
trisztan94 #1964 üzenetére
az a JSONP, amire te gondolsz, és a cross-domain hívások.
ASP.NET-nél Json.Net-et használva bármilyen objektumot lazán serializálsz.
-
Sk8erPeter
nagyúr
válasz
trisztan94 #1962 üzenetére
Ja értem. Szerintem amúgy jobban jársz, ha a töltődést jelző kép egy background-image, és van egy ehhez tartozó div, amire csak ráraksz egy loading class-t, aminek megvannak a maga tulajdonságai CSS-ben (szélesség, magasság, maga a töltődést jelző háttérkép). Így csak megjeleníteni és eltüntetni kell ezt a bizonyos divet (elég a <div class="loading"></div>). De végül is nem ez a lényeg.
Tehát betöltéskor (vázlatszerűen)
1.) megjeleníted a töltődést jelző képet
2.) elküldöd szerveroldalra AJAX-szal, hogy milyen tartalmat szeretnél megjeleníteni, esetleg azt is, hogy annak hányadik oldalát
3.) lekéred a tartalmat, a következőket berakod egy asszociatív tömbbe (most feltételeztem, hogy PHP-vel dolgozol, de végül is mindegy), amit majd átalakítasz JSON-formátumra (pl. PHP-ben json_encode()-dal, mert azt kliensoldalon nagyon könnyű kezelni jQuery-vel!):
- hány oldalas a tartalom
- épp hányadik oldalt fogod abból megjeleníteni
- magát a tartalmat
- esetleg egyebet, ami neked kell (pl. a cikk címét is itt érdemes beállítani
- legyen státuszjelző, sikeres volt-e a lekérés, esetleges hibaüzenet, stb.
4.) kliensoldalon az előző lekérésnek a callback-jében (!!) vizsgálod, sikeres volt-e a lekérés, ha nem, megjelenítesz valami felhasználóbarát üzenetet (érdemes ezt is egyébként szerveroldalon beállítani, ne a kliensoldalra bízd! - de természetesen azt is kell kezelned kliensoldalon, ha már eleve a szervertől nem kaptál vissza adatot, de ez egy error callback-ben történik, nem pedig a success callback-ben), eltünteted a töltődést jelző divet, animálgatsz, amit akarsz, és betöltöd a megfelelő divbe a tartalmat, valamint az oldalszámokat (aktuális/összes), beállítod az új oldalcímet, mindezt a JSON-adatból kinyerve.
A lényeg, hogy a JSON-adatból mindenféle fontos információ kinyerhető legyen, tehát ezeket már eleve szerveroldalon állítsd be, hogy kliensoldalon aztán tök egyszerű legyen vele dolgozni. -
Sk8erPeter
nagyúr
válasz
trisztan94 #1960 üzenetére
Egész konkrétan amúgy hogy szeretnéd az egészet megvalósítani, hogy nézzen ki? Nem néztem végig a kódodat, csak ez egyből feltűnt.
-
Sk8erPeter
nagyúr
válasz
trisztan94 #1958 üzenetére
Ja. De csak egy lehetséges megvalósítás a sok közül. De az eredeti koncepció rossz.
-
Sk8erPeter
nagyúr
válasz
trisztan94 #1956 üzenetére
kódodból:
$('.TutorialsSlideDown').slideDown(400, function () {
$('.TutorialsPagination').bind('click', function () {
//ajax kérés a lapoztatásra
$.post("Action/TutorialsPagination.cshtml",
{
page: 2
},
function (data) {
$('.TutorialsSlideDown').html(data);
alert(data);
});
//ajax kérés vége
});
});eleve rossz a koncepció. A slideDown callback-jében írod meg, hogy a .TutorialsPagination class-szal ellátott elem event handlere a click eseményre ezt meg azt csinálja... nem jó. Minden lapozáskor ezt megcsinálod. Szedd külön, az event handler a click-re eleve az elején legyen már rákötve, és valami data-attribútumtól, vagy globális változótól függjön (inkább előbbi!).
A koncepciót alakítsd át. -
martonx
veterán
válasz
trisztan94 #1951 üzenetére
Neked is csak azt tudom mondani, hogy nem szégyen jquery dokumentációt olvasni:
"As of jQuery 1.7, the .on() method is the preferred method for attaching event handlers to a document. For earlier versions, the .bind() method is used for attaching an event handler directly to elements. Handlers are attached to the currently selected elements in the jQuery object, so those elements must exist at the point the call to .bind() occurs. For more flexible event binding, see the discussion of event delegation in .on() or .delegate()." -
Karma
félisten
válasz
trisztan94 #1923 üzenetére
Screenshot téma: ez esetben Javascript oldalról kizárt.
Viszont ha megnézed a Jing oldalát, ott is embeddálnak screencastot előképpel. Az oldal forrását megnézve ezt találtam:
<object type="application/x-shockwave-flash" id="tscplayer" name="tscplayer" align="middle" data="http://www.techsmith.com/includes/tsc_player.swf" width="100%" height="100%">
<param name="quality" value="high">
<param name="bgcolor" value="#000000">
<param name="allowscriptaccess" value="always">
<param name="allowfullscreen" value="true">
<param name="wmode" value="direct">
<param name="allowNetworking" value="all">
<param name="flashvars" value="src=http://assets.techsmith.com/Videos/ua-tutorials-jing/screencast-embed.mp4&debugHotspots=false&poster=http://assets.techsmith.com/Videos/ua-tutorials-jing/screencast-embed.png&authoredLanguage=default&customEventTracking=true&customEventJSCallback=onCustomEvent&altEventCategoryAsFilename=true&altLoadTimeAsSeconds=true&debugUI=false&advancedSeeking=false&enforceLinearAssessments=true&scormComplete=false&hostingPage=http://www.techsmith.com/videoframe.aspx?mp4=http://assets.techsmith.com/Videos/ua-tutorials-jing/screencast-embed.mp4&webm=http://assets.techsmith.com/Videos/ua-tutorials-jing/screencast-embed.webm&xml=&png=http://assets.techsmith.com/Videos/ua-tutorials-jing/screencast-embed.png&autoplay=false&disablefullframe=false&title=screencast-embed.mp4">
</object>Kiemeltem, de külön is: a flashVarsban bead egy olyan paramétert, hogy poster és egy png változó, benne egy URL-lel ami az előnézeti képre mutat.
Bár szerintem ezt magától is ki tudja generálni a program (sose használtam), kézzel is hákolhatod ha gondolod.
-
Sk8erPeter
nagyúr
válasz
trisztan94 #1923 üzenetére
Most nem értem, melyik a kérdés, hogy lehet-e az egészen gyorsítani, vagy hogy ne slideDown-oljon addig, amíg be nem fejeződött a szerveroldallal a kommunikáció?
Nyilván gyorsítani a szerveroldali kommunikáción úgy lehet, hogy megoldod, hogy gyorsabban adjon választ a szervered.
Azt meg, hogy csak az eredmények tényleges megérkezésekor legyen slideDown, úgy tudod megoldani, hogy a callback-be rakod bele a slideDown-t, nem az aszinkron híváson kívülre.
Tehát pl.
...
$.post("Action/LoadTutorials.cshtml", { category: ClickedCategory },
function (data) {
$('.TutorialsSlideDown').html(data);
//DIV megjelenítése
$('.tutorial_listing').slideUp(400);
$('.TutorialsSlideDown').slideDown(400);
});
//ajax kérés vége
... -
Karma
félisten
válasz
trisztan94 #1921 üzenetére
Ez csak akkor lehetséges, ha a Flash fájlt is te írod, és definiálsz hozzá egy külső interfészt. Ezt meghívva a Flash kód legenerálja a screenshotot, majd átadja a JavaScriptnek.
Más megoldás a böngésző alapelvei miatt nem lehetséges.
Ha nem SWF objektumod lenne, hanem egy HTML5 canvasra rajzolnál, na az le tudja generálni az aktuális állapotát képként.
-
Sk8erPeter
nagyúr
válasz
trisztan94 #1896 üzenetére
"Lehet, hogy én értettem félre, nekem abszolút az jött le, hogy a leg- lepkefingnyi kódot is pluginba írjuk, mert az milyen jó."
Erre a válasz megint az "attól függ". Indokolt esetben "lepkefingnyi" kódot is érdemes lehet pluginba rakni, ha adott DOM-elemek manipulálását egyszerűbbé teszi. Erre sincs általános szabály.
Mindenesetre az tény, hogy a jQuery plugin nem egy nagyon misztikus valami, nem is nehéz írni, de hasznos lehet, viszont nem is kell rá úgy tekinteni, mint egy gyógyír az összes problémádra. Egyébként legalább egyszer próbáld ki, hogy írsz egy tök egyszerű jQuery plugint, nagyon jó a dokumentáció a jQuery hivatalos oldalán, meg rengeteg tutorialt lehet találni a témában. Ha legalább egyszer kipróbáltad, milyen az, akkor segít eligazodni, hogy mikor lehet érdemes plugint írni. Akár 20 perc alatt át tudsz futni rajta, hogyan kell, mit kell tudni róla nagyvonalakban, és meg tudod írni a legegyszerűbb pluginedet, szóval érdemes rászánni azt a kevés időt.""Mik azok a "sima hívások"?"
$('#valami').click(function() {
//do stg
});
Ezek helyett a "sima hívások" (van erre valami szakkifejezés? nem jut eszembe )"Uhh, hát itt megint csak valami fogalomzavar van. Ez a "sima hívás" egy eseménykezelő akar lenni... a click eseményre feliratkozol (így szokták mondani) egy eseménykezelővel. Tehát annyi ennek a lényege, hogy amennyiben #valami elemre ráklattyolnak, akkor ez a függvény fog lefutni. Jelen esetben itt egy úgynevezett anonim függvénnyel iratkoztál fel az eseményre. De nem kell, hogy az a függvény anonim legyen, a függvénypointeres szintaktikával is lehet:
function myFunction() {
// do something
// ....
}
$('#valami').click(myFunction);Ugyanaz fog történni. A különbség az, hogy jobban elkülönül a kettő. De itt sem egyértelmű, hogy egyiket vagy másikat "érdemes" használni - ha sokszor használod fel mondjuk az adott függvényt, máshol is van rá szükség, akkor nyilván érdemes így szétválasztani, ha egyetlen helyen lesz felhasználva, akkor nem kell, sőt, adott esetben olvashatóság szempontjából még jó is lehet, hogy "egy helyen van".
"Én próbálok mindig objektum orientált lenni, sokszor kísért meg a "sötét oldal", hogy inkább lesz*rom, gányolok, úgy is működni fog"
Ez ismét képzavar, ha valaki nem objektumorientáltan kódol, az nem azt jelenti, hogy gányol.
Scriptnyelvekben például nem feltétlenül kódolsz objektumorientáltan, aztán mégis lehet úgy is igényes kódot írni."Az append az nem egy szinten van a DOM-ban a <li>-vel?"
Hogy micsoda?"Tehát ha jól értem, akkor nem a <li>-re kéne append-olni, hanem az ő containerjére, nem?"
Nem. A <li>-hoz is lehet appendolni, kódodban hozzáfűzve a Lorem ipsum dumát:Egyébként van .slideToggle() is, ami kicsit egyszerűbb.
-
martonx
veterán
válasz
trisztan94 #1896 üzenetére
Valamit nagyon benézel, mert az append-nek így működnie kellene, ahogy mutatod.
-
fordfairlane
veterán
válasz
trisztan94 #1896 üzenetére
Aha, értem!
Lehet, hogy én értettem félre, nekem abszolút az jött le, hogy a leg- lepkefingnyi kódot is pluginba írjuk, mert az milyen jó. Hát kicsit fogtam a fejem..
A jquery plugin olyan, mint más rendszerekben az újrafelhasználható komponens. A hangsúly azon van, hogy a kész kódot a lehető legkönnyebben lehessen felhasználni különféle oldalakon anélkül, hogy bele kelljen nyúlni a plugin programjába. A plugin olyan szerkezetű, hogy mindent tartalmaz, ami szükséges a használatához, és idegenek, akik semmit nem tudnak a belső felépítésről, azok is egyszerűen tudják felhasználni. Ha arra gondoltál, hogy a plugin olyan, mint egy függvény, vagy egy objektum metódus, akkor tényleg mellélőttél.
-
Sk8erPeter
nagyúr
válasz
trisztan94 #1891 üzenetére
Hát a kettő igazából nem ekvivalens, hogy függvénybe rakok-e valamit, vagy mondjuk jQuery-plugint írok, vagy OO-jelleggel írom meg; feladattól függ. Ha például konkrétan ilyen feladatról van szó, hogy sok DOM-elem átalakításával, felhasználásával kapcsolatos feladat merül fel, akkor érdemes plugint írni rá (lásd például a jQuery UI pluginokat is, mint a datepicker, ott is egy input elem "viselkedését", kinézetét befolyásolod), ha csak valami szimpla feladatról, mint annak eldöntése, hogy egy szám páros vagy páratlan, akkor sima függvényt lehet írni rá (pl. function isOdd() vagy ilyesmi), ha objektumorientált gondolkodást igénylő feladat merül fel, mint hogy mondjuk van egy autó, aminek különböző tulajdonságai vannak, vagy van egy fiú és lány objektumod, szintén tulajdonságokkal felruházva, akkor OO-jellegű kódot érdemes írni rá, de nem indokolt a plugin... szóval a feladat függvényében érdemes dönteni. Általában azért nem nehéz eldönteni.
"Én nem rég tértem át a sima hívásokról a function-ök használtatára, sokkal jobban szeretem."
Mik azok a "sima hívások"?"Nem egyszerűbb egy fájlban tárolni gyorsaság szempontjából?"
A jobb CMS-eknél be lehet kapcsolni, hogy a sok-sok CSS- és JS-fájl helyett ezen fájlok aggregálása legyen aktív, tehát sok-sok különálló fájl helyett egyetlen fájlba bepasszírozott, lehetőleg valamennyire minimalizált változatot include-olnak a fájlba (nyilván külön ömlesztett CSS- és ömlesztett JS-fájl), ez így egyetlen fájllekérést eredményez a szerver felé mondjuk a 20 helyett, és ki vannak szedve a whitespace-ek is, így kevesebb ideig tart rajta a kliensnek végigrohangászni, plusz kevesebb helyet foglal, stb... ez adott esetben sokat számíthat teljesítmény szempontjából. A kliensnek is kevesebb fájlt kell behúznia, cache-elnie, valamint a szervernek is kevesebb fájlt kell kiszolgálnia, mindkét oldal számára jó lehet. Olvashatóság, fejleszthetőség szempontjából persze nem ez a jó, de itt nyilván élesbe helyezett oldalakról van szó, ahol érdemes az aggregálást választani. -
martonx
veterán
válasz
trisztan94 #1891 üzenetére
Ha már most teljesítmény problémáid vannak, akkor vagy valamit elrontottál, vagy mellőzni kellene a Jquery-t.
Tegnap átálltam 1.9-es Jquery-re. Ennyit még az életben soha nem szívtam js-el, mint most. Még a gyári pluginekben is debug-oltam, mire sikerült ismét működőképessé várazsolni mindet. Bár az is igaz, hogy van pár ezer sornyi js-em. Ismét megerősítést kaptam, hogy fejlesztés közben azért a pár percnyi idő előnyért jó eséllyel öngól bármilyen third-party lib-et használni, mert később azt az időt többszörösen elveszted
-
Sk8erPeter
nagyúr
válasz
trisztan94 #1888 üzenetére
"Mi a kulonbseg jelen estben az each es a find kozott? Nem kell megegyszer hivatkozni ra id-vel?"
Félreértettél.Nem az each-csel van a baj, hanem azzal, hogy ugyanazt a selectort félrevezető lehet itt felhasználni, meg felesleges.
Tehát mondjuk $(this)-szel is meg lehetne oldani, tiédet gyorsan átalakítva:
http://jsfiddle.net/aBcnr/1/
Most a szemléltetésért direkt raktam multiple-re, ebben jogos, amit Jim-Y korábban mondott, hogy ennél nem lenne feltétlenül szükséges az each, mivel egyetlen elemről van szó.
Aztán tömbszerűen, erről szintén volt már szó:
http://jsfiddle.net/aBcnr/2/Szerk.: ja, egyébként jsFiddle-nél érdemes használni a TidyUp gombot, szépen formázza a kódot.
-
Jim-Y
veterán
válasz
trisztan94 #1874 üzenetére
Ezt egy kicsit túlmisztifikáltad szerintem, ugyanis ahogy létrehoztad a html-t, úgy nem tudsz többet kijelölni, így a kódban is rosszul kezelted le:
http://jsfiddle.net/Jim_Y/ddSUL/
Multiple selectekre:
-
Sk8erPeter
nagyúr
válasz
trisztan94 #1874 üzenetére
Ugyanúgy jelenik meg jsFiddle-ön is, mint itt.
Inkább a change()-en belül $(this).find("option:selected")...Láttad egyébként, amit neked írtam nemrég válaszul?
-
Sk8erPeter
nagyúr
válasz
trisztan94 #1868 üzenetére
Ajánlom magamat, írtam egy miniplugint erre a célra:
http://stackoverflow.com/questions/5371089/jquery-count-characters-in-textarea/14789531#14789531
-
martonx
veterán
válasz
trisztan94 #1833 üzenetére
Egy próbát megérhet, illetve neki is jól jöhet némi visszajelzés.
Egyébként kellemes meglepetés, hogy egy hozzáértő tanár az oktatód! -
Sk8erPeter
nagyúr
válasz
trisztan94 #1833 üzenetére
Hát én szívesen tesztelném
-
Sk8erPeter
nagyúr
válasz
trisztan94 #1811 üzenetére
"sajnos nem írja sehol sem a firebug, hogy milyen pluginok vannak felrakva"
Hát nyomass a Fájörfoxban egy Ctrl+Shift+A-t, ott tudsz kotorni a felrakott extensionjeid közt. -
martonx
veterán
válasz
trisztan94 #1811 üzenetére
elég ha a firefox pluginjeidet megnézed
engem is érdekelne, egy ilyen js elemző firebug bővítmény. -
Sk8erPeter
nagyúr
válasz
trisztan94 #1809 üzenetére
Ja, hát ha valami plusz kieg., engem érdekelne, melyik az.
Az "unnecessary memory hog" kifejezés azért többre utal, mint a felesleges "overhead", mert az előbbi konkrétan azt jelenti, hogy valahol zabálja a kódod a memóriát, utóbbi meg "csak" azt, hogy a kódod túl sok felesleges lépést tartalmaz, jobban is lehetne spórolni az erőforrásokkal, és azzal, hogy ne legyen össze-vissza ugrálás a kódban; ilyen lehet például számtalan tök felesleges függvényhívás, amikor mondjuk bizonyos visszatérési értékeket el is tárolhatnál egy változóban, és azt használhatnád fel a kódodban máshol is. Ez persze nyilván összefügghet felesleges memóriakajálással is, tehát a két fogalom nem áll távol egymástól, de azért mégis picit mást jelent.
-
Sk8erPeter
nagyúr
válasz
trisztan94 #1807 üzenetére
Szívesen!
"firebug dobálta ki a felesleges overheadeket"
Ezt hogy érted, hogy "dobálta ki" az overheadeket? -
Sk8erPeter
nagyúr
válasz
trisztan94 #1805 üzenetére
if($('#SpecifyCodeSnippetLanguage').css('display', 'none'))
Ez a feltétel eleve értelmetlen, mivel itt a display-nek none értéket adsz, és vizsgálgatod a visszatérési értékét.Így lenne értelmes:
if($('#SpecifyCodeSnippetLanguage').css('display') === 'none')
Ezenkívül inline-block jelenleg a szövegmező, tehát a sima inline-ra való vizsgálgatás nem lenne jó.
Még valami, simán rossz kódolási szokással kapcsolatos megjegyzés/javaslat:
$('#SpecifyCodeSnippetLanguage').css('display')
ezt egy függvényen belül nem érdemes többször hívogatni, mivel túl sok overheadet jelent.Így lehet elkerülni az overheadet:
var $customCodeSnippetLanguageElement = $('#SpecifyCodeSnippetLanguage');
var $customCodeSnippetLanguageElementVisibility = $customCodeSnippetLanguageElement.css('display');
if($customCodeSnippetLanguageElementVisibility === 'none'){
// ...
} else if($customCodeSnippetLanguageElementVisibility === 'inline-block'){
// ...
}így nem lesz túl sok felesleges függvényhívásod.
-
Sk8erPeter
nagyúr
válasz
trisztan94 #1790 üzenetére
Szívesen! Engem is érdekelt már a dolog, úgyhogy jó, hogy kérdezted.
-
Sk8erPeter
nagyúr
válasz
trisztan94 #1788 üzenetére
Szívesen!
Amúgy kipróbáltam, ha letöltöd, akkor a demo/loadmode.html-t nézd meg mindenképp, abban ki lehet próbálni, hogy bepötyögöd, melyik nyelv syntax highlightját szeretnéd épp alkalmazni, aztán nyomsz egy "change mode"-ot, ez neked épp megfelelne az alapján, amit írtál, csak úgy, hogy akkor nálad lenne egy előre generált select-lista, aztán abból lehetne választani a megfelelőt, és akkor a júzer is meg tudná határozni, melyik kell épp neki.
Durva, mennyire egyszerű beüzemelni, meg van autoformat is (nézd meg a demo/formatting.html demót), nagyon fasza. -
Sk8erPeter
nagyúr
válasz
trisztan94 #1786 üzenetére
Kukkantsd meg a jsFiddle kódját, amibe gépelsz, az valójában nem egy textarea. A mezei textarea-t nem lehet ilyen szinten testreszabni, ezért tehát olyan kell neked, ami ezt lecseréli, és legfeljebb majd submit előtt bepakolja a tartalmat a textarea-ba.
De tulajdonképpen a WYSIWYG-szerkesztők sem a textarea-t próbálják átszabni, hanem odaraknak egy iframe-et vagy egyebet, mindenesetre valamit, ami kicseréli a textarea-t.CodeMirror
ezt használja a jsfiddle.net ÉS a jsbin.com is. Ezek elég meggyőző referenciák. -
martonx
veterán
válasz
trisztan94 #1774 üzenetére
1.9-hez képest, vagy 1.8-hoz képest.
1.9-hez képest csak annyi, hogy ez már (végre!) nem támogatja az Ie6-8-at.
Ettől kisebb, gyorsabb lesz a kód, bár számomra kiábrándító, hogy mindez csak 10%-ot jelent kisebbségben, és gyorsulásban is. De lehet velem van a baj, és feleslegesen vártam többet? Másrészt még csak béta, talán még ki tudnak pár %-ot facsarni a stabil verzióig. Másrészt minden % kissebedés, gyorsulás jól jön, szóval összességében örülünk.
1.8-hoz képest vannak igen drasztikus változások, nem teszteltem, de szerintem komolyan megölik a változások a régebbi pluginek jelentős részét. -
Sk8erPeter
nagyúr
válasz
trisztan94 #1774 üzenetére
http://blog.jquery.com/2013/01/15/jquery-1-9-final-jquery-2-0-beta-migrate-final-released/
Nekem még nem volt kedvem és időm elolvasni, majd összegezd, ha te megtetted. -
Sk8erPeter
nagyúr
válasz
trisztan94 #1761 üzenetére
-
Sk8erPeter
nagyúr
válasz
trisztan94 #1755 üzenetére
Nem volt túl nehéz működésre bírni jsFiddle-ön:
http://jsfiddle.net/Sk8erPeter/PShHD/
(ASP.NET-szalagos kép nem volt, csak ASP-s
)
De ez még így is túlbonyolított megoldás, egyszerűbb lenne class-szal ellátni azokat az elemeket, amikre kötni szeretnéd a közös event handlert, és valami data- attribútummal megadni a kívánt title-t, vagy ilyesmi.Elég egyértelmű, mi a baj a kódoddal: valamilyen érthetetlen okból kétszer kötsz event handlert az elemeidre, ráadásul itt látszólag tök feleslegesen használod az .on()-t.
Tehát előtte nagyjából ilyesmit műveltél:
$('#valami').click(function(){
$('#valami').on('click', function(){
/// hát ez így egy szar!
}
});Most persze leegyszerűsítettem a kódot, amit előtte bemásoltál, hogy a lényeg, tehát a hiba látható legyen. Nem csoda tehát, hogy nem működött az elvártak szerint.
Az AJAX-os dolog meg nem egy bonyolult valami jQuery-ben, a példában látható képekre akár rakhatsz szintén data-attribútummal linket, hogy mit is kéne betölteni, vagy milyen URL-ről, aztán azt használnád fel az $.ajax() függvényedben... na, most egyelőre ennyit volt energiám leírni.
-
Sk8erPeter
nagyúr
válasz
trisztan94 #1753 üzenetére
Így néz ki az AJAX-hívás:
http://api.jquery.com/jQuery.ajax/
De ha valami konkrétabbat kérdezel, akkor még talán érteni is fogom a kérdésedet.másik:
Épp ezért mondtuk hogy rakjál már fel egy példát jsFiddle-re, hogy lássuk, mivel próbálkozol...
Egyébként gondolj bele azok helyzetébe, akik megpróbálnak neked segíteni: meglátják valaki másnak a kódját, el kell kezdeni tanulmányozni, hozzáképzelni a környezetet, mindez neki kerül időbe... kinek éri ez meg?Szóval a kérdezők saját érdeke is, hogy felrakjanak gyakorlati példát, hogy gyorsabban kapjanak (vagy kapjanak egyáltalán) segítséget.
Egyébként nem tudjuk, hogy mire kötöttél click event handlert, de adott esetben mindenesetre nem árthat, ha a végére beteszel egy return false;-t. -
Sk8erPeter
nagyúr
válasz
trisztan94 #1751 üzenetére
Persze, hogy megoldható....
A kódod viszont így nem túl szép.
$('#PhpTutorials').click(openTutorials('#PhpTutorials', "PHP Tutorialok. <a class='GoBack'>Vissza</a>"));
event handlernek nem így adunk át paramétert.
Itt egy érintett topic, gyorsan kikotortam neked:
http://stackoverflow.com/questions/979337/how-can-i-pass-arguments-to-event-handlers-in-jqueryTehát így:
$('#PhpTutorials').click(function(){
openTutorials('#PhpTutorials', "PHP Tutorialok. <a class='GoBack'>Vissza</a>")
});VAGY ha a .bind()-ot akarod használni:
$('#PhpTutorials').click( openTutorials.bind(this, '#PhpTutorials', "PHP Tutorialok. <a class='GoBack'>Vissza</a>") );
Bár utóbbit én feleslegesen nyakatekertnek találom, ízlés kérdése.
-
tick
aktív tag
válasz
trisztan94 #1746 üzenetére
EZT próbáltad már?
-
Sk8erPeter
nagyúr
válasz
trisztan94 #1745 üzenetére
$('#PageTitle').html("PHP Tutorialok. <a class='GoBack'>Vissza</a>");
Azért ezeket nem illik JavaScripttel kiírni, gondolom ez egy cím. Rejtsd el addig CSS-sel, amíg nem szükséges a megjelenítése, vagy ilyesmi.
Ahogy martonx írta, készíts jsFiddle-példát az eddigi próbálkozásodról. -
martonx
veterán
válasz
trisztan94 #1745 üzenetére
jsfiddle?
-
trisztan94
őstag
válasz
trisztan94 #1745 üzenetére
Update:
Próbáltam Callback functionnal is, semm változás
$('#PageTitle').html("PHP Tutorialok. <a class='GoBack'>Vissza</a>", function() {
$('.GoBack').on('click', function () {
$('.TutorialsSlideDown').slideUp(400);
$('.tutorial_listing').slideDown(400);
$('#PageTitle').html("@Page.Title");
}); -
Sk8erPeter
nagyúr
válasz
trisztan94 #1398 üzenetére
Az AJAX-os beléptetést csak azért vetettem fel, mert van, ahol ilyet alkalmaznak.
Szerintem nem érdemes vele pöcsölni, még ha hűdecsicsa is, mert a legtöbb esetben a bejelentkezés után tök más lesz a felület, több link lesz elérhető, stb., most ezeket mind kliensoldalon frissítgetni amiatt, hogy bejelentkeztél, szerintem túl sok felesleges meló, nem történik semmi, ha speciel belépésnél lát egy oldalfrissülést a felhasználó. Persze ha ez a megrendelő kifejezett kérése, meg full AJAX-os felületet akar, akkor nem úszod meg a szarakodást.
Egyszerű példakód meg nincs rá, mert ki tudja, Te milyen elemeket szeretnél frissíteni bejelentkeztetés után. Önmagában a bejelentkezés AJAX-szal pont úgy néz ki, mint bármilyen más, AJAX-szal elküldött form feldolgozása, csak belépteted a júzert, azt' annyi.Most így hirtelen fingom sincs, hogy oldanám meg szépen, mert ahhoz gondolkodni kéne, és ahhoz meg energiát kéne erre szánni, de most nem vagyok olyan állapotban.
(#1399) Frigo :
[link]
"2. How do I install this?
Um... are you stupid or something? Just attackclone the grit repo pushmerge, then rubygem the lymphnode js shawarma module – and presto!" -
Sk8erPeter
nagyúr
válasz
trisztan94 #1394 üzenetére
A $.get AJAX-os oldallekérésekre használható, mindezt GET-metóduson keresztül, ahogy a nevében is benne van: http://en.wikipedia.org/wiki/HTTP#Request_methods
A szavaidból úgy vettem le, hogy nem AJAX-szal jelentkeztetsz be, hanem hagyományos módon, van egy oldalfrissülés.
Így elég sokat találsz ilyenből.Pl. ez, ez, ez, ez, stb.
Azt nem néztem meg, ezek közül melyik a legjobb, nem tanulmányoztam a kódjukat, próbálgasd őket.A stackoverflow-s elég összetettnek tűnik:
function getURLParameter(name) {
return decodeURI(
(RegExp(name + '=' + '(.+?)(&|$)').exec(location.search)||[,null])[1]
);
}"Szóval konkrétan jQuery-vel szeretném megnézni, hogy létezik-e a 'user' nevű GET változó, ha igen akkor történik az esemény. "
Ez nem biztos, hogy jó megoldás.
Ha én kézzel beírom ezt a paramétert, úgy, hogy már rég be vagyok jelentkezve, akkor is mindig mutogatni fogja nekem a slideDownnal megjelenített divet? -
Sk8erPeter
nagyúr
válasz
trisztan94 #1304 üzenetére
Mi az a timer+1?
Ez jó, csökkentetted eggyel a kezdeti értéket a 3-ról 2-re, de azért biztonság kedvéért hozzáadtál plusz egyet, hogy pontosan ugyanott tarts, ahol előtte. (facepalm)Amúgy nem értelek, martonx már elmondta a megoldást elég egyértelműen, hozzátéve persze, hogy ez így nem túl szép megoldás, de van egy
<p id="timer">3</p>
elemed, és a timer-t pedig 2-ről indítod, a korábbi kódoddal, azt' kész vagy.
De nem ártana betenni egy időzítés-leállítót, hogy azért 0-nál lejjebb ne számolgasson már... -
Speeedfire
félisten
válasz
trisztan94 #1304 üzenetére
Leírom megint. A setInterval miatt várakozik 1-et. Állítsd át az 1000-ret 0-ra és akkor nem fog várni.
$(document).ready(function() {
var timer=3;
window.setInterval(function() {
$('#timer').html(timer);
timer--;
}, 0);
}); -
Speeedfire
félisten
válasz
trisztan94 #1301 üzenetére
A setInterval 1000-res paramétere miatt várakozik.
-
martonx
veterán
válasz
trisztan94 #1185 üzenetére
minél kisebb, minél univerzálisabb részekből építed fel a kódodat, az a későbbiekben annál könyebben, annál rugalmasabban módosítható, bővíthető lesz.
-
Sk8erPeter
nagyúr
válasz
trisztan94 #1182 üzenetére
Hagyd a TXT-fájlos megoldásokat, ne gyakorolj olyat, amit hosszú távon úgysem fogsz tudni használni. Úgyis az az általános gyakorlat, hogy kicsinek indul, aztán bővíteni kell, és akkor alakíthatod át teljesen a szarul megírt rendszert. Inkább legyen kicsit komplexebb, de könnyen bővíthető.
-
martonx
veterán
válasz
trisztan94 #1180 üzenetére
A TXT file-os megoldás működhet, ha elég kevés adatot akarsz benne tárolni.
Meg ha nem kell benne sokat keresni. -
Soak
veterán
válasz
trisztan94 #1178 üzenetére
És mondjuk az AJAX-od egy php-re mutat ahova elpostolod az id-t az meg vissza adja amit akarsz.
Nincs mit !
-
Soak
veterán
válasz
trisztan94 #1176 üzenetére
Azokat az adatokat amiket jelenleg az url-ben tárolsz sokkal egyszerűbb lenne adatbázisban. Egyszerűen egy id-t tárolsz az url-ben amit $_GET-el kinyersz, majd azt előhozod az adatbázisból.
A jelenglegi formában iszonyú melós már egy árat is átírni még akkor is ha hozzáférsz a forráskódhoz. Amúgy meg egy nagyon egyszerű admin pagen nyilván tudsz mindent tartani.
-
Male
nagyúr
válasz
trisztan94 #1138 üzenetére
A load-nak van egy complete része (callback), ott rendeld hozzá a gombokhoz amit kell.
-
Male
nagyúr
válasz
trisztan94 #1136 üzenetére
Elég zűrzavar amit írsz, de ugye nem az előtt rendeled hozzá a gombokhoz a click-et, hogy kitennéd őket az oldalra?
-
Sk8erPeter
nagyúr
válasz
trisztan94 #1133 üzenetére
"van két gomb: Termékek és felhasználók, nos ezeket is ajaxolnám a mostani ajax helyére az #ajax divbe.
[...]
Szóval lehet ilyet jquery-vel? Én anno sima mezei JS-el csináltam ajaxban ajaxban ajaxot.. "Azt a k×rva, te aztán tudsz fogalmazni...
"nincs document.readybe"
Akkor legyen.Amúgy imádom az ilyen hibajelzéseket, csak a lényeget nem írod le, hogy mi a hibajelenség, mi van a konzolon (F12 vagy Ctrl+Shift+I, Console fül), mi történik, vagy épp mi NEM történik.
Még próbáld így, pl.:
$('#adminfelhasznalok').on('click', function() {
$('#ajax').load('admin/felhasznalok/felhasznalok.php');
return false;
});Ha ez sem jó, akkor kicsit több infót is ossz meg (meg fogalmazz magyarul
).
Új hozzászólás Aktív témák
Hirdetés
- Bomba ár! Asus Slate EP121 Tablet - Intel Core i5 I 4GB I 64GB SSD I 12" Touch I Cam I W10 I Gari!
- Bomba ár! HP EliteBook 2570P - i5-3GEN I 4GB I 320GB I DVD I 12,5" HD I W10 I Garancia!
- Bomba ár! HP EliteBook 2560P - i5-2GEN I 4GB I 320GB I 12,5" HD I W10 I Garancia!
- Bomba ár! HP EliteBook 2540P - i5-540M I 4GB I 250GB I 12,1" WXGA I W10 I Garancia!
- Bomba ár! Fujitsu LifeBook S761 - i7-2GEN I 8GB I 320GB I 13,3" HD I HDMI I W10 I Garancia!
- Telefon felváráslás!! Xiaomi Redmi Note 11, Xiaomi Redmi Note 11 Pro, Xiaomi 11 Lite
- HYNIX 2GB DDR3 RAM eladó
- ÁRGARANCIA!Épített KomPhone i3 10105F 16/32/64GB RAM RX 6600 8GB GAMER PC termékbeszámítással
- NEC MultiSync V421 monitor (42") 1920 x1080px
- LG 65C3 - 65" OLED evo - 4K 120Hz 1ms - NVIDIA G-Sync - FreeSync Premium - HDMI 2.1 - PS5 és Xbox!
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest