#3

;)



Te trije fajli so do potankosti identicni ... ;)

Le vrstica "Last-Translator:" se pri enemu razlikuje LOL


všeč(0) ni všeč(0) spam(0)
#2

Ja defer atribut pove browserju da ne bo generiral nobenega contenta - document.write in da naj nadaljuje s parsanjem in rendarjem strani. Zdaj je vprasanje ali defer atribut res odlozi nalaganje zunanje skripte dokler se content body ne sparsa??? Doloceni browserji bi naj imeli probleme s tem. Tudi

HTML 4.01 DTD pravi "UA may defer execution of script."



Bom magari ob priliki naredil kaksen test pa bomo potem lahko definitivno rekli ali uporabljati Js funkcijo ali defer atribut :)


všeč(0) ni všeč(0) spam(0)
#3

In short, the point of template engines should be to separate your business logic from your presentation logic, not separate your PHP code from your HTML code.

:D




To kar si napisal je osnovna ideja templatov. Tega se lepo drzi Savant ki med drugim ne kompajlira template v php, ker se kot jezik za template upurablja php. Lepo dela tudi v php5 z Exceptni edino za kompatibilnost E_STRICT rabis verzijo 3 nalozit.



Meni osebno je ljubsi Smarty kljub temu da ga mnogi kritizirajo zaradi kompajliranja templatov in uporabo svojega jezika ki se ga mores naucit. Glede na to da je od leta 2001 ko so ga lansirali sama zasnova ostala vec ali manj enaka jim ni za zamerit. ;) Cakamo pa verzijo ki bo metala ven php5 exceptione.

Zakaj ga ljudje se vedno radi uporabljajo: Ker obstaja malo morje pluginov (Gettext), filtrov (removeHTMLComments, RemoveWhiteSpace, Gzip), ker ima razvit svoj cache sistem, ker ga z malo truda lahko vgradis tudi v razne MVC frameworke (CodeIgniter, ZendFramework, ...)



Kar se pa tice tvojih vprasanj pa si nametal kar nekaj zadev, ceprav ne vem tocno kaj zelis vedet. Izbira template sistem je odvisna od tebe. Ce ti to ne odgovarja in imas cas lahko vedno napises svojega ;)

Kar se pa tice dizajnerjev - jaz se nisem srecal nobenega, ki bi se ukvarjal z templati ter tagi in samimi template sistemi. To pri nas vec ali manj delajo programerji ... popravite me ce se motim!



LP, AlesL


všeč(0) ni všeč(0) spam(0)
#

Da tudi jaz zacnem z mojim doprinosom za narodov blagor ;)



Izpostavil sem vprasanje o performancu spletnih strani in predstavljam vam eno od resitev kako zadevo optimizirat.

Gre za primer ko na spletni strani vkljucujete eksterne Javascripte, oziroma zelite manipulirati z DOM-om takoj ko se ta nalozi. V primeru da se skripta klice tik pred </body> tagom ni nobenih problemov, saj se je HTML ze v celoti nalozil in zrenderiral. Stala nastane takrat kadar skripto vkljucimo v <HEAD> (recimo da jo tam tudi rabimo) saj se vse kar je pod <script> tagom ne renderira dokler se celotna skripta ne nalozi, kar pomeni da je celotna stran v zastoju oziroma v cakanju.



Vsi poznamo event window.onload tako da ne bom prevec razglabljal o tem. Ce uporabljate kaksen drug Javascript framework (prototype, scriptaculous) boste ze vedli kaj uporabit ;)

V primeru da pa ne rabite cakat da se nalozi celotna stran (HTML + slike), lahko uporabite resitev DEXAGOGO's FastInit library katera poskrbi da se inicializacijse fukncije klicejo takoj ko je browserjev DOM na voljo.

Klicemo funkcijo Load.JScript (JSON - i like it) ki v head section nalozi javascript datoteko katere source podamo kot parameter



