Toon posts:

[html]je huidige bouwstijl/aanpak voor statische html site

Pagina: 1
Acties:
  • 163 views sinds 30-01-2008
  • Reageer

Verwijderd

Topicstarter
Mijn favourite aanpak de laatste tijd, als ik een 'statische' html site moet maken;

--'all in one'
3 tot 30 informatie/texten.

Gewoon één index.html gebruiken.
Met de navigatiebuttons (en javascript) zet je diverse divs/plaatjes aan/uit.


--'content only'
3 tot +100 pages.

Design en navigatie wordt geschreven/geregeld via een javascript.
Makkelijk bij te houden, aangezien als er iets veranderd in de navigatie of
design, je puur één javascript-file (of css) kan aanpassen, en ter plekke
veranderen al die 50/100 pages.


soort van pseudo code
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
<html>
<head>

<script language="javascript" type="text/javascript">
    // set current navigation 
    var hoofdnavigatie=1;
    var subnavigatie=2;
    var subsubnavigatie=1;
</script>

<link rel="stylesheet" href="css/stylesheet.css" type="text/css">
<script language="JavaScript" src="js/navigatie.js" type="text/javascript"></script>

</head>

<body>

<script language="javascript" type="text/javascript">
    write_navigatie(hoofdnavigatie, subnavigatie, subsubnavigatie);
    write_design();
</script>


<div id="my_content" class="content">
    De text van de betreffende page.
</div>

</body>
</html>


Ik moest laatst weer een 'statische' site maken, in een zeer korte tijd. (via de 'content only' methode)
En het beviel mij zo goed, dat ik nu het design en navigatie, puur via één script geregeld had. On the fly kon ik er op het laatste moment nog pages toevoegen/weghalen, en last minute dingen veranderen in de vormgeving.
Geen gerotzooi meer met 50 pages 'search & replace'

Met dit topic wil ik meer tijdsbesparende en creatieve ideeen uitwisselen/geven met andere site-bouwers.

[ Voor 25% gewijzigd door Verwijderd op 19-12-2004 22:44 ]


Verwijderd

Waar je natuurlijk onmiddelijk bij stil moet staan, is dat mensen wel direct bij de nodige informatie moeten kunnen komen. Een zoekmachine zal niet direct kunnen linken naar een bepaalde 'pagina'. Ook zal de inhoud van dat ene document minder specifiek over één onderwerp gaan, en dat is voor een zoekmachine dus ook minder interessant. Tenslotte willen mensen misschien eens een directe link doorsturen, bookmarken of iets anders.

Er zijn vele nadelen te noemen, terwijl je met losse documenen en een "global search & replace" ook veel kunt bereiken. :)

  • Blaise
  • Registratie: Juni 2001
  • Niet online
Vrijwel elke server ondersteunt PHP, dus waarom zou je je dan op statistische sites concentreren?

De toegankelijkheid voor javascript-generated html is belabberd, (zoals cheatah ook vermeldt) terwijl je ongeveer hetzelfde met PHP kan doen op een toegankelijke manier.

[ Voor 50% gewijzigd door Blaise op 20-12-2004 01:44 ]


  • XangadiX
  • Registratie: Oktober 2000
  • Laatst online: 13-05 10:26

XangadiX

trepanatie is zóó kinderachtig

ik moet eerlijk zeggen dat ik voor iedere pagina met meer dan 5 bladzijden een php oplossing bedenk, al was het maar omdat ik er dan snel een admin systeem bij kan schuiven en dat vinden klanten op de lange termijn erg prettig.

Daarbij vind ik het in php prettig om alles, maar dan ook echt alles, in een bibliotheek bestand te stoppen, en dat is vaak inclusief alle headers database calls etc.
Over creatieve ideeen, ik geef dit soort bestanden altijd namen van legendarische klassieke bibliotheken. Zoals alexandrie.php, pergamon.php, abusimbel.php en thamugadi.php :+
(vooral als je niet zelf host krijg je nog wel eens leuke telefoontjes van netwerkbeheerders)

Ik houdt net als cheetah al zei niet zo van dat door js gegenereerde spul, dat is niet altijd even compatible en als er ergens een packet dropped is je hele pagina vernaggeld. Nee dan houdt ik het liever bij server side scripts.

ik wist trouwens niet dat er nog mensen waren die om een 'statische html' pagina vragen ;)

