Új hozzászólás Aktív témák
-
#6632
Highground
aktív tag
martonx
#6631
Highground
aktív tag
válasz
martonx
#6631
üzenetére
A facebookon igen
De mi arra lennénk kíváncsiak, hogy van-e értelme egyáltalán fenntartani a weboldalt (nem a facebookos oldalt). Mert ha igen, akkor (mivel régi) újat kellene csinálni. Csak ha már csinálnánk, akkor úgy vagyunk vele, hogy valami modernet, szépet grafikusat kellene. De ahhoz meg valószínűleg zsebbe kell nyúlni. Ez egy non-profit, sőt kiemelten közhasznú egyesületnél nem olyan egyszerű Ezért rohadtul biztosra kell menni, hogy nem dobunk ki az ablakon feleslegesen mondjuk 20.000-et egy jobb minőségű Wordpress weblapsablonra. (egyikünk sem grafikus vagy designer... sajnos.) -
#6564
MasterMark
titán
martonx
#6559
MasterMark
titán
válasz
martonx
#6559
üzenetére
Köszi, gondoltam.
más: Annyi kérdésem lenne még, hogy valahol láttam, hogy lehet CSS-ben attól függően is formázni, hogy a mekkora a megjelenítési felbontás.
Van egy táblázat az oldalon, alapból 75% szélesen, de azt szeretném, ha mondjuk 1024-nél kisebb a szélesség, akkor 100% legyen.
Nem tudom már hol láttam, de elsőre nem tűnt olyan bonyolultnak.
-
xTREem
tag
válasz
martonx
#6530
üzenetére
Próbálom másképp fogalmazni:
Szeretnék egy összesen 1 oldalas ismertető jellegű weboldalt néhány képpel, kevés szöveggel és zéró interrakcióval, semmi többet.
Nem szeretnék MySQL-lel, Apache-al és PHP verziókkal foglalkozni, és nem szeretnék szövegszerkesztővel html kódokat pötyögtetni, tutorialokat olvasgatni.Keresek egy olyasmi szerkesztőt, mint például a Yahoo SiteBuilder, aminek egy baja van, hogy csak Yahoo-s oldalra lehet feltenni az elészült anyagot.
Aki tud, légyszi' segítsen, köszi!
-
Zedz
addikt
válasz
martonx
#6487
üzenetére
Jajj bocs, igazad van.
Munkahelyen PHP a sláger, de szerintem találtam egy aránylag használható dolgot itt. Még nem próbáltam ki, de ahogy böngészőben tesztelgettem, úgy nem volt rossz. A Laravelnek is elvileg van sajátja, max arra is ránézek még.ASP-nál akkor az elég kényelmes, szívesen kipróbálnám éles projekteken is, csak itt nem nagyon van támogatója...
NodeJs-re sajnos nincs elég időm, pedig érdekes dolgok vannak arra felé. Ha jól tudom ismét egyesül a NodeJs és iojs. -
Zedz
addikt
válasz
martonx
#6465
üzenetére
Lehet rájött ez a szakma nem neki való.
Neki is jobb, nekünk is. 
Szerk.: ha már mobil nézet. Ha struktúrabéli különbségek vannak az oldalon, mondjuk más a menü, a footerben helyet cserélnek elemek, ilyenek, akkor azt hogy érdemes megoldani? Az m.xyz.com nyilván nem játszik, media queryvel pedig ilyenkor nem lehet szórakozni. Wat to do?
-
#6376
Sk8erPeter
nagyúr
martonx
#6374
Sk8erPeter
nagyúr
válasz
martonx
#6374
üzenetére
Én IE-ben is átállítottam az alapértelmezett keresőt a Bingről Google-re.
Mert a Bing az én keresgéléseim alapján sokkal rosszabb keresési találatokat adott a legtöbb kulcsszóra, persze ebben nyilván szerepet játszik az is, hogy a Google-be be vagyok jelentkezve, és korábbi kereséseim alapján kotor ki releváns találatokat. Igaz, próbáltam már inkognitó módban is, akkor is érdekes módon rosszabb eredményeket kaptam - általánosítani mondjuk az alapján annyi tapasztalatból, ami nekem van a Binggel, nem érdemes, de én egyáltalán nem használom a Binget épp a korábbi tapasztalatok miatt. Aztán biztos van olyan is, aki meg a Binggel elégedettebb. 
-
Zedz
addikt
válasz
martonx
#6374
üzenetére
Azt hiszem egy NFL közvetítésben történt az, hogy a riportereknek adott MS Surface tabletet reflexből le iPadezték, majd mondták MS-ék, hogy ezt nem kellene mert nem tesz jót a reklámnak.
A bing-et én egy időben próbálgattam, ha másért nem a szép képekért érdemes volt minden nap meglátogatni. Aztán rátaláltam erre.
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
#6370
Sk8erPeter
nagyúr
martonx
#6369
Sk8erPeter
nagyúr
válasz
martonx
#6369
üzenetére
Hát ja, ebben teljesen igazad van, tulajdonképpen helyette töltöttem el vele időt, én hülye.
De amúgy észrevettem, hogy emberek hihetetlen, mennyire nem tudják jól használni a Google-t (sem), egyszerűen nem tudják beírni a megfelelő keresőszavakat, amikkel az igazán releváns találatokhoz nagy eséllyel el tudnak jutni, vagy azt gondolják, hogy az első 5 találatban mindig minden benne lesz. Vagy csak lusták. Egyik sem jó. -
Vikus
tag
válasz
martonx
#6265
üzenetére
Hogy szemléltessem:
http://www.kephost.com/image/1d5
A lényege, hogy a kép felső részén, ahogy írnám be a betűt, akkor meg is találja azokat a neveket, amik adott linkre vinnének. (csak éppen a háttérben totál átlátszó..stb.)
A kép alsó részén pedig ugyanez van, annyi a különbség, hogy a body részbe írt
<form id="tfnewsearch" method="get" action="livesearch.php">
<input class="tftextinput" type="text" name="q" size="21" maxlength="120" onClick="this.value='';" onFocus="this.select()" onkeyup="showResult(this.value)" value="keresés..."><input type="submit" value="keresés" class="tfbutton">
<div id="livesearch"></div>
</form>name="q" <-- be van biggyesztve és emiatt mindenféle más szó, amit használtam más oldalakon is megjelenik, mögötte meg az, amit szeretnék láttatni és persze egy "lenyíló panelben".
Igazából ezt kellene valahogy úgy összehozni, hogy amit az "adatbázisban" szeretnék keresni, azokat mutassa csak, és látható is legyen, ne úgy, mint itt.. Már filóztam rajta, az is lehet, hogy a script-en belül kéne valamit mókányolni, de mivel nem vágom, ezért kérek segítséget.
Az oldalt nem tudom belinkelni, de egyébként felesleges is lenne, mert egy az egyben ugyanaz van mindenhol, mint itt: http://www.w3schools.com/php/php_ajax_livesearch.asp
-
#6254
Sk8erPeter
nagyúr
martonx
#6251
Sk8erPeter
nagyúr
válasz
martonx
#6251
üzenetére
Alapvetően egyetértek, de amíg azt sem tudja, hogy kell elküldeni magától egy levelet, addig szerintem először próbálja ki. Aztán ha ezt már elsajátította, tudni fogja értékelni az ilyen jellegűeket is. (Vagy nem, az már az ő dolga.
) Amúgy a MailChimp tényleg fasza (a SendGridet még nem használtam).(#6252) Zedz:
"És milyen előnye van még ennek mondjuk egy Swiftmailer vagy PHPmaillel szemben? Mert így elsőre plussz egy körnek tűnik az API-t meghívni külsős szerverről."
Az az előnye, hogy neked nem is kell foglalkoznod magával az email-küldéssel, meg a mindenféle kapcsolódó tevékenységekkel (mint pl. a levél elküldésének sikeressége, illetve a levél hatékonyságának elemzése különböző módszerekkel). Egyszerűen átpasszolod az üzenetet egy levélküldő szolgáltatásnak, az elintézi a többit; felhasználhatsz template-et is, küldhetsz nagy mennyiségben, adott esetben ezek ütemezett küldözgetését is megoldja, a levél nagy eséllyel nem fog a felhasználóknál a spambe kerülni, PLUSZ ami nagyon hasznos lehet, hogy statisztikákat készít arról, hogy a felhasználóknak milyen szokásai vannak a leveleid olvasása kapcsán, mondjuk a levélben milyen gombra kattint rá, mit sikerült figyelem-felkeltővé tenni, mi az, amivel a felhasználóid egyáltalán nem foglalkoztak, tehát az a rész a levél sablonjában mondjuk szarul sikerült, azon javítani kéne, és így tovább...
Csomó következtetést le lehet ezekből vonni, és nem neked kell mindezt kézzel, mindenféle saját megoldásokkal, esetleg library-k felhasználásával megoldanod, hanem ezt a feladatot a szolgáltató (mint pl. a MailChimp) elvégzi. Az ingyenes változatával is egész sok levelet lehet küldeni, persze a nagyobb csomagok már fizetősek, de megtérülhet.
Ja, és kapsz mindehhez egy jól áttekinthető webes felületet (ahol pl. a sablonokat is létrehozhatod, meg elemezheted a tömegesen kiküldött (hír)leveleket), meg egy normális API-t. -
r6man123
senior tag
válasz
martonx
#6227
üzenetére
A videokártya HW-val nem lehet gond, a probléma inkább szoftveres szvsz, ezért is vagyok meglőve, mert nem tudom, hogy egyedi hiba-e vagy van több olyan kártya / oprendszer / Firefox kombó, aminél ilyen hiba előjöhet. Amúgy egy AMD Radeon HD 7800 kártyám van W8-al, legújabb FF-el és naprakész driverekkel. A hiba FF frissítés után jött elő.
-
cidalain
veterán
válasz
martonx
#6128
üzenetére
Értem, köszönöm.
Igazából most tökmindegy nekem hogy mit rakok össze PHP-val, kb ugyanannyira egyszerű egy XML meg egy JSON outputot is elkészíteni.
Hallottam már a JSON-ról korábban is, de valahogy eszembe sem jutott ez az opció most, automatikusan az XML ugrott be. Közben persze most én is elkezdem utánanézni, és több az előnye ha ilyet használnék. Nem tudom miért nem promózzák ezt jobban... (vagy csak én nem forgatom elég mélyen a szakirodalmat?) -
#6092
Sk8erPeter
nagyúr
martonx
#6090
Sk8erPeter
nagyúr
válasz
martonx
#6090
üzenetére
Az állandó igénytelensége és helyesírási hibái egy dolog, de jelen esetben nem kifejezetten csak erre hívtam fel a figyelmet, hanem azzal kezdtem, hogy tiszteljen már meg minket egy HTML-szerkesztésről szóló fórumon azzal, hogy megtanulja, hogyan kell egy URL-t link formájában beilleszteni, magyarul használja a Link gombot.
Nem tudom, miért csak az a része jött át, hogy cseszegetem a helyesírás miatt. Ezeket a dolgokat azért nem tudom megérteni, mert összesen 1149 hozzászólás után, amennyi a srácnak jelenleg van (összeadva a szakmai+közösségi+piaci+blogok/lokál hsz.-eket), fel nem fogom, hogy nem jött rá még ezekre a dolgokra külön rászólás nélkül. Hogy?? Én is voltam kezdő ezen a fórumon, de pár hozzászólás után rájöttem, mit hogy tudok itt használni. Nem azért, mert hű de rohadt ügyes vagyok, hanem azért, mert ez alapszint. Zavaró, amikor minden apró-cseprő szarságért szólni kell. Az ember amikor épp agypihentetős perceiben úgy gondolja, hogy megnézi, mi a helyzet a fórumon, esetleg segít, akkor nem az ilyen alapvető igénytelenséggel akar foglalkozni - sőt, ez inkább elveszi a lendületet a nagy segítési kedve során.
Ja, és amúgy kb. lesz@rnám, hogy nem használ ékezetes betűket, mert más is teszi (hozzáteszem, sosem értettem, miért szopatja magát és másokat valaki ilyennel, amikor mondjuk itthon él, és lehet venni magyar billentyűzetet/billentyűzetmatricát/...), .de amikor összeadódik a sok minden, akkor beszólhatnékom támad.
(De úgy általában a válaszaira adott reakciókból is ítélve nem csak én vagyok vele így.)================================
(#6087) honda 1993 :
Félreértetted, nem a billentyűzettel és ékezetek hiányával van a baj (bár számomra az is zavaró tud lenni, de ez a mellékes része), hanem azzal, hogy nem használsz alapvető dolgokat, mint a Link gomb, emellett igénytelenül, csetszerűen írsz. De mindegy, inkább hagyjuk a témát, térjünk vissza a szakmai vonalra. Szóval nem kell mobilról írni ettől még, hogy tudj használni ékezeteket! (mondjuk ezt nem is értem, át is állíthatnád a bill. kiosztást... )
Na jó, még egy: szabad megkérdezni, milyen billentyűzet? (márka+típus) Csak kíváncsiságból. -
#6091
honda 1993
senior tag
martonx
#6090
honda 1993
senior tag
válasz
martonx
#6090
üzenetére
hmmm. értem.
Most hogy visszaolvastam az elozo hozzászólásomat, vettem csak észre hogy egy csomószor el is írtam egy egy betut.
(Ennek az az oka hogy telefonról írtam és észre sem vettem)
Ha tenyleg olyan zavaro hogy nem hasznalok ekezeteket, akkor valtoztatok rajta, de nekem meg baromira sokaig tart igy egyetlen mondatot is leirni.
-
biker
nagyúr
válasz
martonx
#6054
üzenetére
Szvsz pont a webfejlesztő az egyik legnehezebb programozás irány, mert kenni-vágni kell a html-t, css, js-t, minimum egy szerver oldali nyelvet, és minimum egy sql típust (mssql, oracle, postgre, mysql, nosql variánsok stb...).
és évente 2x újratanulni valamelyiket mert jön az új verzió
-
cidalain
veterán
válasz
martonx
#6054
üzenetére
Hat jo, nyilvan lehet ezzel is sokat keresni, mindennel lehet. De ahhoz tudni kell rendesen, es olyan tudas nem jon egy tanfolyambol, egyetemi oktatasbol. Raadasul amig nem tettel le semmit az asztalra, csak a szomszed kisbolt weblapjat, addig nem is jon a nagy penz. Ilyen fizeteshez ki kell jarni a szamarletrat, projektvezetokent, senior fejlesztokenttudom elkepzelni ezt a zsozsot amit irtal. Egy kezdo webfejleszto biztos hogy alacsonyabban kezd fizetesben mint mondjuk egy c, c++, java fejleszto, vagy ami most meno android/ios fejleszto.
-
DNReNTi
őstag
-
Jim-Y
veterán
válasz
martonx
#5963
üzenetére
Ugye tudod, hogy ez azert nem volt profi hozzaszolas, meg ha ironikus is volt, akkor sem, pl Honda tuti komolyan veszi
itt is fel lehet venni a listaba a css-t is, es onnantol kezdve az is benne lesz a listaban, templatet is meg lehet adni ugyanott a fajloknak. Annyi, hogy a keszitok a css-nek nem csinaltak "gyorsinditot". -
#5953
honda 1993
senior tag
martonx
#5951
honda 1993
senior tag
válasz
martonx
#5951
üzenetére
Amikor htmlt ir az ember akkor kivalasztja a html-t.
Ugyan ugy mint a notepad++-ban.
Es a css - nel is ki kell valasztani hogy. Css-t irsz.
Pont ugyan ugy mint a notepad ++-ban.
Tenyleg nem ertem hogy miert nem ertitek amit mondok.
Html fajl irasakor. Nyelv: html.
Css-nel nyelv: css.Ugyan ugy mint a notepad. ++-ban.
En nem tudom hogy tenyleg ennyire mashogy mukodik e ez a program mint a notepad ++, vagy csak en vagyok ennyire hulye, de nekem sokkal hasznalhatobbnak tunik a notepad ++.
-
Orionk
senior tag
válasz
martonx
#5866
üzenetére
Szia !
Én pont ilyen weboldalt szeretnék, mint ez. Azaz pont Ezt a PLUGINT szeretném átalakítani, amit lentebb néztél.
Tehát, hogy a weboldal oldalai így csúsznak, mint a fenti pluginban, és ha minden igaz, akkor reszponzív az oldal, azaz, hogy mobilon is jól megtekinthető.
Ha teljes képernyőre kiteszem a fenti plugint, akkor a háttérnek az alja is látszódik. Próbáld ki légyszíves. Egyébként, meg ha nincs full screen en az oldal, akkor nekem nem mutatja a böngésző a kép alsó kb. 20-30 pixelét, de az a következő oldalra sem nyúlik át, csak elveszik
Erre tudtok valami megoldást ?
----------------
A másik dolog, amit kérdezni szerettem volna, hogy hogyan lehet megvalósítani, hogy az oldalon menjen a héttérben zeneszám, de a képernyőn látható gombbal kikapcsolhatja a user.
köszi
-
Orionk
senior tag
válasz
martonx
#5863
üzenetére
Teljes képernyős Slider alatt azt érted, hogy reszponzív az oldal ? Egyáltalán reszponzív weboldal az a plugin, amit mutattam lentebb ?
A másik dolog, amit kérdezni szeretnék, hogy valóban teljes képernyőre feszíti ki a háttérképet, de a kép alsó 20-30pixele mindig lemarad, de miért ?Ha letöltöd a háttérképet, akkor a képek alja 20-30 pixellel nagyobb.
köszi szépen.
-
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!
-
#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......
-
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. -
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> -
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 -
#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. -
#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ó)):
-
#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/edit -
#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. -
#5503
csabyka666
veterán
martonx
#5502
-
#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. -
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? -
#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.
-
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.
-
#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. -
#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.
-
#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)), 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. -
#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 -
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.
-
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)! -
-
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ünk -
#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.html -
#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.
-
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!
-
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. -
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)
-
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 :-)
-
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)
-
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)
-
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á?)
De mi arra lennénk kíváncsiak, hogy van-e értelme egyáltalán fenntartani a weboldalt (nem a facebookos oldalt). Mert ha igen, akkor (mivel régi) újat kellene csinálni. Csak ha már csinálnánk, akkor úgy vagyunk vele, hogy valami modernet, szépet grafikusat kellene. De ahhoz meg valószínűleg zsebbe kell nyúlni. Ez egy non-profit, sőt kiemelten közhasznú egyesületnél nem olyan egyszerű 
NodeJs-re sajnos nincs elég időm, pedig érdekes dolgok vannak arra felé. Ha jól tudom ismét egyesül a NodeJs és iojs.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
(De úgy általában a válaszaira adott reakciókból is ítélve nem csak én vagyok vele így.)
Itt egy szemléltető példa, hogy az inline style-t felül lehet bírálni 
ezt ezzel 
Új hozzászólás Aktív témák
Hirdetés
- PlayStation 5
- Samsung Galaxy A54 - türelemjáték
- NVIDIA GeForce RTX 5070 / 5070 Ti (GB205 / 203)
- Amlogic S905, S912 processzoros készülékek
- Honor 400 Pro - gép a képben
- Samsung Galaxy Watch6 Classic - tekerd!
- Nintendo Switch 2
- Yettel topik
- Mielőbb díjat rakatnának a görögök az olcsó csomagokra az EU-ban
- Delta Force (2024)
- További aktív témák...
- AMD Ryzen 7 5700X processzor eladó /Garanciás/
- Xbox Series S + 2 kontroller
- Dell laptop eladó i5 11. gen, 8GB RAM, 512GB SSD, újszerű állapotban!
- Bomba ár! HP EliteBook Folio 1040 G1 - i5-G4 I 8GB I 256GB SSD I 14" HD+ I Cam I W10 I Garancia!
- Bomba ár! HP Elitebook Folio 9470M - i5-3GEN I 8GB I 256GB SSD I 14" I DP I Cam I W10 I Garancia!
- ÁRGARANCIA!Épített KomPhone i7 14700KF 32/64GB RAM RX 9070 XT 16GB GAMER PC termékbeszámítással
- ÁRGARANCIA! Épített KomPhone Ryzen 5 9600X 32/64GB RTX 5070 12GB GAMER PC termékbeszámítással
- ÁRGARANCIA! Épített KomPhone Ryzen 5 7600X 32/64GB RTX 5070 12GB GAMER PC termékbeszámítással
- Xiaomi Redmi Note 11 64Gb Kártyafüggetlen 1Év Garanciával
- BESZÁMÍTÁS! Microsoft XBOX Series S 512GB játékkonzol garanciával hibátlan működéssel
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: PC Trade Systems Kft.
Város: Szeged