Menu's volledig opbouwen mbv javascript? meningen?

[mr_star]

Ik ben bezig met een CMS systeem te maken (php). Probleem is dat hier nogal vrij veel verschillende menu's aan te pas komen, afhankelijk van de rechten van de gebruiker.
Nu heb ik snel een javascriptje in elkaar geknutseld waarmee ik mijn menu's kan opbouwen. In php wordt aan de hand van de rechten van de gebruiker een aantal arrays in het javascriptje opgevuld, waarna client side de menu's opgebouwd worden.

Hier een klein simpel voorbeeldje. De arrays in het begin worden dus aangemaakt in het php script.

code:

mItems = new Array(
Array('Features','Bugs'),
Array('menu2')
);

mLinks = new Array(
Array('/dpm/todo/features/','/dpm/todo/bugs/'),
Array('niks')
);

for (i1=0; i1<mItems.length; i1++)
{
    document.write('<table border="0px" cellpadding="0px" cellspacing="0px"><tr><td colspan="3">[img]"/images/menu_head.png"[/img]</td></tr>');
    for (i2=0; i2<mItems[i1].length; i2++)
    {
        document.write('<tr><td width="6px">[img]"/images/menu_left.png"[/img]</td><td width="112px"><a class="niv1" href="', mLinks[i1][i2], '">',mItems[i1][i2],'</a></td><td width="6px">[img]"/images/menu_right.png"[/img]</td></tr>');
    }
    document.write('<tr><td colspan="3">[img]"/images/menu_foot.png"[/img]</td></tr></table>');
}

Nu vind ik dit eigenlijk wel een heel handige manier om mijn menu's op te bouwen. Het spaart load uit op de server omdat de template parser minder moet doen en er moet minder data verstuurd worden want al die menu's zijn een constante herhaling van een heleboel html code.

Nu kom ik eindelijk aan mijn vraag: Kan ik dit gebruiken op een site die vaak bezocht wordt?
met andere woorden: kan ik van de gebruiker eisen dat die javascript ondersteund?
Ik heb er eigenlijk geen id van van hoeveel mensen er geen javascript kunnen gebruiken.

Wat zijn jullie ervaringen hierin? hoever kan men hier in gaan?

edit:
sorry voor layout verneuking

[ Voor 17% gewijzigd door mr_star op 16-02-2004 22:40 ]

[curry684]

Javascript is van de buren van W&G, moved

[Spider.007]

Ik zou eerder tijd gaan steken in wat CSS met XHTML. Dit bied voordelen voor de gebruikers; en ik kan me niet voorstellen dat het aan de serverkant load zou kosten? Als je in plaats van tabellen gebruik maakt van 'div's dan ben je het grootste deel van je html code al kwijt

[Johnny]

Je zou het kunnen gebruiken, je kan best eisen van je bezoeker dat ze javascript ondersteunen, iemand zonder JavaScript ondersteuning kan nauwelijks fatsoenlijk internetten, daarnaast blijkt uit verschillende polls/onderzoeken dat er nog maar enkele mensen zijn (tienden van procenten) die versie 4 browsers gebruiken, en zelfs deze ondersteunen al javascript.

Tweakers.net doet het ook alleen met JavaScript.

maar er zitten nog wel wat foutjes in je HTML

code:

<table border="0px" cellpadding="0px" cellspacing="0px">

Dat mag niet, die "px" moet je alleen gebruiken als je met CSS werkt.

Omdat ik een slash zie staan bij de <img> tag ga ik er van uit dat je XHTML wilt maken.

Ook zie ik dat de tabel slechts een enkele colom heeft, je gebruikt er wel drie voor afbeeldingen, maar dat hoeft niet als je met een lijst (<ul>) werkt en de plaatjes als bullet/achtergrond zet doormiddel van CSS.

[ Voor 5% gewijzigd door Johnny op 16-02-2004 22:50 ]

[Verwijderd]