[ Voor 30% gewijzigd door XangadiX op 20-12-2004 01:57 ]

Stoer; Marduq


Verwijderd

Statische sites kom ik ook nog wel tegen.

De beschreven javascript aanpak heeft wat nadelen waarvan de meeste al genoemd zijn: Toegankelijkheid (drempelsweg en zo), cross-'user agent' compatibiliteit.

Aangezien bijna elk hosting-pakket wel php of asp ondersteund en dus ook server-side includes zou ik altijd dat gebruiken voor wat je nu met javascript doet. Een menu in een include maakte het idd een stuk makkelijker om even een pagina toe te voegen. Zelfde geldt voor je doctype/head, description/author/keywords enz.

Maar als zelfs dat niet voorhanden is (kom ik helaas ook tegen hoewel ik dan wel iets heb van: waar gaat dit over, neem fatsoenlijke hosting :/) dan werkt een 'search&replace in all files' nog verrassend goed. Maar dan moet wel je 'template' goed zijn zodat het alleen gaat om extra menu-items, spul in de 'head' van je pagina's enz. anders blijf je bezig.

Verwijderd

Laatste keer dat ik zoiets moest maken heb ik de website ontwikkeld op een server met ssi, en zo de hele navigatiebende dus apart gehouden.

Toen de boel uiteindelijk opgeleverd werd (idd naar een server met alleen statische mogelijkheden; de beheerder was 1 van die paranoiden die denken dat met ssi je hele server open staat), heb ik met een een of ander progsel al die sites over gezet naar iets statisch en klaar.

Idd ook geen ge-gloabal-search-&-replace meer zo

  • TRON
  • Registratie: September 2001
  • Laatst online: 04-05 12:27
Frames _O_


Not ;). Net als wat Type-O zegt, je kan dan ook volgens mij het beste met search & replace aanpassen. Frames moet je sowieso niet gebruiken.

-edit-
Wat een beetje omslachtig is, maar misschien wel goed mogelijk is om op een andere server de pagina's te laten 'renderen' en deze automatisch te laten uploaden naar de 'statische' server. Het is een leuke oplossing, maar heeft ook een aantal nadelen.

[ Voor 46% gewijzigd door TRON op 20-12-2004 09:36 ]

Leren door te strijden? Dat doe je op CTFSpel.nl. Vraag een gratis proefpakket aan t.w.v. EUR 50 (excl. BTW)


  • blizt
  • Registratie: Januari 2003
  • Laatst online: 01-05 08:39

blizt

Wannabe-geek

