Új hozzászólás Aktív témák
-
cidalain
veterán
válasz
martonx
#4881
üzenetére
Szerintem félreérted.
Eddig statikus volt a weboldal, de most kitalálták, hogy kellene egy oldalon dinamikus feltöltés (híreket akarnak feltölteni).
(Az hogy eddig statikus volt a weboldal, nem feltétlenül jelenti azt hogy a tárhely alkalmatlan a dinamikus oldalak futtatására. Ha alkalmas PHP futtatására, akkor mindjárt kiesik az az FTP-zős bonyolultság. Meg nem is értem hogy az eddigi statikus oldalt miért kéne átalakítani dinamikussá?)>> GearBest Club Veszprém << >> https://www.facebook.com/gbc.veszprem <<
-
cidalain
veterán
válasz
martonx
#4884
üzenetére
Hát lehet hogy igazad van: ugyanazt a tartalmat akarja e mindegyik oldalon, vagy csak ugyanazt a lehetőséget más tartalommal. Nem mindegy.
Ha több oldalon is ugyanaz a tartalom kell 1 adminnal akkor:
Én azt csinálnám, hogy az egyiken lenne az admin, és ezen az oldalon generálnék egy XML-t (mondjuk valós időben), és a másik oldalak, csak beszippantják ezt amikor a híreket írnánk ki, és az XML-t értelmezve kiprintelnék az adatokat.Mondjuk a friss híreknél ennek van értelme (10-20 legfrissebb), de 5678 hírt így átszippantani nem túl előnyös.
Ez esetben már felépíteném az adatbázis mindhárom helyen, és az XML-ből értelmezés után bele is vágnám bázisba. Így mindenhol egyezne az adatbázis, de admin csak 1 helyen lenne. Ez esetben a kiiratás egyezik mindenhol, adatbázis dettó, az egyik helyen admin kell és XML generátor, a másikon meg XML értelmezőViszonylag egyszerűen kivitelezhető, és az ügyfélnek továbbra sem kell semmit extrát sem tudnia, csak az egyetlen adminját kezelni.
Ez a megoldás nekem már gyönyörűen bevált. Sőt egy hasonló is, igaz az nem XML alapú volt hanem egyedi, és egy Win-app feltette nekem a tárhelyre FTP-n az anyagokat bizonyos időközönként (adott volt az FTP-zés, így ki is használtam)
[ Szerkesztve ]
>> GearBest Club Veszprém << >> https://www.facebook.com/gbc.veszprem <<
-
-
cidalain
veterán
válasz
martonx
#4892
üzenetére
én azt nem kedvelem, hogy a CMS-eket árulják komoly weboldalként 30E-ért. feltelepíti az alapot, jó esetben keres egy free sablont, rossz esetben marad a gyári. tököl vele 2 délutánt. az emberek meg ezt veszik alapul (árban legalábbis).
ez elég erőteljesen rontja a bizniszt, és 1-2 óra mindig azzal megy el az ügyfél felé, hogy a te webshopod miért kerül 90-be, meg a designer miért 40-50-ért csinálja meg a sablont, mikor máshol 30-ért megkapja az egészet...én meg pont hogy szeretek programozni. a kattintgatással nem fejlődök. és ha nincs fejlődés akkor megette az egészet a fene, akkor kár is csinálni. iszonyat jól tud esni ha egy megszokott dolgot megcsinálok az újabb ismeretekkel máshogyan, egyszerűbben. volt nekem is olyan munkatársam aki a munka elkezdésekor egyből googlival kezdett, aztán összeollózta, majd megformázta a kódot, és kész. most hogy már nincs iszonyat javítani (fejleszteni) bármit is a kódjában, mert nincs benne programozói stílus, egyszer ilyen megoldás egyszer olyan (ahogy jött a google találat)
[ Szerkesztve ]
>> GearBest Club Veszprém << >> https://www.facebook.com/gbc.veszprem <<
-
cidalain
veterán
válasz
martonx
#4955
üzenetére
Mondjuk a kerdezotol nekem nem az jon le, hogy most o ezzel foglalkozik, inkabb egy eseti melo ez neki. Esetleg kesobb csinalna tobbet. Nem valoszinu hogy szamlakepes.
Persze szamit hogy mennyit foglalkozol a cuccal, de ralisnak is kell maradni. Nyilvan aki lassabban dolgozik, 2x annyi idejebe kerul, de oszinten, fizetnel neki ketszer annyit?
Sima egyszeru designtervet 30 alatt be sem vallalnek, de akivel szoktam dolgozni grafikus, o 50-nel kezd. Ez csak egy oldalsablon elkeszitese, az elrendezes, a szinek, a tervezes, stb. Erre szokott rajonni oldalankent par ezer penz. Ezek netto arak. Ismerosnek ha kell szamla nelkul, akkor ennel nem lehet tobbet kerni. Sokan vannak akik ennel olcsobban csinalnak weboldalt. A megrendelok nagyon arerzekenyek, barkit megbiznak, ha alacsony arat mond.
Ha mar elkeszitett sablonomat tudom ajanlani (szerkezet, elrendezes ok a vevonek) akkor tudok kicsit engedni, mert akkor eleg 1 du photoshop, meg a css-t atirom az o szineire aztan okes.
En altalaban delutanonkent erek ra, nagyjabol tudom elore, mennyi idot vesz igenybe a melo. Mondjuk 10 delutan. Akkor idoben duplajat szoktam mondani, mert tuti van olyan hogy nincs kedved melozni, stb.
De vannak amik atirjak ezt. Pl volt olyan hogy ket napom volt csinalni egy full oldalt. Siman kertem 2x es surgossegi felarat, es marha jol jott ki az oraber :-)
>> GearBest Club Veszprém << >> https://www.facebook.com/gbc.veszprem <<
-
cidalain
veterán
válasz
martonx
#4982
üzenetére
ha html a doksi akkor biztosan. arra való a horgonyos cucc:
..../valami.html#masodik_fejezetde talán word doksival is meg lehet oldani, de akkor valami word doksi megjelenítőt kellene illeszteni a kódba, és ott talán lehet x. oldalra ugrasztani. pdf-ben létezik e ilyen, de hogy word doc-ra is azt nem tom (hasonlóra gondolok mint egy videólejátszó beillesztése, csak itt dokumentum viewer)
[ Szerkesztve ]
>> GearBest Club Veszprém << >> https://www.facebook.com/gbc.veszprem <<
-
#5078
DeltaPower
őstag
martonx
#5077
DeltaPower
őstag
válasz
martonx
#5077
üzenetére
[link] IE10 a bal oszlop zöld gombos menüjének celláját függőlegesen megnyújtja. A fura, hogy inspectelve ugyanakkora magasságot jelez rá, mint a ffox, pedig láthatóan sokkal nagyobb.
"Moonshine Whiskey (70°, ízesítés nélküli) van. Fincsi" - Teebee - "De az kiírtaná az egész családomat..Akkor is ha csak én innék belőle.." - forintuser
-
Kurik
tag
válasz
martonx
#5113
üzenetére
Tudtam, hogy valamit kihagytam...
<html>
<head>
<title>Browse Folders</title>
<SCRIPT LANGUAGE="JavaScript">
<!--
var currentFolder="";
function GetDriveList(){
var fso, obj, n, e, item, arr=[];
try {
fso = new ActiveXObject("Scripting.FileSystemObject");
}
catch(er) {
alert('Internet Expolerbe kell elindítani.');
cancelFolder();
}
e = new Enumerator(fso.Drives);
for(;!e.atEnd();e.moveNext()){
item = e.item();
obj = {letter:"",description:""};
obj.letter = item.DriveLetter;
if (item.DriveType == 3) obj.description = item.ShareName;
else if (item.IsReady) obj.description = item.VolumeName;
else obj.description = "[Drive not ready]";
arr[arr.length]=obj;
}
return(arr);
}
function GetSubFolderList(fld){
var e, arr=[];
var fso = new ActiveXObject("Scripting.FileSystemObject");
var f = fso.GetFolder(fld.toString());
var e = new Enumerator(f.SubFolders);
for(;!e.atEnd();e.moveNext()){
arr[arr.length]=e.item().Name;
}
return(arr);
}
function loadDrives(){
var drives=GetDriveList(),list="";
for(var i=0;i<drives.length;i++){
list+="<div onclick=\"loadList('"+drives[i].letter+':\\\\\')" class="folders" onmouseover="highlight(this)" onmouseout="unhighlight(this)">'+drives[i].letter+':\\ - '+ drives[i].description+'</div>';
}
document.getElementById("path").innerHTML='<a href="" onclick="loadDrives();return false" title="My Computer">My Computer</a>\\';
document.getElementById("list").innerHTML=list;
currentFolder="";
}
function loadList(fld){
var path="",list="",paths=fld.split("\\");
var divPath=document.getElementById("path");
var divList=document.getElementById("list");
for(var i=0;i<paths.length-1;i++){
if(i==paths.length-2){
path+=paths[i]+' \\';
}else{
path+="<a href=\"\" onclick=\"loadList('";
for(var j=0;j<i+1;j++){
path+=paths[j]+"\\\\";
}
path+='\');return false">'+paths[i]+'</a> \\ ';
}
}
divPath.innerHTML='<a href="" onclick="loadDrives();return false">My Computer</a> \\ '+path;
divPath.title="My Computer\\"+paths.toString().replace(/,/g,"\\");
currentFolder=paths.toString().replace(/,/g,"\\");
var subfolders=GetSubFolderList(fld);
for(var j=0;j<subfolders.length;j++){
list+="<div onclick=\"loadList('"+(fld+subfolders[j]).replace(/\\/g,"\\\\")+'\\\\\')" onmouseover="highlight(this)" onmouseout="unhighlight(this)" title="'+subfolders[j]+'" class="folders">'+subfolders[j]+"</div>";
}
divList.innerHTML=list;
resizeList();
divPath.scrollIntoView();
}
function resizeList(){
var divList=document.getElementById("list");
var divPath=document.getElementById("path");
if(document.body.clientHeight>0 && divPath.offsetHeight>0){
divList.style.height=document.body.clientHeight-divPath.scrollHeight;
}
}
function highlight(div){
div.className="folderButton";
}
function unhighlight(div){
div.className="folders";
}
function selectFolder(){
var myobject = new Object();
myobject.first = currentFolder;
window.returnValue=currentFolder + showModalDialog("file.htm", myobject ,"width:400px;height:400px;resizeable:no;");
if (window.returnValue != currentFolder)
{ window.close();
}
}
function cancelFolder(){
window.returnValue="";
window.close();
}
-->
</SCRIPT>
<style>
#header{
background-color: #cccccc;
border-bottom: solid 1px black;
}
#path{
position:relative;
font-size: 8pt;
font-family: Arial;
font-weight: bold;
padding: 2px;
}
#list{
font-size: 10pt;
font-family: Arial;
overflow:auto;
}
.folders{
padding: 1px;
border-top: solid 1px white;
border-left: solid 1px white;
border-right: solid 1px white;
border-bottom: solid 1px black;
cursor: hand;
pointer: hand;
background-color: #FFCC00;
}
.folderButton{
padding: 0px;
border-style: outset;
border-width: 2px;
border-color:;
cursor: hand;
pointer: hand;
background-color: #DDAA55;
}
A{
color:blue;
text-decoration:none;
padding:3px;
}
A:hover{
background-color: #DDAA55;
padding:1px;
border-style: outset;
border-width: 2px;
}
</style>
</head>
<body onload="loadDrives()" onresize="resizeList()" marginwidth="0" marginheight="0" leftmargin="0" topmargin="0" bgcolor="#FFCC00" scroll=no>
<form>
<div id="container">
<table border="0" cellpadding="0" cellspacing="0" id="header">
<tr>
<td><div id="path"></div></td>
<td align="right" width="1%" nowrap>
<input type="button" value="Select" onclick="selectFolder()"><input type="button" value="Cancel" onclick="cancelFolder()">
</td>
</tr>
</table>
<div id="list"></div>
</div>
</form>
</body>
</html>
A szerver egy régi XP-s gép amin IIS van. Pontosan azt szeretném elkerülni, hogy asp-be kelljen írni.
Köszönöm a válaszokat.
Ha tévedek, ki lehet javítani :)
-
Kurik
tag
válasz
martonx
#5115
üzenetére
Leírom a folyamatot, mit szeretnék vele. Az említett fos XP-s gépen futnak a torrent-jeim a másik házba. (Belvárosba, mert ott jóval jobb net szolgáltatás érhető el, mint idehaza.) Eddig is egyszerű video plyer-el néztem itthonról a letöltött filmeket, csak mindig átkellet írni a video fájl hivatkozását. Ezt szerettem volna bővíteni a tallózás lehetőségével. (Ami helyben működik is...
)Az "újraírod normálisan" mit jelent? (természetesen, nem az újraírás szót nem ismerem
)
Mi az amit hibáztam és változtatnom kéne?Az eddigi és a további válaszaidat is Köszönöm!
[ Szerkesztve ]
Ha tévedek, ki lehet javítani :)
-
#5134
Sk8erPeter
nagyúr
martonx
#5131
Sk8erPeter
nagyúr
válasz
martonx
#5131
üzenetére
Ja, sikerült faszán felcserélnem a "miről-mire" kérdést.
(#5132) KaiotEch :
Hát akkor ne lepődj meg, pont ezért kérdeztem (bár véletlenül fordítva kérdeztem, mint akartam), mivel a Linux case sensitive, a Windows pedig case insensitive (nem törődik a kis- és nagybetűk közti különbséggel), így ott nem mindegy, hogy kis- vagy nagybetűvel írod az útvonalat.Első megoldás, hogy a megfelelő URL-t írod be mindig (figyelembe veszed, hogy nem mindegy, hogyan írod be), második megoldás, hogy csakis kisbetűs fájlokat (és URL aliasokat) engedélyezel például feltöltéskor, harmadik megoldás a mod_speling (nem elírás az egy l betű!) modul engedélyezése, majd
CheckSpelling On
beállítása. Innen szedtem:
http://answers.oreilly.com/topic/108-how-to-permit-case-insensitive-urls-with-apache/
http://httpd.apache.org/docs/2.2/mod/mod_speling.html#checkspelling
Ennek viszont - ahogy írják, és nem meglepő -, van teljesítménybeli vonzata, ronthat, bár nyilván esetfüggő, egyáltalán észrevehető-e.Ja, és feltételeztem, hogy Apache-ot használsz.
Sk8erPeter
-
#5174
Sk8erPeter
nagyúr
martonx
#5173
Sk8erPeter
nagyúr
válasz
martonx
#5173
üzenetére
Jelen esetben rossz embereket vádolsz, CSorBA (aki állítólag korrepetál is webfejlesztésből
) és PumpkinSeed közölték, hogy ők jól megvannak a localhostos teszteléssel:
http://prohardver.hu/tema/weblap_keszites/hsz_7523-7525.htmlSk8erPeter
-
biker
nagyúr
válasz
martonx
#5173
üzenetére
én sem szeretek, mert nem egyszer jártam már úgy hogy helyi gépen xampp mellett király minden, aztán feltöltve kiderül, X Y le van tiltva, limites, akármi, és szopok mint a torkosborz, de szoktam azért használni...
én is azt szeretem, ha a kezdetektől az éles server egy elkülönített, nem publikus részén tesztelünkElektromos autó töltő berendezések | Mesterséges növényvilágítás | Mai ajánlatunk: www.gerisoft.hu | www.e-autotoltokabel.hu | www.agrar-vilagitas.hu |
-
-
sz.j
nagyúr
válasz
martonx
#5248
üzenetére
Köszönöm a válaszod, de ezt eddig is tudtam ....
Az eredeti kérdésem úgy szólt, hogy
"HTML-ben (tehát nem css-el!), hogy tudom a szöveg sortávolságát tetszőleges mertékben növelni?"
azaz pl. úgy css-l 1,2 vagy 1,3 em, tehát nem teljes sortávolsággal/sorkihagyással, hanem annak csak egy részével.
Egyáltalán HTML-ben meg lehet ezt csinálni?Amúgy
Boldog Újévet Krivánok Neked (is)!Műanyag, alumínium és motoros redőnyök, valamint szúnyoghálók készítése, szerelése. www.szaboredony.hu
-
cidalain
veterán
válasz
martonx
#5265
üzenetére
Regen iszonyat mennyiseget szivtam IE miatt, de teny hogy mondjuk az IE9-tol kezdve nincs olyan nagy problema. Igaz mar tudok ugy css-t irni, hogy kapasbol jo legyen mindegyik bongeszon, max csak apro finomitasok kellenek utolag.
Viszont en meg azt varom, hogy a html 5 tamogatas legyen az osszesnel olyan mint a chrome alatt. Egy csomo javascriptet ki lehetne dobni ha pl IE alatt menne nehany extra urlapelem ugy mint a datumvalaszto, a csuszkas allito, a colorpicker.
Es a legjobb az lenne ha a kepeket a bongeszomotor nem csak osszetorzitana kis mereture, hanem tenylegesen lekicsinyitene mint a cheome pl.
[ Szerkesztve ]
>> GearBest Club Veszprém << >> https://www.facebook.com/gbc.veszprem <<
-
#5296
Sk8erPeter
nagyúr
martonx
#5295
Sk8erPeter
nagyúr
válasz
martonx
#5295
üzenetére
WordPress-ről most számomra ez egy időre elegendő volt:
http://prohardver.hu/tema/php_kerdesek_2/hsz_14945-14945.html
Sk8erPeter
-
#5311
Sk8erPeter
nagyúr
martonx
#5309
Sk8erPeter
nagyúr
válasz
martonx
#5309
üzenetére
"az adatbázis nem azért van, hogy fordítást tároljunk benne"
Bocs, de ez a vélemény szerintem ebben a formában teljesen értelmetlen. Mi az, hogy "nem azért van"? Miért ne lehetne "azért", amennyiben sokkal rugalmasabb fordítási és nyilvántartási módszereket biztosít az adott CMS (vagy keretrendszer, vagy teljesen mindegy, micsoda)? Ha épp arra van szükség, akkor adott esetben miért ne lehetne előnyösebb, mint fájlokat b@szogatni, minden egyes lekéréskor beolvasni, parse-olni, kikeresni a megfelelő elemet?
Fontos: mindkettő módszerre lehet találni érveket, de te lényegében leszögezted, hogy nem, csak az egyik módszer a helyes. Bocs, de most a válaszod inkább tűnt kötekedőnek és önigazolónak (hogy miért is jobb a WordPress, mint a Drupal, ha már azt választottad), mint előrevivőnek és érdeminek.
Korábban már leírtam, hogy a Drupalt a legapróbb részletekig le lehet fordítani, entitásszinten, field-szinten, blokkszinten, theme-szinten, modulszinten, mindennek nagyjából lehet tudni az első előfordulását is, vannak ezentúl fordítási csoportok is. Ha adatbázisban van tárolva, azért pár fokkal könnyebb karbantartani, és rugalmasabban kezelhető a dolog.
Másik: amikor az ÖSSZES fordításban keresgélek - amire van lehetőség Drupalban - akkor szerinted tényleg az lenne a legjobb, ha az adott esetben száz telepített modul (úgy, hogy egyes moduloknak lehetnek almoduljai, akár 10 almodulja is lehet, épp a modularitás jegyében, hogy azok kikapcsolhatóak legyenek), 3 smink, és a core fordítási fájlját is összekaparná, parse-olná, és kinyögné valahogy pár másodperc után a végeredményt, hogy melyik fájlban találom az adott stringrészletet? Azért azt hangsúlyozzuk: NEM egy XML-fájlról van szó, mint amiről te beszéltél. Ez amúgy nem is értem, honnan jött, hogy egy darab XML-ről beszéltél. Bár lehet, hogy a WordPress így oldja meg, bár én sehol nem láttam XML-t említve, feltételezném, WP-nél is pluginfüggő fordítások vannak; és amennyiben uninstallálsz egy plugint, akkor feltételezném, hogy annak a fordításai is mennek a kukába, hogy tök feleslegesen ne legyenek ott.
Amikor a fordítási felületre rámegyek, és több csoportosítási szempont szerint is láthatom a fordításokat - például hogy valamelyik elem a menühöz tartozik, valamelyik az entitásokhoz, meg a tököm tudja most a többit hirtelen fejből -, akkor mindegyik fájlból össze kéne kaparásznia a csoportosítási szempontoknak megfelelő adatokat? Ekkor is végig kellene rohannia a fájlokon (amiből ezek szerint lehet sokszáz - már ha össze nem pakolja egybe)? Oké, akkor erre most lehet jönni azzal, hogy hát a fájlokra is van mindenféle cache-elési módszer. Végül is azzal is lehet jönni, hogy de hát az adatbázis is fájlok formájában képzelendő el (ahogy sajnos az imént megtetted). De nem biztos, hogy ezek találó szempontok.
Lehet, hogy mérlegelni kellene, hogy a WordPress és a Drupal más jellegű CMS-ek. A Drupalban mindenféle menütípust, blokktípust, entitástípust, tartalomtípust, taxonómiát, és minden egyebet eleve létre lehet hozni, és mindezt le is lehet fordítani apró részletekig. Tudtommal ebből a szempontból a WordPress jóval kötöttebb. Lehet, hogy nem csak az az egyféle szempont létezik, amit mi a fejünkben egyszer elképzeltünk, lehet, hogy van más eset, mint amivel mi eddig találkoztunk."Ezek már miért ne lehetnének file-ban?"
És miért ne lehetnének adatbázisban?
Egy csomó szempontot fel lehet hozni mindkettőre. Továbbra is tök értelmetlen az egyiket egyértelmű győztesként kihozni. De mivel úgy tűnik, Drupal esetén az adatbázisszintű tárolás a jóval praktikusabb, ezért talán el lehetne fogadni, hogy lehet benne valami ráció, és hogy indokolt volt, hogy így találták ki, és nem szükséges az előfeltételezés, hogy biztos kretének dolgoztak a rendszer kitalálásán, akik nem értenek hozzá.
Amúgy gondolom nem csak hype-olásból hangsúlyozzák, hogy a CMS-ek között a Drupal többnyelvűsítési mechanizmusa nagyon rugalmas.
Persze biztos azt is csak hülye elfogult f@szok mondják."Egy xml-en végigrohanni semmivel nem tart tovább, mint elindítani húszszor egymás után, hogy select ize from forditas where key = valami. A húsz-al arra céloztam, hogy mondjuk 20 elem fordítását kell lekérdezni az oldal rendereléséhez. Sőt lehet hogy, az xml nyerne."
Adatbázisszintű cache is létezik. Durva, nem? Akár ha olyan van, ezt is le lehet kérni egyben is. Query cache is van, meg hasonlók."Ne tegyünk úgy, mintha az adatbázis valami csoda lenne. Az is file-ban tárolódik ugyanúgy a lemezen
"
Te most tényleg ekkora idiótának nézel, hogy úgy érezted, ezt ki kell hangsúlyozni? Azért reménykedtem, hogy ennél többre tartasz. Ez rosszabb, mintha simán csak lehülyéztél volna, de köszönöm, hogy elláttál ezzel a teljesen újszerű információval.
Bár egyébként sem értem, ez az érv hogyan lehet jelen esetben releváns, amikor teljesen máshogy működik egy adatbázis (még ha fájlok formájában is jelenik meg a háttértárolón (ami nem biztos, hogy lemez![;]](//cdn.rios.hu/dl/s/v1.gif)
)), mint a fájlnyitogatás, parse-olás. De mint említettem, van olyan is, hogy a fájlos módszer tűnik praktikusabbnak. Nem változtat semmit azon, hogy adott esetben meg az adatbázisszintű megoldás lehet az előnyösebb. Mint jelen esetben.
Igaz, én is elkövettem azt a hibát, hogy két, teljesen más felépítésű CMS megoldását vetettem össze.
De legalább senkit nem néztem hülyének.Sk8erPeter
-
#5317
Sk8erPeter
nagyúr
martonx
#5316
Sk8erPeter
nagyúr
válasz
martonx
#5316
üzenetére
Semmi gond, valószínűleg én értettem félre a szándékot, vagy reagáltam túl.
Ilyenkor szedni kell két adagnyi hangyát, és az ember megnyugszik.
"nem CMS-ben gondolkoztam, amikor írtam a felvetésemet, amivel igaziból csak arra akartam reflektálni, hogy abszolút nem lehet olyan magabiztossággal kijelenteni az adatbázisban tárolt fordításról, hogy az a jó megoldás, mint ahogy tetted"
Ebben teljesen igazad van, bocs, tényleg erőltettem egy darabig, hogy az adatbázis a mindenekfeletti megoldás, pedig ebben a formában nem igaz, később rájöttem. Rugalmasabbá teszi persze a karbantartást, több információ kapcsolható így a fordításokhoz (ahogy végül is Te is írtad)."Nyelvenként egy po file-t lehet nyitva tartani a jobb po editorokban, és keresni bennük a pillanatok műve."
Egy fájl esetében tényleg semmi gondot nem jelent. Mármint maga a keresés. A karbantartása már más kérdés (szerintem), de ezt mindjárt.
Tehát a fájlos megoldást sem szabad leszólni, én igazából csak azt nem láttam be, és még továbbra is kérdőjel maradt a fejemben, hogy valójában miért is ne lehetne arra is használni az adatbázist, hogy fordításokat tároljunk benne (amire utaltál), miért nagyobb gond az, ha adatbázisból kérjük le a fordításokat, akár egyben, még ha nem is kell hozzácsatolni valami plusz információkat (lásd Drupal, összetettebb információhalmaz), valami összepakolt cache-ből, mintha egyetlen nagydarab fájlból.
Bár az egyetlen nagydarab fájlnak a modularitás továbbra is ellentmond (és végül is modul nem csak CMS-ben lehet), hiszen az elvileg azt kívánná meg, hogy akár modulonkénti külön fájlokból álljon össze egy fordítás; igaz, ezt is meg lehet kerülni úgy, hogy "aggregáljuk" a fordításokat egyetlen nagy fájlba, a modul telepítésekor egyszerűen hozzáfűzzük annak a fordításait. Csak kérdés - és többek közt itt jön elő a karbantartási probléma -, akkor az egyik modul törlésekor mi legyen. Keressük meg a megfelelő részeket, és azokat töröljük ki a fájlból, mert a törölt modul fordításai már feleslegessé váltak? Elvileg így lenne helyes, de akkor ez a karbantartást picit megint nehézkesebbé teszi - könnyebbnek tűnik legalábbis adatbázisból megkeresni adott kulcs mentén adott modulhoz tartozó fordításokat, majd azokat kidobni, mint egy nagy .po-fájlon végigrohangászni, és tudni, hol van a modulok fordításának eleje, majd vége. Kérdés, hogyan tartjuk nyilván, hogy a modul fordításai hol kezdődnek? Vagy akkor modul törlésekor gyártsuk le ismét az összepakolt fordítási fájlt? Na de az nem jó, mert azóta a nagy fájlban végezhettünk módosításokat. Szóval marad az előbbi, hogy meg kell keresni az elejét, meg a végét. Persze lehet, hogy ez a ritkább eset, amivel nem kell annyira foglalkozni, de modularitás esetén engem zavarna, hogy nem szükséges fordítások is szükségtelenül növelik a fájlméretet. Meg biztos van még valami szempont, de most csak ez jutott hirtelen eszembe.Engem legalábbis érdekel a téma, jó néha véleményeket ütköztetni, szóval még körbe tudjuk járni másképpen is.
[ Szerkesztve ]
Sk8erPeter
-
#5341
Sk8erPeter
nagyúr
martonx
#5318
Sk8erPeter
nagyúr
válasz
martonx
#5318
üzenetére
"Admin felületről lehet fordítgatni benne a cuccokat, egész korrektül megcsinálták. CMS-hez talán tényleg ez a megoldás a legjobb, mivel amúgy is minden content az utolsó betűig az adatbázisban van. Ha már úgyis adatbázis kell a legkisebb hello world-höz is, akkor kézenfekvő, hogy egyúttal onnan rögtön a nyelvnek megfelelő szöveget vegye ki a rendszer."
Igen, én is pont így gondoltam korábban, ami CMS esetén ellentmond annak az érvnek, hogy az adatbázis ne lenne erre való.
Ha épp az kell, akkor arra való."Szvsz teljesen normális 1-1 pár száz kb-os, folyamatosan használatban lévő file tartalmát memóriában tartani, de szerintem azokat megnyitogatni és realtime olvasni is minimális idő."
Na ja, ez lehet, korábban arra utaltam, hogy amennyiben a modularitást vesszük elő (lásd CMS), akkor esélyes, hogy nem csak egy fájlban lesznek tárolva a fordítások. Vagy ha igen, akkor feláldozzuk a modularitást. Viszont ha már nagyon sok fájlt kell megnyitva tartani (pl. 100 modul), és sok fájlt is kell update-elni, megnyitogatni az oldallekéréskor minden apró elemhez, akkor már nem járunk jól, és akkor már a fájlbeli kotrás teljesítménye nem olyan meggyőző. Igaz, cache-szerűség érdekében le lehet akár generálni egy fájlba is különböző feltételektől függően, vagy adatbázisban, cache-táblában tárolni valami bejegyzés alatt a megfelelő fordításokat. Nem tudom, itt melyik megoldás nyer sebességben/erőforrás-igényben/más tekintetben, de mindkettő megoldás mellett szólhatnak érvek.Egyébként a fájlkezelés oprendszer-szinten költséges művelet, erre akartam célozni, persze abban igazad van, hogy talán nem mérhető össze az adatbázishoz kapcsolódás, lekérés költségével, főleg, ha az adatbázis másik szerveren van...
"Másrészt vegyük észre, hogy a hoszting cégeknél a sima lemez kapacitás jellemzően több, mint az SQL tárhely. Sőt felhőben hosztingolva pl. a lemez kapacitás szó szerint szinte ingyen van, míg az SQL-es adattárolásnál azért zsebbe kell nyúlni."
Ez mondjuk jó szempont.
Bár itt fordításokról beszélünk, nem brutális adatmennyiségekről, igaz, ha a fordítások különböző relációban állnak egymással, és az fontos, akkor nőhet a mennyiség szép lassan, de akkor meg úgyis az adatbázis a jobb megoldás elvileg.Na de tényleg összegezhetjük annyiban, hogy mindig attól függ, mit használunk, egyik megoldás sem nevezhető szarnak.
Most már tényleg jól körbejártuk a témát.Sk8erPeter
-
cidalain
veterán
válasz
martonx
#5438
üzenetére
szerintem a rendszer mappájának nincs köze a webszerver rendszer mappájához.
én úgy értettem hogy az ő rendszer mappája, egy olyan mappa ahol a weboldalon megjelenő képeket, esetleg scriptfájlokat tároljaén valami htaccess-ben gondolkoznék.
másrészt nem iratnám ki hogy nincs ott semmi látnivaló, mert ezzel figyelemfelhívsz.az emberek nem fognak oda eljutni, mert nincs oda link. aki meg forráskódot elemez, és az alapján eljut "rendszer" mappákhoz, az meg ugyis eljut amúgy is. ha a rendszer mappádba olyan fájlok vannak amik kellenek a weboldalad működéséhez, akkor felesleges levédeni, mert aki meg akarja szerezni az meg tudja hisz a fájlokat használod, az összesnek ott az elérési útja a forráskódban.
[ Szerkesztve ]
>> GearBest Club Veszprém << >> https://www.facebook.com/gbc.veszprem <<
-
#5453
Sk8erPeter
nagyúr
martonx
#5452
Sk8erPeter
nagyúr
válasz
martonx
#5452
üzenetére
Na ja, ebben teljesen igazad van, hogy már eleve a webszerver alapbeállításai kellene, hogy tartalmazzák az erre vonatkozó opciókat. Az a rész ebben a formában tényleg nem igaz, hogy a fejlesztő szarakodjon ilyesmivel .htaccess-ben vagy másképp, az igazából már a kényszermegoldás, amikor mondjuk van egy szarabb osztott/egyéb tárhely, amihez kénytelen igazodni a fejlesztő, mert mondjuk a megrendelő vagy a Gizike néni ahhoz ragaszkodott. Vagy mert a rendszergazda egy kretén.
[ Szerkesztve ]
Sk8erPeter
-
Yilderim
újonc
válasz
martonx
#5452
üzenetére
Erre válaszolok, de egyúttal mindenkinek köszönöm a hozzászólásokat a témához...
A szerver beállításaihoz
a) sajnos nem értek
b) nem is kaptam információt róla, hol lehetne az én jogosultságaimmal bármit állítani.A konkrét helyzet a következő <user>.web.elte.hu címre tárhelyet igényelhetünk ELTE-hallgatókként, azonban támogatás nem igazán jár a dologhoz, egyszerűen WinSCP kapcsolaton keresztül egy mappába tudunk anyagot feltölteni, de az itteni (esetlegesen létrehozott) almappák tartalmát automatikusan kilistázzák a böngészők, szóval jelen lehetőségeim függvényében szeretném az elrejtős index.html-t használni...
(A mappában egyébként nem csak olyan képek vannak, amik konkrétan linkelve vannak a weblapon, hanem pl. egyetemi beadandó feladatok is, amik ott fontosak voltak, hogy a webszerverre kerüljenek fel, de nem részei a mostani publikus tartalomnak...)
Szóval, a kérdés a technikai részre visszakanyarodva az lenne:
mi lehet az oka, hogy nem működik az átirányítás?
Ha egy kattintható linkre teszek javascriptes visszalépést, az önmagában működik;
illetve önmagában (rendes url beírásával) az átirányítás is rendben;
miért ütik egymást? -
#5488
Sk8erPeter
nagyúr
martonx
#5487
Sk8erPeter
nagyúr
válasz
martonx
#5487
üzenetére
Hát ja, igazából ebben nehéz újat mondani, hogy mindkettőnek vannak előnyei-hátrányai, és azt mérlegelni kell. Ha a teljesítmény-szempontok kritikusak, akkor valószínű, hogy kevésbé éri meg a CMS, persze ez is attól függ, a gyorsítótárazással kapcsolatos tudást is fejlesztik. Általános lesajnálás övezi sokszor a CMS-eket, ha komolyabb projektről van szó, ennek sok oka van, egy része teljesen jogos, másik része nem az.
Amit én kódszinten komoly problémának látok, hogy a visszafelé kompatibilitás kényszere miatt a PHP-alapú CMS-ek kódja sokszor a PHP 4-es időszakból visszamaradt tákolmányok korhoz igazítgatásával, toldozásával-foldozásával van tele, meg a procedurális kódolás erőltetésével, immár kutyulva az objektumorientáltsággal. Sajnos ez alól nem kivétel a Drupal sem, még ha ez a komolyan vehető CMS-ek közé tartozik is. Ez szerintem gáz, én inkább örülnék egy radikális váltásnak két főverzió között, még ha sok is lenne az anyázás, hogy nehéz portolni az új verzióra a modulokat.
Probléma az is, hogy sokszor inkompetens emberek készítenek tutorialokat, screencasteket (mondjuk ez a PHP-s világra sajnos különösen jellemző, hogy boldog-boldogtalan nekiesik, mint tót az anyjának).
Probléma továbbá sokszor az is, hogy - amennyiben komolyan vehető CMS-ről van szó - muszáj tényleg sok időt beleölni a CMS fejlesztésének tanulásába, különben kellő ismeretek híján csak billentyűzet-csapkodós, facepalmos módon tudja az ember megoldani a problémát. Szóval sokszor egyszerűen a kellő ismeret hiányzik ahhoz, hogy rájöjjön az ember, hogy lehet értelmesen megoldani egy problémát. Amikor pár éve melóhelyen volt egy projekt, akkor annyi volt a megkötés, hogy CMS-t használva legyen kialakítva az oldal - én a netes, értelmesen, programozói szemszögből is megközelített vélemények alapján választottam a Drupalt. Sokan dicsérték a jól kialakított, könnyen kezelhető jogosultságkezelést, az elég általános mezőzhetőséget, tartalomtípusokat, viszonylag értelmes bővíthetőséget, stb. Fogalmam nem volt még az egészről, jó kis beletanulási időszak volt, aztán kb. 1,5 hónap múlva majdnem úgy döntöttem, hogy abbahagyom az egészet a francba, és megcsinálom ugyanezt tök máshogy. Egyszerűen a tököm ki volt vele. De ez még a 6-os verzió idején volt (most a 8-as lesz idén vmikor stabil), azóta rengeteget fejlődött a Drupal, plusz akkor aztán találtam egy normális könyvet, ahol végre értelmesen volt leírva, hogyan is kell egy rohadt modult relatíve jól fejleszteni. Még a hivatalos anyagokat sem találtam ilyen szempontból kielégítőnek. Aztán később, amikor már belejöttem, láttam, mennyire egyszerűen is meg lehetett volna oldani mindezt, főleg a 7-es után... a két verzió között szerintem igen látványos különbségek vannak.
Aztán nyilván megköti a fejlesztő kezét az is, hogy alkalmazkodni kell a CMS fejlesztői által kitalált moduláris struktúrához. Persze a framework API-jához is igazodni kell, ott sem lehet csak rászabadulni, mint egy vadbarom, azt is hosszú időn keresztül kell tanulni.Igazából mind a CMS, mind a framework esetén könnyű elérkezni egy ponthoz, ahol az egyik röhögve lehagyná a másikat - pl. CMS esetén lehet mondani, hogy háhh, ehhez csak kattintanék hármat, vagy erre csak felraknám az XY modult, és kész lennék, esetleg modulból meghívnám az API akármilyen függvényét; aztán frameworknél meg lehet mondani, hogy "ne szívassál már, ezt három sorból megoldom, amivel te itt most szarakodsz".
Szóval ez a kérdés megoldatlan marad. És akkor a kötelező panelszöveg: mindenki használja azt, amit szeret, amit megkövetel a főnök, vagy ami alkalmasabb az adott feladatra. 
[ Szerkesztve ]
Sk8erPeter
-
#5503
csabyka666
addikt
martonx
#5502
csabyka666
addikt
válasz
martonx
#5502
üzenetére
Úgy volt ezelőtt, de ha az oldalt nagyítottam (vagy mobilon néztem), akkor összecsúsztak a menük. Persze biztos ki lehet ezt is védeni valahogy, de most a táblázattal ez az összecsúszás nem jön elő.
Ágdarálást, kaszálást, területtisztítást vállalok profi gépekkel! Elsősorban Zala megye és vonzáskörzete, de minden megkeresést meghallgatok. +36305633091
-
#5559
haromegesz14
aktív tag
martonx
#5558
haromegesz14
aktív tag
válasz
martonx
#5558
üzenetére
Oldalukon található dokumentációval próbálkoztam, sajnos foghíjas angoltudásomnak köszönhetően kifogott rajtam.
Ő lenne az, remélem működik a link.
Továbbá szeretném kérni azt, hogy minden mástól tekintsünk most el, hogy mennyire valid vagy sem, és egyéb orbitális webszerkesztéses hibáktól, csak koncentráljunk a Grid System-re. Köszönöm!
Suliba volt feladat, de sajnos ezzel nem boldogultam.[ Szerkesztve ]
10 féle ember létezik, aki ismeri a bináris számrendszert, és aki nem!
-
#5595
Sk8erPeter
nagyúr
martonx
#5594
Sk8erPeter
nagyúr
válasz
martonx
#5594
üzenetére
Nem-nem!
Itt egy szemléltető példa, hogy az inline style-t felül lehet bírálni !important kulcsszóval, ergo az !important kulcsszónál csak egy másik, a stílusok között később szereplő, azonos elemre vonatkozó (vagy akár specifikusabb) !important kulcsszóval megadott stílus lehet erősebb. --> http://jsbin.com/pexulozi/1/edit(#5593) Agostino :
Hát igen, rossz megoldás, de van ilyen. Most sajna ehhez alkalmazkodva kell felülbírálnod a stílust kliensoldalon.
A fentebb belinkelt példa továbbfejlesztése két divvel, nth-child használatával (ami kényszermegoldás, de most a "Copy CSS path" segítségével ezt tudod tenni kb.):
http://jsbin.com/pexulozi/2/editSk8erPeter
-
#5597
Sk8erPeter
nagyúr
martonx
#5596
Sk8erPeter
nagyúr
válasz
martonx
#5596
üzenetére
Plusz a Weblapkészítés topicban már többször linkelt Star Wars CSS Specificity Wars talán a legbeszédesebb gyorspuska (még ha az !important külön nincs is részletezve (bár kommentekben megtalálható)):
[ Szerkesztve ]
Sk8erPeter
-
#5610
Sk8erPeter
nagyúr
martonx
#5603
Sk8erPeter
nagyúr
válasz
martonx
#5603
üzenetére
Jaja, az csak egy összefoglaló a selector-erősorrendről, szóval a kettő együtt lehet érdekes. Mondjuk a style-meghatározás sorrendjében látszó különbséget végül is az ember úgyis megjegyzi. És ja, az !important alapvetően egy gányolás, és az tényleg ilyen végső kényszerhelyzetben lehet érdekes, mint amilyet Agostino írt.
Amikor !important stílussal felüldefiniált stílust kell !important kulcsszóval felüldefiniálni, az a legalja.(#5601) biker:
Tanulságos
A következtetés az lehet belőle, hogy még ha a felhasználóink hirdetéseket adhatnak is fel az általunk fejlesztett oldalon, ne készítsünk olyan alkönyvtárat/aliast, amit kiszűrhet az AdBlock, pl. épp az "adverts" ezek szerint nem szerencsés.Sk8erPeter
-
cidalain
veterán
válasz
martonx
#5651
üzenetére
mivel a dobozok egyformák kinézetre de egyedi tartalmat tárolnak, miért ne oszthatnék nekik egyedi id-t?
(es ehhez miért ne kapcsolhatnék max 1-2 egyedi extra stílusformázást?)van valami oka annak hogy az id osztással spórolnom kellene?
miért gondolod elpazarolásnak: ha valami javascripttel akármivel szerertnék rá hivatkozni akkor ugyanugy tudok. ha meg csak a stílus miatt használom bizonyos esetekben akkor sem okoz hátrányt.nem baszakodásképpen de komolyan érdekel, hogy
a id="milyen" class="doboz" és a class="milyen doboz" között hordoz e valamelyik előnyt/hátrányt, és mi lenne az[ Szerkesztve ]
>> GearBest Club Veszprém << >> https://www.facebook.com/gbc.veszprem <<
-
biker
nagyúr
válasz
martonx
#5699
üzenetére
majdnem megvagyok, csak a hülye dropdown menü néha megbolondul, és nem azt nyitja le amit kellene
és nem jövök rá, de már ideggörcsöt kapok.Elektromos autó töltő berendezések | Mesterséges növényvilágítás | Mai ajánlatunk: www.gerisoft.hu | www.e-autotoltokabel.hu | www.agrar-vilagitas.hu |
-
pecze
aktív tag
válasz
martonx
#5789
üzenetére
de, ajaxosból egy részlet (infoszerk.inc.php), van előtte adatbázis felépítés, meg get-el az eredeti fájlból adtam át neki egy id értéket
Itt a meghívó kód is, hátha ez segít eligazodni benne, ez előtt van a tinymce init rész:
<script>
function betoltes(uzenet) {
if (window.XMLHttpRequest)
{
xmlhttp = new XMLHttpRequest();
}
else
{
xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
}
if ( uzenet == 1 ) {
xmlhttp.onreadystatechange = function() {
if (xmlhttp.readyState == 4 && xmlhttp.status == 200) {
document.getElementById('mod').innerHTML = xmlhttp.responseText;
}
}
var e = document.getElementById("selectmodosito");
var selectertek = e.options[e.selectedIndex].value;
var filename = 'inc/infoszerk.inc.php?id=' + selectertek;
}
if ( uzenet == 2 ) {
xmlhttp.onreadystatechange = function() {
if (xmlhttp.readyState == 4 && xmlhttp.status == 200) {
document.getElementById('torlo').innerHTML = xmlhttp.responseText;
}
}
var e = document.getElementById("selecttorlo");
var selectertek = e.options[e.selectedIndex].value;
var filename = 'inc/infotorlo.inc.php?id=' + selectertek;
}
xmlhttp.open('GET', filename, true);
xmlhttp.send();
}
</script>Itt meg a meghívás:
<select class="form-control" id="selectmodosito">
<?php
$query = "SELECT id FROM informaciok";
$result = mysqli_query($dbc,$query);
while ( $row = mysqli_fetch_array($result)) {
echo "<option value=" . $row['id'] . ">" . $row['id'] . "</option>";
}
$close = mysqli_close($dbc);
?>
</select>
<button type="submit" class="btn btn-default" onclick="betoltes(1)">Küldés</button>
<div id="mod"></div>[ Szerkesztve ]
-
pecze
aktív tag
válasz
martonx
#5791
üzenetére
ok és hogy oldható meg, mert már mindenhová áthelyezgettem, írtam külön classra vonatkozó initeket is, beleraktam a meghívást a infoszerk.inc.php-be, amit az ajax meghív, beleraktam függvénybe, amit meghívok a textarea betöltésekor, de semmi.
jelenleg épp átírom, hogy ne ajaxal jelenítse meg, de ha valakinek van ötlete a megoldásra azért jelezze. -
-
#5853
huliganboy
addikt
martonx
#5852
huliganboy
addikt
válasz
martonx
#5852
üzenetére
Szia!
Letöltöttem egy hover effektet amibe beleszerkesztettem egy fancybox megjelenítést. A gépemen tökéletesen működik, őt ha felrakom szerverre és meghívom a html-t közvetlenül akkor is..... de ha beillesztem a joomla oldalba akkor a fancybox nem működik... csak megjelenik a kép a böngészőablakban nem pedig felugróként.
Elvileg az oldalon lévő slider-el akad össze......
-
pumatom
aktív tag
válasz
martonx
#5856
üzenetére
Szia!
8-as IE-rel van a probléma.
Lehet igazad van, viszont a felhasználók szemszögéből nézve jó ha működik, mert amúgy nem tudnak használni bizonyos elemeket, és nem utasíthatom arra őket, hogy frissítsék a böngészőjüket.
Ellenben marha idegesítő, hogy minden jól működik az összes egyéb böngészőn, de persze az IE-n nem.
Ezt a modernizr js megnézem, már láttam ebben a témában.
Köszönöm, hogy írtál!
)
) és PumpkinSeed közölték, hogy ők jól megvannak a localhostos teszteléssel:
ezt ezzel 
"![;]](http://cdn.rios.hu/dl/s/v1.gif)
)), mint a fájlnyitogatás, parse-olás. De mint említettem, van olyan is, hogy a fájlos módszer tűnik praktikusabbnak. Nem változtat semmit azon, hogy adott esetben meg az adatbázisszintű megoldás lehet az előnyösebb. Mint jelen esetben.
Új hozzászólás Aktív témák
- Elemlámpa, zseblámpa
- Xiaomi 13T és 13T Pro - nincs tétlenkedés
- Futás, futópályák
- Robogó, kismotor
- Kávé kezdőknek - amatőr koffeinisták anonim klubja
- Autós topik látogatók beszélgetős, offolós topikja
- Debrecen és környéke adok-veszek-beszélgetek
- Milyen alaplapot vegyek?
- Samsung Galaxy A54 - türelemjáték
- Luck Dragon: Asszociációs játék. :)
- További aktív témák...
