Új hozzászólás Aktív témá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. -
martonx
veterán
Kijött az 1.9-es, meg a 2.0-ás JQuery.

Mondjuk én az 1.9-es kihagyom, a 2.0-ást várom, Ie9 alatt úgyse szupportálok böngészőt. Ráadásul mire meglesz a végső 2.0-ás, addigra hátha a plugin készítők is aktualizálják a pluginjeiket az új API-hoz. -
martonx
veterán
válasz
Sk8erPeter
#1762
üzenetére
Ez zseniális. A varászló manuszt percekig produkáltattam

-
martonx
veterán
válasz
Sk8erPeter
#1756
üzenetére
Te aztán szuper rendes, szuper ráérős vagy

-
martonx
veterán
válasz
trisztan94
#1745
üzenetére
jsfiddle?
-
martonx
veterán
válasz
Brown ügynök
#1705
üzenetére
modernizer
-
martonx
veterán
-
martonx
veterán
válasz
Sk8erPeter
#1658
üzenetére
sehogy nem látja át, rá is hagyta a fejlesztést
-
martonx
veterán
válasz
Sk8erPeter
#1580
üzenetére
igen, ez az általános szabvány dátumoknál.
-
martonx
veterán
válasz
Sk8erPeter
#1578
üzenetére
Így van, de mint mondtam ISO formátumra van felülbírálva a Datepicker dátum formátuma. Ezt a formátumot meg alapból szereti a js is, meg a szerver oldal is.
-
martonx
veterán
válasz
Sk8erPeter
#1576
üzenetére
Mert az lenne a legszebb, ha mindenki a kultúrájának megfelelő dátum formátumon kommunikálhatna. Mondjuk a datepicker globalizálva van, azaz mindenkivel a saját nyelvén kommunikál, csak a végeredmény dátum ISO formátumú.
-
martonx
veterán
válasz
Sk8erPeter
#1574
üzenetére
Datepicker-nél is csúnya vagy nem, de ISO dátum formátumot használok (yyy-mm-dd), noha az oldal több nyelvű. Még csak az hiányzik, hogy 12 kultúra dátum formátumát ismerjem fel, és kezeljem le szépen. Ennyire nem fizetik meg a cuccot
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
martonx
veterán
válasz
Sk8erPeter
#1562
üzenetére
Ezt datepicker-rel használom pont az ilyen problémák áthidalása miatt. Egyébként JS-ben (meg mondjuk nem csak ott) az egész dátum kezelés nagyon gázos. Egy számról könnyű eldönteni, hogy az valóban szám-e, egy dátum mezőbe megadott valamiről eldönteni, hogy az dátum-e, ráadásul ahogy a példád is mutatja a 10/11/2012 az most 2012.11.10 vagy 2012.10.11 közel sem triviális. Talán ezért is nincs erre külön gyári ellenőrzés a jquery validate pluginben.
Mert félreértés ne essék, amiket az unobtrusive megoldásomban használok, egytől egyig (kivéve persze a saját metódusaimat) az alap jquery validate plugin beépített validálási szabályai.
Írj a plugin készítőjének, hogy tegyen bele dátum érvényesség validálást, mert az ötlet szerintem is hasznos. -
martonx
veterán
válasz
Sk8erPeter
#1556
üzenetére
Igaziból ez már a Date.parse-on múlik. Ha sikerült a browsernek parse-olnia a kapott értéket, akkor van értelme az összehasonlításnak, ha nem sikerül neki, akkor nincs.
Én végül nem is a Date.parse-ot használtam, hanem csináltam egy var formdate = new Date(value) változót, mert ez sokkal rugalmasabb, mint a Date.parse, a sima Date sokféle bemeneti dátumformátumot elfogad.
Ha belegondolsz ez az unobtrusive validálás nagyon elegáns, mert MVC design pattern-nél, elég csak a model-edet megfelelően annotálni, megírni a custom validációkat szerver és kliens oldalon (az én példám a kliens oldalt mutatja, a szerver oldali sem bonyolultabb), és voilá, máris kész a szerver és kliens oldali automatikusan működő validációd. -
martonx
veterán
válasz
Sk8erPeter
#1553
üzenetére
A JS-es Date.parse elég gyenge dolog (ezen magamnál még javítottam).
Ha így viszed be a dátumot, akkor tudja a JS parse-olni, és észre is veszi, hogy jövőbeli a dátum.2012-11-01
-
martonx
veterán
válasz
Speeedfire
#1550
üzenetére
De te utálod css-el megoldani azt, amire napokig írhatsz js-t is.
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
martonx
veterán
válasz
Peter Kiss
#1544
üzenetére
Így van, rögtön bele kell tolni a custom validátorokat, nem szabad elkezdeni ellenőrizni, hogy van-e már ilyen meg olyan objektum, készen van-e a DOM?
Ráadásul ez sehol nem volt leírva, két éjszaka árán sikerült végigrágnom magam az egész folyamaton. -
martonx
veterán
Ó bakker, megvan a probléma.
De legalább megtanultam a jquery.validate plugin, meg az unobtrusive bővítményének a mélylélektanát![;]](//cdn.rios.hu/dl/s/v1.gif)
A saját validációmat nem szabad document.ready-be rakni.
Mivel, amikor létrejön a teljes dokumentum, akkor ő fogja és szépen végigveszi, hogy milyen validálások is vannak beállítva az egyes form-okhoz, és ezt okosan le is tárolja magának.
Ezek után már nem számít neki, hogy milyen egyéb metódusokat adok hozzá, mivel ő látja, hogy ezt a form-ot már átnézte. És ezen a parse-olás sem segít, mert ekkor újra átnézné, de mivel látja, hogy már átnézte, mégsem teszi.Viszont ha a document.ready előtt már megadom neki, hogy erre az egyedi metódusra is figyeljen, akkor azt beleveszi a legelső vizsgálatába.
A parse-olás, csak akkor működik, ha addig nem létező (mondju ajax-al odatöltött) elem-en indítom el (érdekes látni, hogy a Jquery saját id-ket képez az elemekhez, és igaziból ezt vizsgálva dönti el, hogy új-e az az elem).
A végső megoldás: http://jsfiddle.net/5wbqd/35/ ami valami miatt JsFiddle-ön nem működik, de ha valaki nagyon ki akarja próbálni, egy html-be beledova (+ a két CDN hivatkozás persze) seperc alatt könnyen kipróbálható.
-
martonx
veterán
Egy fokkal jobb már a helyzet, az unobtrusive.js már látja a validálási szabályt, csak éppen nem hívódik meg a megadott metódus.
Vajon miért nem?
-
martonx
veterán
válasz
Peter Kiss
#1531
üzenetére
No megnéztem, és az adapter és a metódus megvan, parse-ot is csináltam.
Debugolom, és az általam megadott adaptert meg is találja az unobtrusive.js, viszont az alábbi résznél mégsem adja hozzá a gyűjteményhez:$.each(this.adapters, function () {
var prefix = "data-val-" + this.name,
message = $element.attr(prefix),
paramValues = {};
if (message !== undefined) { // Compare against undefined, because an empty message is legal (and falsy)
prefix += "-";
$.each(this.params, function () {
paramValues[this] = $element.attr(prefix + this);
});
//futuredate-nél itt a this.adapt-nál nem adja hozzá a futuredate validálásomat, pedig végigfut a kód,
//csak épp nem csinál semmit
this.adapt({
element: element,
form: form,
message: message,
params: paramValues,
rules: rules,
messages: messages
});
}
});Itt a frissített jsfiddle példa, ahol kiválóan látszik, hogy az unobtrusive validálás már működik, legalábbis a required-re, a date-re nem tudom miért nem működik, a fejlesztői gépemen arra is működik, csak a futuredate-re nem.
-
martonx
veterán
válasz
Sk8erPeter
#1537
üzenetére
de-de, nem is tudtam hogy ezek CDN-ből is elérhetőek. Tök jó, az oldalamon is átállítom ezeket a js-eket CDN-re! Köszi!
-
martonx
veterán
válasz
Speeedfire
#1536
üzenetére
Írtam rá szép model metadata vezérelt megoldást, már csak rá kellene venni ezt a szerencsétlen jquery validátort, hogy használja az én adapteremet, metódusomat is.
No sebaj, este majd még próbálkozok, Athlon-nak lehet igaza, hogy valami gond a metódus, adapter, parse hozzáadással lehet, bár ezeket (emlékeim szerint mind) megcsináltam, a sorrendjükben lehet elrontottam valamit. -
martonx
veterán
válasz
Sk8erPeter
#1534
üzenetére
Igen

De ezt a file-t most így hamarjában nem tudom kirakni netre, pedig ez lenne a lényeg. -
martonx
veterán
válasz
Peter Kiss
#1531
üzenetére
igen, ezek elvileg rendben vannak.
Ráadásul ahogy debugoltam a hiba még azelőtt jön ki, mielőtt egyáltalán megnézné a validation plugin, hogy az adott rule-hoz talál-e végrehajtandó adaptert, metódust.
Tehát magát a rule-t nem tudja beazonosítani. -
martonx
veterán
Itt van egy, de ez még nem tökéletes, mert egy js hiányzik, amihez nem találtam CDN-t:
-
martonx
veterán
Sziasztok!
Kellene nekem Jquery validation plugin segítség. Első körben (tudom égő) az érdekel, hogy JsFiddle-be hogy tudok a sima jquery-n kívül más külső JS-t hozzáadni, hogy megmutathassam a gondot?
Addig is a problémám: adott egy input, amibe unobtrusive módon beletettem pár validálási szabályt, köztük egy sajátot. Ám a validation plugin, pontosabban maga a Jquery, amikor ide ér a validation plugin-nél:
staticRules: function(element) {
var rules = {};
var validator = $.data(element.form, 'validator'); //itt van a kutya elásva
if (validator.settings.rules) {
rules = $.validator.normalizeRule(validator.settings.rules[element.name]) || {};
}
return rules;
},Akkor a saját validátoromat figyelmen kívül hagyja. Ami benne van required, minlength stb... azokat a $.data belepakolja a validator objektumba, a sajátomat nem.
Az input-om így néz ki a belefoglalt validálási szabályokkal:<input name="MDate" id="MDate" type="text" data-val-required="Date field is required." data-val="true" data-val-futuredate="{0} future date" data-val-date="The field Date must be a date." />
A cél az lenne, hogy a $.data felismerje a futuredate-et is, mint validátor rule-t.
-
martonx
veterán
válasz
Sk8erPeter
#1508
üzenetére
Így lehet az ajax által küldött http header-öket konfigurálni. Mondjuk még én se próbáltam, csak egy tipp, megérzés hogy a header-ökben lehet valami eltérés.
-
martonx
veterán
biztonsági szempontok miatt nagyon is sok különbség lehet. Lásd pl. cross-domain problémák.
Emellett a Js közel sem biztos, hogy ugyanazokat a http header-ökkel fogja küldeni a kérést, mint a böngésző a címsorba beírt url esetében.
Ezért is mondtam a Fiddlert, mert azzal seperc alatt meg lehet állapítani a különbségeket. -
martonx
veterán
válasz
martonx
#1506
üzenetére
$.ajax({
type: "GET",
url: "https://ib.slsp.sk/ebanking/login/ibxlogin.xml",
data: {user_id: "999999999", tap: "2", ac: "", pwd: "99999999", lng2: ""},
xhrFields: { //ezt még érdemes lehet kipróbálni
withCredentials: true
},
success: function(data, textStatus, jqXHR) {
// .... csinálj valamit, ha sikeres volt a kommunikáció
// mondjuk kiíratom debuggolás erejéig a konzolra a visszakapott adatot
console.log('siker, data:');
console.log(data);
},
error: function(jqXHR, textStatus, errorThrown) {
// .... csinálj valamit, ha hiba történt
// mondjuk kiíratom debuggolás erejéig a konzolra a textStatust és az errorThrown-t
console.log('para van, textStatus:' + textStatus);
console.log('errorThrown: ' + errorThrown);
},
dataType: "xml"
}); -
martonx
veterán
Fiddler-rel kellene nézegetni a hálózati forgalmat, amikor bankolsz.
Abban össze is tudsz rakni url hívásokat, meg tudod nézni a cookie-t.
Ha kell cookie, akkor ezt érdemes kipróbálni ajax-nál, jól beállított szerveres cross-domain policy esetén:xhrFields: {
withCredentials: true
} -
martonx
veterán
válasz
Speeedfire
#1464
üzenetére
2 másodperc gugli: http://stackoverflow.com/questions/821516/browser-independent-way-to-detect-when-image-has-been-loaded
-
martonx
veterán
válasz
Sk8erPeter
#1452
üzenetére
Jquery UI-ból jött az 1.9, nem a Jquery-ből.
Ami szerintem nagy hiánypótlás az a menü widget, illetve végre nem az ősrégi 1.3.2-es Jquery-t használják, hanem az 1.6-ost, ami úgy általában is jótékonyan hat a teljesítményre, meg a letöltendő js méretére is.
Belegondolva, hogy két és fél év kellett az 1.8 - 1.9 váltáshoz, és a 2.1-esre ígérik a grid-et a roadmap-jük szerint, kár is várni a JQueryUI team-re. -
martonx
veterán
-
martonx
veterán
Kijött az JqueryUI 1.9
Már csak egy rendes grid, meg egy uploader kellene az alap készletbe és tökéletes is lenne.
Azért ezeknek a kis előre lépéseknek is örülök. -
martonx
veterán
válasz
Sk8erPeter
#1440
üzenetére
Én meg nem győzök windows vonalon mindenre Dark theme-et rakni. Nálam még a VS, SSMS, Notepad++ is sötét

Gondolom mivel Linux-okat a hardcore felhasználók a mai napig is konzolon használják (az pedig fekete alapon fehér betűs), ezért ott tradíció a sötét témák használata. Én néha még ma is konzolon nano-val is szerkesztek php-t, js-t, amikor hirtelen kell reagálni, és nagyon nincs más kéznél. -
-
martonx
veterán
Visual Studio 2012 (ingyenes Express for Web változat is!) nagyon szépen kezel minden létező JS framework-öt.
Open Source rajongóknak a Netbeans az általam ismert legjobb webfejlesztő eszköz. Elég jól kezeli a JS-eket, jquery-t.
Mintha az Eclipse-et is lehetne okosítgatni, én személy szerint kevés dolgot rühellek jobban, mint az Eclipse.
Végszükség esetén ott a Notepad++. -
martonx
veterán
válasz
Sk8erPeter
#1405
üzenetére
Gondolom a Yii-nek (ahogy minden mvc framework-nek) is van egy default unobtrusive validálási metódusa. Ezt vagy használod vagy nem. Ha nem, akkor sajátot kell írni, ami ugyan nem nagy dolog, de minek vele vessződni, ha egyszer ott van egy kész validálási metódus.
Ezeket a gyári validálásokat lehet bővíteni, mindenféle extra szabályt létrehozni hozzájuk. Amit nem nagyon lehet (js-ekben túrkálás nélkül), az annak szabályozása, hogy mikor fusson le a validálás. -
martonx
veterán
válasz
Speeedfire
#1391
üzenetére
Nekem abszolút nem fáj, csak mindig elcsodálkozok a kerék újra feltalálásán. Segíteni akartam, hogy ne dolgozz feleslegesen.
-
martonx
veterán
válasz
Speeedfire
#1384
üzenetére
<div class="squaredThree">
<input type="checkbox" value="None" id="squaredThree" name="check" />
<label for="squaredThree"><label>
</div>A fenti 4 soron mi nem tetszett?
-
martonx
veterán
válasz
Speeedfire
#1380
üzenetére
Egyrészt te is span-oltad a checkbox-ot, hogy normális kinézete legyen. Csodák nincsenek.
Másrészt tele az internet checkbox testre szabással, tessék gugliztam helyetted egyet:
http://cssdeck.com/labs/css-checkbox-styles -
martonx
veterán
válasz
Speeedfire
#1380
üzenetére
esetleg megfogalmaznád, hogy miben is áll a checkbox-od egyedi kinézete? Ugyan ez nem css topik, de esetleg tudnánk segíteni.
-
martonx
veterán
válasz
Speeedfire
#1376
üzenetére
A Jqueryzés tárgya az volt, hogy másképp nézzen ki a checkbox, ha fölé megy a user az egérrel? Mert ezt css-el meg lehet oldani, ehhez igazán nem kell javascript.
Vagy valamit félreértettem? -
martonx
veterán
válasz
Speeedfire
#1352
üzenetére
Na ne már! Ha egy funkcióba beleírsz egy másik funkciót akkor az szerinted globális kellene, hogy legyen???.
Egy minimális javascript alapismeretet azért szedhetnél magadra.Úgy látom, olyan dolog ez a jquery-zés, mint biciklizni nem tudó mamáknak a bicikliút. Még az a mama is elindul biciklizni, aki amúgy ön és közveszélyesen nem tud biciklizni.
-
martonx
veterán
Elég meredek alatt mit értesz? Komoly, jó cucc, vagy épp ellenkezőleg?
Mondjuk nekem alapból szimpatikusabbak a leíró framework-ök (pl. Jquery Mobile), mint a háttérben létrehozós (Sencha Touch) framework-ök. Ez persze elég szubjektív dolog.Mindkét framework típusra van egy-egy jó angol műszó, ami most nem jut az eszembe

-
martonx
veterán
válasz
Speeedfire
#1305
üzenetére
amikor vak vezet világtalant 
-
martonx
veterán
válasz
Speeedfire
#1302
üzenetére
Ez a normális működés része. Hiba nincs, csak éppen így ez 4 másodpercig számol vissza másodpercenként.
Ergo, ha 3-ig akarod, hogy visszaszámoljon, akkor 2-re kell állítani a var timer-t.
A kijelzett másodperc számhoz meg hozzá kell adni 1-et, és jó is lesz.
Vagy újra gondolod a logikádat. -
martonx
veterán
válasz
Speeedfire
#1259
üzenetére
Hűűű, miket nem tud ez a Yii... Viccet félretéve, ezt bármilyen framework meg tudja csinálni, sőt kézzel is oda fűzöd be a js-t, ahova jól esik
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
martonx
veterán
Egyébként röhej, hogy az alap Jquery UI mennyire minimális funkcióval bír.
Nincs benne select, nincs benne grid, nincs benne upload. Persze mindenhez lehet találni ilyen-olyan plugineket, de nagyon macerás őket összeválogatni, css-ezni.
Egy újabb Jquery változat kiadása helyett, igazán gatyába rázhatnák már végre az UI-t. -
martonx
veterán
válasz
Speeedfire
#1213
üzenetére
Ha nem tökéletesen hülyeséget kérdezel, ami kerek-perec le van írva a Jquery dokumentációjában, akkor nincs baj a kérdéseiddel.
![;]](//cdn.rios.hu/dl/s/v1.gif)
Ahogy néztem, az lehet a baj, hogy a #table selectorod túl általános. Erre rákötve a hover-t, az folyamatosan elsül. -
martonx
veterán
IE9 és FF15, meg Chrome akárhányas - a legújabb. Egyiknél sem csinál semmit a resizing.
No mindegy, az IE miatt amúgy is kezelnem kell szerver oldalon az átméretezést.
Mivel publikus hoszting-on lesz a készülő cucc, aminek mind a sávszélessége, mind a napi adat forgalma, mind a szerver erőforrása erősen limitált, így gondoltam legalább FF, meg chrome alól ne érkezzenek több megás képfeltöltések.Ez a plupload egészen jópofának tűnik, lehet ezzel 100%-ban ki tudnám váltani a szerver oldali átméretezést. Este kipróbálom.
-
martonx
veterán
Sziasztok!
Tudtok-e ajánlani valami jó kép feltöltő jquery plugint? Olyan kellene, amivel még kliens oldalon rögtön át is tudom méretezni a feltöltendő képet.
Ezt használom jelenleg: https://github.com/blueimp/jQuery-File-Upload
Maga a feltöltés része működik is, de az átméretezést nem sikerül működőképesre beparamétereznem, és sehol nem találtam hozzá egy működő példa kódot.Itt van a jelenlegi működő kódom (tudom, hogy az .each ebben a kódban felesleges, mielőtt szóvá tennétek
):$("#file").fileupload({
url: "../Account/FileUpload",
dataType: "json",
done: function (e, data) {
$.each(data.result, function (index, name) {
var insert = "<img src='" + name + "' height='120' width='160' />";
$("#avatar").append(insert);
});
}
});Ezt kellene valami ilyesmire átalakítani (nem működik az alábbi kód):
$('#fileupload').fileupload({
url: "../Account/FileUpload",
dataType: "json",
process: [
{
action: 'load',
fileTypes: /^image\/(gif|jpeg|png)$/,
maxFileSize: 20000000 // 20MB
},
{
action: 'resize',
maxWidth: 1920,
maxHeight: 1200,
minWidth: 800,
minHeight: 600
},
{
action: 'save'
}
],
done: function (e, data) {
$.each(data.result, function (index, name) {
var insert = "<img src='" + name + "' height='120' width='160' />";
$("#avatar").append(insert);
});
}
}); -
martonx
veterán
Sziasztok!
Tudtok-e ajánlani valami jó kép feltöltő jquery plugint? Olyan kellene, amivel még kliens oldalon rögtön át is tudom méretezni a feltöltendő képet.
Ezt használom jelenleg: https://github.com/blueimp/jQuery-File-Upload
Maga a feltöltés része működik is, de az átméretezést nem sikerül működőképesre beparamétereznem, és sehol nem találtam hozzá egy működő példa kódot.Itt van a jelenlegi működő kódom (tudom, hogy az .each ebben a kódban felesleges, mielőtt szóvá tennétek
):$("#file").fileupload({
url: "../Account/FileUpload",
dataType: "json",
done: function (e, data) {
$.each(data.result, function (index, name) {
var insert = "<img src='" + name + "' height='120' width='160' />";
$("#avatar").append(insert);
});
}
});Ezt kellene valami ilyesmire átalakítani (nem működik az alábbi kód):
$('#fileupload').fileupload({
url: "../Account/FileUpload",
dataType: "json",
process: [
{
action: 'load',
fileTypes: /^image\/(gif|jpeg|png)$/,
maxFileSize: 20000000 // 20MB
},
{
action: 'resize',
maxWidth: 1920,
maxHeight: 1200,
minWidth: 800,
minHeight: 600
},
{
action: 'save'
}
],
done: function (e, data) {
$.each(data.result, function (index, name) {
var insert = "<img src='" + name + "' height='120' width='160' />";
$("#avatar").append(insert);
});
}
}); -
martonx
veterán
válasz
Speeedfire
#1204
üzenetére
Ember, annyi fáradtságot vegyél már, hogy megnézed a jquery hivatalos dokumentációt mielőtt hülyeségeket kérdezel. Mondjuk kezdtnek google -> jquery .on keresőszavakra az első találatot javaslom.
-
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.
-
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. -
martonx
veterán
válasz
Speeedfire
#1157
üzenetére
És az ajax-od csak annyit ad vissza, hogy pl 1,2,3,4,5, esetleg json objektumokat, vagy tényleges html kódrészt:
<option>1</option>
<option>2</option>
<option>3</option>
<option>4</option>
Mert ez utóbbi azért elég tré lenne. -
martonx
veterán
válasz
trisztan94
#1123
üzenetére
jquery saját dokumentációjából, webes tutorialokból. Bevallom konkrét jquery könyvet sosem olvastam.
Más programnyelvek (C# és leszármazottai ASP.NET, Silverlight) esetében futottam már át jópár ebook-ot, de inkább a saját dokumentációkból, webes példákból, oktató videókból tanultam. Rémlik mintha egyszer nekifogtam volna valami baromi hosszú PHP-s könyvnek is, de ott is inkább a webről szedtem az információkat. -
martonx
veterán
Az apache-ok lelki világát annyira nem ismerem mostanában tökéletesen átszoktam (hál'istennek) IIS-re. IIS-en viszont van olyan beállítás, hogy ha túl hosszú egy GET/POST/akármi, akkor simán figyelmen kívül hagyja az IIS a kapott adatot. Ilyenkor csak annyit látsz, hogy az adat elment, viszont nincs mit debugolni sem rajta, mert az alkalmazásig már nem is továbbítja az IIS.
Lehet, hogy it is valami ilyesmi gond lesz? Szóval én lehet szétnéznék az Apache lelki világában, ki tudja hogy van bekonfigolva a hoszting cégnél? -
martonx
veterán
[https://github.com/wymeditor/wymeditor]
Ez milyen?
-
martonx
veterán
konkrétan én sem, de legyünk már egy csöppet találékonyak. A CKEditor, meg minden hasonszőrű plugin létrehoz egy rakás DOM elemet.
Ezek közül leellenőrzöd a legfelsőt, hogy ott van-e, és ha ott van, akkor létrejött a CKEditor, ha nincs ott, akkor nem jött létre.
Ilyen egyszerű. -
martonx
veterán
válasz
Sk8erPeter
#1032
üzenetére
Elárulom, hogy Android emulátorral fejlesztek. Nekem céges butafon-om van, és hülye lennék bármennyit is költeni telefonra (aztán mikor egy-egy etap kész, akkor teszteljük mindenféle készüléken). Amit írtam a statisztikák alapján írtam. Fejlesztőként viszont rendesen szívok az Android platform töredezettségével, utálom is rendesen.
-
martonx
veterán
Az animáció Android oprendszer, és mobil proci függő. Ami egy Galaxy SII-esen röccenés nélkül animál, az egy Alctel OT-akárhányon úgy szaggat, hogy rossz nézni. Viszont a többségnek Alcatel szintű hardware-e, meg oprendszere van.
Másrészt mindez egyedül Android-on probléma, IOS-en, WP7-en, BlackBerry-n nem probléma.
De ha egyszer mindenki a kártyásan 20K-s android-os fosokat veszi meg, akkor a fejlesztőnek ezt kell kiindulási alapnak vennie
-
martonx
veterán
válasz
Sk8erPeter
#1026
üzenetére
jelentem per pillanat Android 2.1-es régi szutyok gépekre optimalizált weboldalt (igazából phonegap projekt) fejlesztek jqueryvel, és nem jelent rájuk semmiféle terhelést az események dinamikus bekötése.
Az egyetlen ami terhelést jelent nekik, bármiféle animáció (slide, toggle, fade ilyesmik) lejátszása a böngészőben. -
martonx
veterán
-
martonx
veterán
attól függ, melyik statisztikákat nézed. Nézőpont kérdése, hogy IE, vagy Chrome vezet, miközben a firefox-nak is elég masszív részesedése van.
Nálunk egyébként a külsős webfejlesztő beszállítók meg is mondták, hogy IE6-7-et 2012-től kezdve nem támogatnak és kész. Vagy ha támogatják akkor meg olyan horror áron, hogy ösztönözzék ők is az átállást. IE6-7-et már a Microsoft sem támogatja, szóval tényleg ott tartunk, hogy seperc alatt tökéletesen kikopnak.
-
martonx
veterán
Én jellemzően magunknak fejlesztek. A böngésző statisztikákat nézve az IE6-7 már most is teljesen marginális, az Ie8-nak még van vagy 15%-os részesedése (nálunk is ez van jelenleg), de a trendeket elnézve 2013 végére az IE6-7-8 együttesen is 5% alá fog esni. 2014 végére meg, amikorra lesz itt Jquery 2.0 valahova 1% környékére várom az IE6-7-8 globális részesedését.
-
martonx
veterán
Én párszáz gépes környezetben dolgozok, és nálunk 2013-ra tervezik a win7 átállást (mondjuk vicces, mert addigra lesz 1 éves a win8). Azért, amelyik cég 2014-re is egy akkorra 13 éves oprendszert használ, ott komoly gondok vannak. Ráadásul (nálunk legalábbis), az IE8 nagyon erősen behatárolja a belső IT fejlesztési lehetőségeket is, már csak ezért is előbb-utóbb rákényszerülnek a cégek a váltásra.
-
martonx
veterán
"Modern böngészőkben meg semmi szükség JSONP-vel kockáztatni" - azért cross-domain esetben a jsonp-t érdemes használni, böngésző modernség ide-vagy oda.
Illetve lehet json is, ha a szerver oldal rendesen fel van készítve a cross-domain-re, meg ha bevállalják, hogy dupla kommunikáció történik minden egyes json adatcserekor (kommunikáció 1. a böngésző megkérdezi a szervert, hogy működik-e cross-domianben, majd kommunikáció 2. ha a jól felkészített szerver erre igen-nel felel, akkor mehet a cross-domain json akár POST-tal is GET helyett). -
martonx
veterán
-
martonx
veterán
válasz
Speeedfire
#815
üzenetére
Viszont mindegyik megoldás szimpla html és javascript ismereteket feltételez, meg némi józan paraszti észt. Kár ilyen apróságok miatt a jquery topik-ot teleszemetelni.
-
martonx
veterán
válasz
Speeedfire
#813
üzenetére
Kapásból van pár öteletem erre. Annyira bagatell a kérdés, hogy fél perc gondolkodás után biztosan neked is eszedbe jut legalább 1 megoldási lehetőség, így inkább meghagyom neked a ráeszmélés élményét.
-
martonx
veterán
válasz
Speeedfire
#791
üzenetére
miért nem használsz inkább valami rendes wysiwyg editort pl. fckeditor?
-
martonx
veterán
válasz
Sk8erPeter
#755
üzenetére
Hát igen, nálam a SEO abszolút nem játszik.

Azért manapság AJAX mellett sem lehetetlen kereső optimalizálni, csak macerásabb: link
A példád jó, ilyenkor tényleg szerver oldalon kell a képeket manipulálni, aztán majd külön letölti valaki a képet, ha nagyban akarja látni.
Másrészt egy profil képet minek letárolni nagyban, ha úgyis mindig csak bélyegnyi méretben jelenik meg?
Nem zárkózok én el a szerver oldali programozás elől, csak az én szektoromban tényleg egyre minimálisabb szerepe van. -
martonx
veterán
válasz
Sk8erPeter
#749
üzenetére
Én mostanra már a sztenderd html lap kiszolgálás, db kapcsolat (szigorúan minden ajax-al!), meg némi csv, pdf generáláson (amik szintén db-ből származó adatok) kívül semmire nem használom a szerver oldalt.
Session-öket is már csak akkor használok, mikor tényleg szerver szinten kell állapotokat rögzíteni, egyébként mindenhez HTML5 localstorage.
Szép új jövő. -
martonx
veterán
válasz
Speeedfire
#732
üzenetére
.blur()
-
martonx
veterán
ezzel mi a probléma? Azon kívül, hogy ronda, és template-et illene használni.
Mondjuk én egy ideje MVC design patternt használok, ott ezt egy partialview-val oldanám meg.
Ha mindenképpen egy lapon belül akarnék sok dom elemet ide-oda beszúrogatni ajax-al, akkor meg knockout.js-t használnék.
Példa kódokat lusta vagyok írni.![;]](//cdn.rios.hu/dl/s/v1.gif)
Hopp, lehet megértettem a problémád. Te adatbázisban a test.html file nevét tárolod le, nem pedig a test.html tartalmát. De miért szivatod magad ilyenekkel? A helyedben azon is elgondolkoznék, hogy a képet is cakk-pakk letárolnám SQL-ben.
Ha a test.html tartalmát tárolod le, semeddig nem tart azt ajax-al kiküldeni a kliensnek, a kép nevével együtt, ahol beilleszted őket a megfelelő helyre, és már kész is. -
martonx
veterán
az ajax success-ébe kell beleraknod a dinamikus rész click esemény kezelését.
Másrészt én a helyedben a span-os részt átírnám, hogy a button-nak legyen egy data tag-je, és ezt olvasnám ki. Amikor html-t utaztatsz / raksz össze, felesleges a DOM-ot egy csomó plusz elemmel terhelned.
data() jquery függvénnyel pedig ki lehetne olvasni, hogy mit is rejtettél bele.
Új hozzászólás Aktív témák
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest



![;]](http://cdn.rios.hu/dl/s/v1.gif)