Ik zou het net als mophor doen ([rml]mophor in "[ htlm]je huidige bouwstijl/aanpak voor s..."[/rml]), dus dynamic (met 'n header die je overal include etc.) ontwikkelen en dan met Spiderzilla de website downloaden als statische HTML.

United we stand, and divided we fall


  • X-Lars
  • Registratie: Januari 2004
  • Niet online

X-Lars

Just GoT it.

Ik lees hier toevallig net dit artikel over. Het is even een andere optiek, maar wel relevant lijkt me.

  • Bosmonster
  • Registratie: Juni 2001
  • Laatst online: 10-05 18:53

Bosmonster

*zucht*

Denk dat je definitie van een 'statische site' ook kan verschillen. Bij ons valt er simpelweg onder dat er geen cms bij zit.

Aangezien al onze hostings toch PHP bevatten (eigen server) zijn zelfs statische sites opgebouwd met includes etc om wijzigingen makkelijker aan te kunnen pakken.

Het nut van een complete site met dhtml in een enkele pagina te proppen ontgaat me even :? Kan me niet voorstellen dat de beperkte voordelen hier op gaan wegen tegen de enorme nadelen.

[ Voor 25% gewijzigd door Bosmonster op 20-12-2004 10:00 ]


  • -Lars-
  • Registratie: Mei 2004
  • Niet online
Een idee dat net in me opkwam (nog nooit geprobeerd, misschien ook niet perfect te maken):

Op je testserver gewoon php gebruiken e.d. om de site samen te stellen, hier voer je ook alle wijzigingen in door. Is het resultaat naar wens, dan een script/programma uitvoeren dat alle dynamisch samengestelde pagina's als statische pagina's opslaat.
En voila, een statische site die makkelijk aanpasbaar is (even dynamisch bestand aanpassen, scriptje opnieuw uitvoeren, tada).
Enig probleem is denk ik dat het uitvoeren van dat script bij grote sites (veel pagina's) lang kan gaan duren. Verder zijn er dingen die je haast niet kunt uitvoeren in een statische pagina: fora, weblogs, gastenboeken etc.

[ Voor 3% gewijzigd door -Lars- op 20-12-2004 16:16 ]


Verwijderd

-Larz- schreef op maandag 20 december 2004 @ 16:15:
Een idee dat net in me opkwam (nog nooit geprobeerd, misschien ook niet perfect te maken):

Op je testserver gewoon php gebruiken e.d. om de site samen te stellen, hier voer je ook alle wijzigingen in door. Is het resultaat naar wens, dan een script/programma uitvoeren dat alle dynamisch samengestelde pagina's als statische pagina's opslaat.
En voila, een statische site die makkelijk aanpasbaar is (even dynamisch bestand aanpassen, scriptje opnieuw uitvoeren, tada).
Enig probleem is denk ik dat het uitvoeren van dat script bij grote sites (veel pagina's) lang kan gaan duren. Verder zijn er dingen die je haast niet kunt uitvoeren in een statische pagina: fora, weblogs, gastenboeken etc.
Een dergelijke aanpak is ook heel bruikbaar voor bijvoorbeeld datum-selects met 31 dagen en dat soort zaken. Weliswaar geen totaaloplossing maar zeker handige hulpmiddelen om bij de hand te hebben.

  • blizt
  • Registratie: Januari 2003
  • Laatst online: 01-05 08:39

blizt

Wannabe-geek

United we stand, and divided we fall


  • chris
  • Registratie: September 2001
  • Laatst online: 11-03-2022
Ik moet van m'n baas bij statisch sites met dreamweaver werken, zodat ie het zelf later ook makkelijk kan bewerken.
gelukkig heeft dreamweaver wel ondersteuning voor templates, dat werkt erg goed.

  • TwoR
  • Registratie: Augustus 2002
  • Laatst online: 15-05 10:40

TwoR

Gekleurde stippen

als ik eens een statische site moet maken zorg ik ervoor dat de header en footer gewoon geinclude worden en alles wat daartussen hangt doe ik in verschillende bestanden. Op deze manier kan ik wel snel het menu / footer / layout wijzigen en heb alles toch nog statisch.

  • drm
  • Registratie: Februari 2001
  • Laatst online: 09-06-2025

drm

f0pc0dert

TRON:
Frames moet je sowieso niet gebruiken.
Frames moet je sowieso altijd wel gebruiken.

Dit is ongeveer net zo zinnig om te zeggen. Onderbouw het eens, want anders is zo'n opmerking dus echt zinloos.

Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz


  • Mithrandir
  • Registratie: Januari 2001
  • Laatst online: 18:53
Ik zit nu ook met hetzelfde probleem, namelijk hoe een site onderhoudbaar te houden maar niet verzanden in een CMS ontwikkelen. Daar komt het probleem bij dat mijn baas graag de pagina's ook zelf aan wil passen; het liefst in frontpage... :'(

Ik denk dat een kleine database met een javascript-richedit-box de beste oplossing is. Hoe denken jullie daarover?

Verbouwing


Verwijderd

Mithrandir schreef op maandag 20 december 2004 @ 19:19:
Ik denk dat een kleine database met een javascript-richedit-box de beste oplossing is. Hoe denken jullie daarover?
Daar denk ik precies hetzelfde over. Klanten willen in de toekomst toch de touwtjes zelf in handen hebben en ik moet toegeven dat ik kleine textuele wijzigingen een gruwel vind.

  • Mithrandir
  • Registratie: Januari 2001
  • Laatst online: 18:53
Verwijderd schreef op maandag 20 december 2004 @ 19:25:
[...]


Daar denk ik precies hetzelfde over. Klanten willen in de toekomst toch de touwtjes zelf in handen hebben en ik moet toegeven dat ik kleine textuele wijzigingen een gruwel vind.
Tsja, maar een rich text edit... Mensen kunnen de site dan nog verneuken. Kijk maar naar www.lindecollege.nl. (mijn school). De leraren mochten met een rich text edit knoeien, met kleurtjes enzo. Het resultaat: dyslectische leraren die denken dat rood op roze wel leuk kleurt, of grijs op rood of ... *zucht*.

Maarja, toen die snufjes uit waren gezet ging mijn wiskundeleraar "HTML" schrijven. Resultaat: een tag soup, maar het zag er uit zoals hij wilde...

Mijn punt is dus dat je de mensen zo weinig mogelijk ruimte moet geven. Dat klinkt erg hard, en als ze je brood betalen is het standpunt ook niet vol te houden. Toch kun je proberen om in elk geval het aantal kleurtjes/styles dat te kiezen is zo te maken dat het in elk geval nog in het design van de site past.

Ik zit zelf te denken aan een javascript-edit-form zelf maken waarin een stuk of wat verschillende classes zijn de kiezen: header, dik, scheef en gewone text. Misschien nog één voor anders gekleurde text (donkerlbauw op een voor de rest blauwe site) en ik denk dat ik het eerst daarbij laat. En nu maar bidden dat m'n baas het ook genoeg vindt. :X

Verbouwing


Verwijderd

Mithrandir schreef op maandag 20 december 2004 @ 19:33:
[...]


Tsja, maar een rich text edit... Mensen kunnen de site dan nog verneuken. Kijk maar naar www.lindecollege.nl. (mijn school). De leraren mochten met een rich text edit knoeien, met kleurtjes enzo. Het resultaat: dyslectische leraren die denken dat rood op roze wel leuk kleurt, of grijs op rood of ... *zucht*.

Maarja, toen die snufjes uit waren gezet ging mijn wiskundeleraar "HTML" schrijven. Resultaat: een tag soup, maar het zag er uit zoals hij wilde...

Mijn punt is dus dat je de mensen zo weinig mogelijk ruimte moet geven. Dat klinkt erg hard, en als ze je brood betalen is het standpunt ook niet vol te houden. Toch kun je proberen om in elk geval het aantal kleurtjes/styles dat te kiezen is zo te maken dat het in elk geval nog in het design van de site past.

Ik zit zelf te denken aan een javascript-edit-form zelf maken waarin een stuk of wat verschillende classes zijn de kiezen: header, dik, scheef en gewone text. Misschien nog één voor anders gekleurde text (donkerlbauw op een voor de rest blauwe site) en ik denk dat ik het eerst daarbij laat. En nu maar bidden dat m'n baas het ook genoeg vindt. :X
Dan heeft jullie school een verkeerde editor gekozen. Je wilt niet dat een klant het stramien kan verneuken. Je wilt niet dat hij zelf kleuren kan kiezen, dat hij zelf het lettertype kan bepalen. Hoe een link eruit ziet etc.
Je moet een editor kiezen die CSS gebruikt. De gebruiker aan banden legt. Hij kan tekst selecteren en een CSS selector; titel, subtitel, tekst. De editor moet dus alle CSS verwijzingen importeren.
Er zijn best editors die zo werken. HTMLArea en FCKEditor zijn dan wel gratis, maar zijn ook grote rotzooi.

  • Twan V
  • Registratie: Oktober 2001
  • Laatst online: 12-05 11:58

Twan V

...en er stralend uitzien

Wij gebruiken ook gewoon de FCKEditor, maar dan wel een erg getemde versie. De klant mag niets, behalve inderdaad de vaste classes toepassen die in het stylesheet gedefinieerd staan. Verder mag de klant bold, italic... tekst centreren of rechts uitlijnen... linkje en bulleted list, plaatje... that's it.

Als ze meer willen, kunnen wij functies aanzetten, waarbij we de klant vantevoren uitleggen wat de risico's zijn, of we helpen ze even.

Werkt vrij goed. De truc is alleen om de editor af te richten, en daar ben je even mee bezig.

Blaat het niet dan schaadt het niet...
Reflex Discoshow - Het beste wat je bruiloft kan overkomen


  • Genoil
  • Registratie: Maart 2000
  • Laatst online: 12-11-2023
@cel-ed: ik ben niet zo gecharmeerd van je "all-in-one" oplossing. HTML beschrijft strikt genomen de inhoud van 1 webpagina, niet van een hele site. Zoekrobots vinden dat niet tof, de back/forward functie van elke browser zal niet reageren op jouw js-calls om van pagina te wisselen en gebruikers zonder javascript kunnen al helemaal niets met zo'n pagina-site.

De 'content only' oplossing is wat beter, maar de naam zegt al wat er niet zo mooi aan is. HTML is vooral bedoeld om stukken content te structureren en aan elkaar te relateren. Met het dynamisch (client-side) genereren van de hoofdstructuur van je website (je navigatie), waarschijnlijk dmv document.writes of DOM, abstraheer je een van de belangrijkste eigenschappen van je website naar een niveau waarop niet alle clients er zonder meer kaas van kunnen maken.

@reacties
PHP/SSI includes op je development server en een statische op de productieserver is natuurlijk helemaal ok. Gebruik ik zelf meestal ook. Wat ik er minder fraai aan vind is dat de files die je include losstaand geen zinnige output geven behalve fragmenten HTML. Dat maakt voor het einddoel natuurlijk niets uit. Maar als je dan toch PHP tot je beschikking hebt op je development server kun je ook overwegen XSLT te gebruiken als include systeem. Omdat zo'n statisch site veelal toch uit platte pagina + menuutje bestaat, is een XSL sheet die twee (of desnoods meer) XHTML files bij elkaar plempt en evt. nog wat class attributes zet voor het highlighten van de actieve pagina in het menuutje, eigenlijk heel simpel en herbruikbaar. Het voordeel is, dat alle bronbestanden well-formed XML moeten betvatten, waardoor je losse pagina's ook altijd netjes en begrijpelijk zijn tijdens de ontwikkelperiode. Daarnaast kan XSLT alle output heel netjes indenten, waardoor je HTML output retestrak is, hetgeen met PHP includes veelal mis gaat.

-- edit

Wat natuurlijk helemaal hip is, is XSL multiple document output, waarmee je bij het dynamisch genereren van je PHP-driven pagina's (met .php referenties in je hrefs) tegelijkertijd een HTML versie bouwt. Ik heb geen idee hoe breed die functionaliteit inmiddels al wordt ondersteund. Maar gegeven het feit dat XSL altijd well-formed documenten uitspuugt, kun je dat in PHP ook zelf realiseren door de output van je XSLT nog eens door een andere sheet heen te jassen die de hrefs fixed en de output daarvan opslaat als .html. Jammer dat ik zo'n ding nog niet heb ;)

[ Voor 17% gewijzigd door Genoil op 20-12-2004 20:16 ]


  • djluc
  • Registratie: Oktober 2002
  • Laatst online: 15-05 12:23
Zoekrobots vinden dat niet tof, de back/forward functie van elke browser zal niet reageren op jouw js-calls om van pagina te wisselen en gebruikers zonder javascript kunnen al helemaal niets met zo'n pagina-site.
Zou een javascript oplossing niet een idee zijn waarbij je de querystring gebruikt? Dus links linken naar page.html?page=32 en dan laat je met JS die div zien. Dan werken back en forward namelijk wel. Nog steeds heb je dan natuurlijk alle content in 1 pagina.

  • Genoil
  • Registratie: Maart 2000
  • Laatst online: 12-11-2023
djluc schreef op maandag 20 december 2004 @ 20:18:
[...]
Zou een javascript oplossing niet een idee zijn waarbij je de querystring gebruikt? Dus links linken naar page.html?page=32 en dan laat je met JS die div zien. Dan werken back en forward namelijk wel. Nog steeds heb je dan natuurlijk alle content in 1 pagina.
oh ja da's wel een mooie oplossing, had ik nog niet aan gedacht.

  • PrisonerOfPain
  • Registratie: Januari 2003
  • Laatst online: 07-04 13:41
Verwijderd schreef op zondag 19 december 2004 @ 22:38:
Geen gerotzooi meer met 50 pages 'search & replace'
Als je een beetje creatief bent met een C Pre Processor, ook niet :)

Verwijderd

Genoil schreef op maandag 20 december 2004 @ 20:03:
@cel-ed: ik ben niet zo gecharmeerd van je "all-in-one" oplossing. HTML beschrijft strikt genomen de inhoud van 1 webpagina, niet van een hele site. Zoekrobots vinden dat niet tof, de back/forward functie van elke browser zal niet reageren op jouw js-calls om van pagina te wisselen en gebruikers zonder javascript kunnen al helemaal niets met zo'n pagina-site.
Er zijn zat FLASH sites waarbij dit ook niet werkt. Zolang je menu-strucuur "semantisch verantwoord" is hebben visitors mijn inziens geen behoefte aan de back/forward functie.

Ik vind dit een snelle en eenvoudige oplossing voor een statische pagina. :)

[ Voor 3% gewijzigd door Verwijderd op 20-12-2004 21:24 ]


  • blizt
  • Registratie: Januari 2003
  • Laatst online: 01-05 08:39

blizt

Wannabe-geek

Maar flash-(only-)sites zuigen dan ook behoorlijk ....
Echter is dat 'n andere discussie die hier totaal off-topic zou zijn ;)
Wel wil ik aangeven dat Flash op zich niet zuigt, maar flash(-only-)sites wel.

Ik vind dat dus geen oplossing voor 'n statische pagina!

United we stand, and divided we fall


  • Genoil
  • Registratie: Maart 2000
  • Laatst online: 12-11-2023
Verwijderd schreef op maandag 20 december 2004 @ 21:22:
[...]

Er zijn zat FLASH sites waarbij dit ook niet werkt.
Ja, mateloos irritant.
Zolang je menu-strucuur "semantisch verantwoord" is hebben visitors mijn inziens geen behoefte aan de back/forward functie.
* Genoil back-knop freak. Het is daarnaast m.i. niet de bedoeling dat de ontwerper van een website bepaalt wat de behoeften van de gebruiker zijn buiten het pagina-oppervlak...dat maak ik gvd ;) altijd zelf nog wel uit :).