Ik kan in drie tellen al zeggen dat je script niet handig in elkaar zit. Je wilt titel + link in één functieaanroep, constructor of array opgeven. Of je arrays door PHP worden gemaakt maakt wat mij betreft niets uit. Wat je nu hebt aan code is slecht onderhoudbaar en slecht aanpasbaar. Je hebt inline styles gebruikt wat al helemaal niet handig is, en je gebruikt nietszeggende alt-teksten. Haal die tekst helemaal weg als je toch niets te melden hebt over de inhoud van het plaatje. Haal de plaatjes helemaal weg als je ze ook als achtergrondplaatje mee kunt geven in een stylesheet.
i1 en i2 zijn geen handige namen. Een 1 na een i wordt gelezen als een kleine L

Verder: met een CMS kun je eisen dat mensen javascript moeten enablen. Anders zit je al gauw met een vreselijk omhandig geheel. Voor een grote website is het wel zo fijn als het ook zonder javascript kan. Met HTML compressie kun je ook heel erg veel.

[Verwijderd]

Spider.007 schreef op 16 februari 2004 @ 22:48:
Ik zou eerder tijd gaan steken in wat CSS met XHTML. Dit bied voordelen voor de gebruikers; en ik kan me niet voorstellen dat het aan de serverkant load zou kosten? Als je in plaats van tabellen gebruik maakt van 'div's dan ben je het grootste deel van je html code al kwijt

Wat nou divs? Gebruik liever gewoon nuttigere HTML elementen zoals lists (ul, ol, dl).

[Verwijderd]

Ik haat echt javascript menu's vooral als ze een beetje groot worden worden ze echt onverdraagzaam langzaam. Er stond afgelopen maand een goed artikel in vooruit over hoe je met een css ook een uitklapmenu kan maken dat crossbrowser compatible is

[ Voor 4% gewijzigd door Verwijderd op 16-02-2004 22:59 ]

[mr_star]

De html code bevat idd fouten, maar dit is maar een snelle copy/past van een site waar ik wel css gebruik. Daarna heb ik snel de eigenschappen van mijn td's in de html code gezet. Uiteraard zal ik css gebruiken.

Maar ik doel hier meer op het principe dan op de juiste werking van mijn code

Wat wel grappig is als ik op deze manier mijn menu's ophouw is dat er in de bron code van de html pagina alleen

code:

<script language="javascript" src="menu.js"></script>

staat op de plaats waar het menu normaal staat

Misschien dat dit idd niet echt veel uitmaakt kwa load van de server, maar het zal zeker schelen in kb's die overgepompt moeten worden.

[drm]

Als aanvulling op Cheatah: als je toch vraagt "hoe het moet", gebruik dan ipv die ranzige document.write gewoon DOM methoden.

[mr_star]

Verwijderd schreef op 16 februari 2004 @ 22:53:
Ik haat echt javascript menu's vooral als ze een beetje groot worden worden ze echt onverdraagzaam langzaam. Er stond afgelopen maand een goed artikel in vooruit over hoe je met een css ook een uitklapmenu kan maken dat crossbrowser compatible is

Ik ben ook niet van plan om van die uitklap menu's te maken. Ik vind die zelf ook niet handig. Met deze menu's merk je gewoon niet eens dat ze mbv een javascriptje opgebouwd zijn.

Er was ineens een rare kronkel in mijn hoofd die zei: wat als ik het eens op deze manier oplos.

Cheatah: Mijn code is idd niet echt onderhoudbaar, ik wilde eerste meningen horen over deze manier van werken voor ik er echt mijn tijd in zou steken om dit helemaal tot in de puntjes uit te werken.

drm schreef op 16 februari 2004 @ 22:58:
Als aanvulling op Cheatah: als je toch vraagt "hoe het moet", gebruik dan ipv die ranzige document.write gewoon <acronym title="Document Object Model" style="border-bottom:1px solid #777; cursor:help;">DOM</acronym> methoden.