Izvolite!


<HEAD>
<script type="text/javascript" language="JavaScript">
var Load = {
JScript: function (url_)
{
// We are preventing loading a file already loaded
var _script = document.getElementsByTagName("script");
var _head = document.getElementsByTagName("head")[0];

// Loop through the length of the links
for( i = 0; _script.length > i; i++)
{
// If the href is already present, remove it
if (_script*["href"] == url_)
{
_head.removeChild(_script*);
}
}

// Build script element
var _elscript = document.createElement("script");
_elscript.setAttribute("language", "javascript");
_elscript.setAttribute("type", "text/javascript");
_elscript.setAttribute("src", url_);

// Add script
_head.appendChild(_elscript);
}
};
function loadJs() {
Load.JScript('http://www.dolpoteg.com/nalagam-se-na-koncu.js');
}

window.onload = loadJs;
/*
//ce uporabljamo FastInit
FastInit.addOnLoad(loadJs);
*/
</script>
</HEAD>**



všeč(0) ni všeč(0) spam(0)
#50

Ja bo pa res treba zalit to z malinovcem ;)



Na zalost bom moral Bled izpustiti saj pridem sele okrog pol osmih zvecer domov. Sem se vedno v odpovednemu roku, he he.



Kdaj drugic pa z veseljem ...


všeč(0) ni všeč(0) spam(0)
#48

hm, AlesL iz RoN? :)




yep ;)



Po 7 letih Microsofta in asp-ja zapuscam AV-studio in se vracam nazaj k koreninam - php-ju ... LOL

Skrajni cas da se lotim prenove RoN-a saj je koda ze precej zastarela.



Pa tale forum je pridobil se eno glavco :)


všeč(0) ni všeč(0) spam(0)
#45

Sem nov tukaj na forumu, drugace pa ze v tem biznisu kar nekaj let. Kolikor vem Googlebot ne crawla css fajlov, saj ima z xhtml/html fajli prevec dela ;)



V tej temi je predvsem govora o optimizaciji spletnih strani za brskalnike, mene pa zanima naslednje.



Po manjsem iskanju po najdi.si sem na hitro pogledal podjetja ki se ukvarjajo z SEO in sem prisel do zakljucka da vecina njih pozablja na performance spletnih strani predvsem hitrost nalaganja.



Zanima me a se ukvarjate s stvarmi kot so:

- browser cache (empty - full)

- cookies (odstranitev odvecnih, velikost, razumen expire ...)

- zmanjsanjem stevilo HTTP requestov (npr: zdruzitev vecih skript v eno datoteko, zdruzitev css-jev v eno datoteko)

- Gzip, deflate content encodingom (HTML, JS, CSS)

- uporabo filtrov preden posljete spletno stran browserju (odstranitev nepotrebnih komentarjev, minimizacijo inline JavaScripta, ...)



Opazam da to pozabljajo tudi veliki portali pri nas (prva stran):

- dnevnik : 602 kb brez kompresije

- 24 ur : 400 kb brez kompresije

- delo: 278 kb (341 kb brez kompresije) - samo HTML je kompresiran



kar se nalaga celo vecnost v primerjavi z





  • yahoo : 184 kb (451 kb brez kompresije) - kompresirajo velike tri (HTML, JS in CSS)


  • ebay.de : 227 kb (518 kb brez kompresije) - kompresirajo velike tri (HTML, JS in CSS)



Kljub temu da zivimo v dobi sirokopasovnih povezav sem mnenja da se pri nas premalo ukvarjajo podjetja ki izdelujejo spletne strani s tem problemom. Zmanjsanje prenosa podatkov iz 451Kb na 184kb se na prvi pogled ne zdi veliko. Ko pa to pocne nekaj 1000 uporabnikov naenkrat in vsak sprozi nekaj ducata zahtev pa smo ze pri veliki razliki.



LP, AlesL


všeč(0) ni všeč(0) spam(0)