Het maakt niet hoe semantisch verantwoord je menu is, mensen willen terug! Niet omdat jij iets fout gedaan hebt, maar omdat ze zelf denken "hmm nee dit wil ik bij nader inzien niet, ik wil terug, NU!". Het ligt dan voor de hand naar de vertrouwde back-knop te gaan, maakt niet uit waar je je custom back-knop neerplempt.

[ Voor 9% gewijzigd door Genoil op 20-12-2004 22:07 ]


Verwijderd

Genoil schreef op maandag 20 december 2004 @ 22:05:
[...]
...dat maak ik gvd ;) altijd zelf nog wel uit :).
Daar heb je gelijk in... 8)7

  • mullah
  • Registratie: April 2000
  • Laatst online: 19-07-2025
Ik zou als ik met javascript ga werken en alles in een pagina heb staan gaan werken met named anchors .. dus de javascript roept dingen aan als www.example.com/pagina.php#abcdefg en aan hand van die anchors wordt dan de juiste sectie weergegeven, werkt je back button ook meteen, en snapt google de hele zooi misschien ook bijna

  • -Lars-
  • Registratie: Mei 2004
  • Niet online
Ook de search/replace-programma's gebruiken kan een goed idee zijn. Tip: gebruik om het menu, header, footer en inhoud commentaar waaraan je het altijd kunt herkennen, da's leuk voor het programma.
:/ Denk je eens met een geweldig idee te komen... :)
mullah schreef op maandag 20 december 2004 @ 22:43:
Ik zou als ik met javascript ga werken en alles in een pagina heb staan gaan werken met named anchors .. dus de javascript roept dingen aan als www.example.com/pagina.php#abcdefg en aan hand van die anchors wordt dan de juiste sectie weergegeven, werkt je back button ook meteen, en snapt google de hele zooi misschien ook bijna
Wat is jouw defenitie van statisch? Je gebruikt een .php-bestand, dus php en gaat vervolgens met javascript het "dynamische" op de site toepassen. Gebruik dan meteen php, dat is voor dit soort dynamische dingen geschikter.