Daar zal ik zeker eens informatie over opzoeken (ik ben nog maar met mijn eerste stapjes in javascript bezig.)

[ Voor 22% gewijzigd door mr_star op 16-02-2004 23:04 ]

[disjfa]

ik denk dat ik het verder met die mensen met de gekke kleurtjes kwa namen in het gelijk moet stellen.

als je het toch al in moet laden doe het dan goed. een include geeft even veel server load als een script includen.

verder is het language niet meer bruikbaar in normale browsers. je moet type="text/javascript" doen

@crisp opera valt wel mee hoor
en @ drm die woorden kan ik niet goed spellen want ik was er al aan begonnen maar jij weet hoe het goed gespelt word irritant @ sig.... jammergenoeg

[ Voor 27% gewijzigd door disjfa op 16-02-2004 23:09 ]

[crisp]

Even algemeen: javascript menu's hoeven niet traag te zijn; dat ligt 100% aan je scripting skillz (of gebrek daaraan )

Daarnaast zal je zelfs voor CSS-menu's vaak nog JS nodig hebben om het in IE aan de praat te krijgen, en ik zal je vertellen dat ik vandaag ook met een menu bezig ben geweest netjes opgebouwd met list-items enzo, en het heeft me een halve dag gekost om dat in IE5.5 en Opera7 netjes en aan de praat te krijgen (Opera heeft een enorm irritante bug mbt floats in een absoluut geplaatst element zonder breedte). Als ik een tabelletje had gebruikt was ik in 15 minuten klaar geweest...
(eerlijksheidshalve moet ik erbij zeggen dat ik ook nog FIR erbij gebruikt heb wat het ietwat complexer maakt)

Punt is gewoon dat veel browsers gewoon nog bugs en tekortkomingen hebben wb CSS, dus roepen dat je voor een menu netjes een list moet gebruiken vind ik nogal kort door de bocht (het kan wel, maar dan moet je wel weten wat je doet, en er extra tijd voor uittrekken)...

[ Voor 6% gewijzigd door crisp op 16-02-2004 23:08 ]

[drm]

disjfa:
verder is het language niet meer bruikbaar in normale browsers deprecated en geschrapt in latere html versies. je moet afhankelijk van de te gebruiken DTD type="text/javascript" doen

[mr_star]

om even op crisp te reageren: ik sta nogal huiverig tegenover divs. Als ik een layout wil maken met divs en ik vind die er goed uitzien in mozilla, en ik bekijk die dan in internet explorer, kan ik weer helemaal opnieuw beginnen. Ik heb het gevoel dat iedere browser zijn zin doet met het interpreteren van de divs. Met tabellen ben ik op 5 minuten klaar.

[Johnny]

mr_star schreef op 16 februari 2004 @ 23:11:
om even op crisp te reageren: ik sta nogal huiverig tegenover divs. Als ik een layout wil maken met divs en ik vind die er goed uitzien in mozilla, en ik bekijk die dan in internet explorer, kan ik weer helemaal opnieuw beginnen. Ik heb het gevoel dat iedere browser zijn zin doet met het interpreteren van de divs. Met tabellen ben ik op 5 minuten klaar.

Beide browsers gebruiken een verschillend box-model.

Je kunt MSIE (alleen vanaf 6.0) dwingen omdat van het W3C en Mozilla te gebruiken door boven je pagina een stricte DTD te zetten.

Andersom kun je Opera en Mozilla het box-model van MSIE laten gebruiken met een CSS property.

Het gebruik van divs voor verschillende browsers is helemaal niet moelijk, als je eenmaal wat je wel/niet kan.

[Verwijderd]

Even algemeen: javascript menu's hoeven niet traag te zijn; dat ligt 100% aan je scripting skillz (of gebrek daaraan )