Verder: leuk als je henorm veel pagina's hebt, denk aan een documentatie die honderden pagina's bevat. De laadtijd van jouw pagina zou enorm stijgen. Geen probleem voor de gemiddelde tweaker met l33te modem en internetconnectie, maar een hel voor de iets minder toebedeelde mensen ;).

Ook ben ik van mening dat de inhoud van 1 pagina ook op 1 pagina getoond moet worden. Dat is geheel volgens de verwachtingen van de bezoeker en dus qua accessibility en usability het beste.

  • mullah
  • Registratie: April 2000
  • Laatst online: 19-07-2025
Oeps.. de .php was een automatisme.. met www.example.com/pagina.html#abcdefg kan het ook hoor, je kunt het handlen van de anchors namelijk ook met javascript afvangen..

En we hebben het hier over een kleine statische site, bij een site met meer dan 20 serieuze pagina's ga ik echtwel aan kleine CMS systemen denken, dus het 100en pagina's downloaden is niet relevant.
In een site met relatief weinig pagina's is de bestandsgrootte van de extra afbeeldingen vaak meer dan de complete hoeveelheid tekst van een site.

  • Mithrandir
  • Registratie: Januari 2001
  • Laatst online: 18:53
Het probleem is dat je niet alleen problemen krijgt met de toegankelijkheid van je website, maar denk ook eens aan text-only browsers of google (een belangrijke bron voor bezoekers).

Die zullen dus totaal niets met je javascript site kunnen. En geloof me, geen enkele bot kent javascript, dus het zal niet goed geindexeerd worden.

En daarbij komt: waarom zou je de moeite doen om zo'n site te maken in javascript als je het even snel in PHP kunt programmeren? Het scheelt nog bandbreedte ook!

Verbouwing


  • mullah
  • Registratie: April 2000
  • Laatst online: 19-07-2025
Mithrandir schreef op dinsdag 21 december 2004 @ 23:41:
Het probleem is dat je niet alleen problemen krijgt met de toegankelijkheid van je website, maar denk ook eens aan text-only browsers of google (een belangrijke bron voor bezoekers).

Die zullen dus totaal niets met je javascript site kunnen. En geloof me, geen enkele bot kent javascript, dus het zal niet goed geindexeerd worden.
De topicstarter stelt juist dat je met javascript divjes aan en uit zet... de pagina kan dus door text-only browsers zoals bots gewoon heel simpel gelezen worden.

De site is zonder CSS en JavaScript gewoon een lange html pagina met een aantal linkjes die naar named anchors springen - best wel normaal toch.
Mithrandir schreef op dinsdag 21 december 2004 @ 23:41:
En daarbij komt: waarom zou je de moeite doen om zo'n site te maken in javascript als je het even snel in PHP kunt programmeren? Het scheelt nog bandbreedte ook!
Soms is niet alles een spijker als je een hamer in je hand hebt.

  • marko77
  • Registratie: Februari 2002
  • Laatst online: 06-05-2025