In veel gevallen mee eens, maar als je 500+ (= dus heel veel submenus) items wil laden in een dynamisch menu (zoals een tree) dan gaat de client dat echt niet fijn vinden. Ongeacht hoe goed je het hebt gescript.

[disjfa]

Het gaat niet alleen om het box model. Wel dat daar veel topics over zijn. De verschillende browsers happen nou eenmaal sommige dingen anders. Met name als je veel met margins paddings en plaatsen op het scherm gaat. Het box model is niet al te moeilijk omheen te werken en gaat er waarschijnlijk ook uit met css3.

En mabit, dat kan wel. Als je het goed script zoals crisp al zei. Je hoeft niet alles javascript te maken.

[ Voor 16% gewijzigd door disjfa op 16-02-2004 23:23 ]

[mr_star]

disjfa schreef op 16 februari 2004 @ 23:21:
Het gaat niet alleen om het box model. Wel dat daar veel topics over zijn. De verschillende browsers happen nou eenmaal sommige dingen anders. Met name als je veel met margins paddings en plaatsen op het scherm gaat. Het box model is niet al te moeilijk omheen te werken en gaat er waarschijnlijk ook uit met css3.

En mabit, dat kan wel. Als je het goed script zoals crisp al zei. Je hoeft niet alles javascript te maken.

Zit je bij de overschakeling naar css3 dan ook weer niet met het probleem dat het een aantal jaar duurt eer dat de meeste browsers css3 ondersteunen?

anyway, ik denk dat ik voor de gewone frontpage maar gewoon blijf werken met mijn menu's die ik langs de template parser stuur, maar voor de cms pagina's ga ik het toch op deze manier doen denk ik. Dit lijkt mij toch handig te zijn in die situatie waarbij het aantal menu's die getoond worden sterk kan verschillen.

Er mogen natuurlijk nog altijd meningen komen ik ga er nu eens over

[MrBrown]

Wat ik even niet helder heb: is dit menu nou voor de backend van je CMS, of voor de bezoekerszijde? Dit heeft nogal verschillen namelijk. Voor de backend kan je zondermeer eisen stellen aan de gebruikte browser, omdat maar een beperkte groep personen gebruik maakt van de backend.

Als het menu op de bezoekerszijde draait moet je heel goed gaan overleggen of je klant wil investeren in een systeem wat ook op niet javascript-enabled browsers werkt. Of hij dit wil hangt heel erg af van de klant. Gemeentes (en andere overheidsinstellingen) willen bijvoorbeeld graag aan drempels weg standaarden voldoen, zodat personen met bijvoorbeeld een braille-browser ook toegang hebben tot de site. Bij de eigenaar van een webshop kan ik me aan de andere kant voorstellen dat de kosten van het niet-javascript-menu niet opwegen tegen de baten.

Je kan er altijd voor kiezen een vereenvoudigde versie te maken voor niet javascript enabled browsers natuurlijk...

[Verwijderd]

Zit je bij de overschakeling naar css3 dan ook weer niet met het probleem dat het een aantal jaar duurt eer dat de meeste browsers css3 ondersteunen?

Klopt niet wat hier gezegd wordt hoor. In CSS3 gaat er helemaal niks uit w.b.h. box model.

[disjfa]

Verwijderd schreef op 18 februari 2004 @ 12:42:
[...]
Klopt niet wat hier gezegd wordt hoor. In CSS3 gaat er helemaal niks uit w.b.h. box model.

niet? Ik hoorde dat de laatste tijd. Maar het box-model word toch wel verandert iig?

[Verwijderd]

Uitgebreid ( http://www.w3.org/TR/css3-box/ ). En als je iets hoort, zet er een link bij. Als je het van 1 persoon hoort zonder bron, dan hoopt/denkt die persoon het en is het meestal niet waar.

[disjfa]

het was geloof ik van jou..... toen weet ik nog dat clay uitlegde op welke manieren je gemakkelijk om het box-model heen kon werken.