-Larz- schreef op maandag 20 december 2004 @ 16:15:
Een idee dat net in me opkwam (nog nooit geprobeerd, misschien ook niet perfect te maken):

Op je testserver gewoon php gebruiken e.d. om de site samen te stellen, hier voer je ook alle wijzigingen in door. Is het resultaat naar wens, dan een script/programma uitvoeren dat alle dynamisch samengestelde pagina's als statische pagina's opslaat.
En voila, een statische site die makkelijk aanpasbaar is (even dynamisch bestand aanpassen, scriptje opnieuw uitvoeren, tada).
Enig probleem is denk ik dat het uitvoeren van dat script bij grote sites (veel pagina's) lang kan gaan duren. Verder zijn er dingen die je haast niet kunt uitvoeren in een statische pagina: fora, weblogs, gastenboeken etc.
Dat zou ik inderdaad ook eerder doen dan met javascript werken o.i.d.

Sowieso 'misbruik' ik de testserver scripting wel vaker om b.v. grote selectbox te genereren of complete regels javascript (b.v. form checks) waar de variabelen numeriek oplopen o.i.d.

lekker lui toch ;)

Mijn rig


Verwijderd

Ik maak alleen maar statische sites. Althans, 'maakte', want ik had weinig behoefte meer om me te verdiepen in alle technische aspecten van dynamische pagina's. JS, dHTML, PHP, SSI, XLST, XML, het is mij als eenvoudig hobbyistje allemaal te veel om aan te leren en om sowieso nog door alle technieken het bos te zien.

Ik hou het simpel op de heerlijke combinatie XHTML/CSS voor respectievelijk inhoud/layout.

  • Woudloper
  • Registratie: November 2001
  • Niet online

Woudloper

« - _ - »

Ik neem aan dat je met statische pagina's, HTML pagina's bedoelt zonder tussenkomst van een scripting taal o.i.d. en niet de definitie die Bosmonster gebruikt? Zoals hierboven beschreven heeft jouw oplossing de nodige nadelen met betrekking tot de zoekbaarheid van je pagina. Heb je daar ook over nagedacht en wordt dat probleem ook ondervangen?

Wanneer je overigens gebruikt maakt van een HTML Editor (denk bijvoorbeeld aan Dreamweaver) en je gaat gebruik maken van templates heb je ook een redelijk snelle manier van werken.

Als je overigens je HTML goed opzet en je CSS geheel los van de HTML plaatst moet je ook een snelle manier hebben tot het ontwerpen/stylen/opleveren van een pagina als je het mij vraagt...

* Woudloper zou nog wel eens een reactie terug willen zien van de TS'er

Verwijderd

De topicstarter stelt juist dat je met javascript divjes aan en uit zet... de pagina kan dus door text-only browsers zoals bots gewoon heel simpel gelezen worden.
Alleen als je een resultaat vind en er naartoe gaat gaat het fout aangezien je de informatie die je vond niet terugziet op de site. (Deze is immers verborgen.)

Verder heb je zoveel tekst op een pagina dat je ranking voor een bepaald woord sterk omlaag gaat (aantal keren woord / totaal aantal woorden).

Daarnaast worden de links naar ID elementjes niet geindexeerd dus je zou ook niet kunnen linken daarna vervolgens met JS iets opvangen (of :target) en de betreffende inhoud laten zien.

Je wordt ook slechter geindexeerd omdat je TITLE element alleen relevant is voor de gehele website. Je URI is dus, zoals eerder gezegd, ook alleen maar relevant voor de gehele website.

Qua siteopbouw lijkt me dit nou niet echt de beste oplossing. Eerder een slechte.

  • mullah
  • Registratie: April 2000
  • Laatst online: 19-07-2025
kan ik niets meer aan toevoegen...

meerdere losse pagina's is dus handiger, ook al moet je dan meerdere bestanden bijhouden.

  • Twan V
  • Registratie: Oktober 2001
  • Laatst online: 12-05 11:58

Twan V

...en er stralend uitzien

mullah schreef op woensdag 22 december 2004 @ 00:49:
[...]
Soms is niet alles een spijker als je een hamer in je hand hebt.
Sterke spreuk, maar ik ben het er niet helemaal mee eens.

Als je php bij de hand hebt en je wilt alles in een pagina, zou ik niet blind vertrouwen op javascript.

Even uit mijn hoofd een smerige oplossing:
PHP:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
<?
$a_titels = array(
"Welkom",
"Pagina 2",
"Untitled document",
"Nieuw Frotpage-document 28"
);
//dirty coding, maar het werkt wel als het goed is:
$a_content = array( 
"?>
<p>Welkom bij mijn hoompeetsj</p>
<?",
"?>
<p>pagina 2</p>
<?",
"?>
<p>plagina 3</p>
<?",
"?>
<p>nog meer content voor pagina 4</p>
<?"
);

if(isset($_GET['page']) && !empty($_GET['page']))
    $page = intval($_GET['page']);

?>
<html>
<head>
<title><?=$a_titels[$page]?></title>
</head>
<body>
<?=$a_content[$page]?>
</body>
</html>


Niet moeilijk, niet zwaar om te scripten, eenvoudig bij te houden (misschien makkelijker als je de indexen bij het aanmaken van het array zelf al aangeeft), werkt overal en altijd en is google-vriendelijk

Blaat het niet dan schaadt het niet...
Reflex Discoshow - Het beste wat je bruiloft kan overkomen


  • Mithrandir
  • Registratie: Januari 2001
  • Laatst online: 18:53
mullah schreef op woensdag 22 december 2004 @ 00:49:
[...]

De topicstarter stelt juist dat je met javascript divjes aan en uit zet... de pagina kan dus door text-only browsers zoals bots gewoon heel simpel gelezen worden.

De site is zonder CSS en JavaScript gewoon een lange html pagina met een aantal linkjes die naar named anchors springen - best wel normaal toch.


[...]

Soms is niet alles een spijker als je een hamer in je hand hebt.
Door bots makkelijk een site uitlezen waar divjes instaan?

heb je ooit nagedacht over hoe een gebruiker dan op je site komt? Gewoon op de mainsite. Vervolgens kan de user de informatie niet direct vidnen (hij komt niet meteen op de goede pagina terecht omdat alle pagina's die je hebt gemaakt dezelfde info hebben), en gaat weer weg.

Dan ben jij degene die met de verkeerde spijker probeert te timmeren hoor ;)

Verbouwing

Pagina: 1