[HTML] Frameset voor een CMS

[Genoil]

Dat voor "normale" websites framesets inmiddels not-done zijn is iedereen het zo'n beetje wel over eens, maar hoe zit dat eigenlijk met CMSen? Ik wil weer eens een nieuw CMSje bouwen, en de layout daarvan moet gaan lijken op die van Ultraedit (maar dan met formulieren op de plek van de code). Nu kan ik wel heel moeilijk gaan doen met DHTML om allemaal van die split windows na te gaan bouwen en gaan stoeien met CSS om deze layout uberhaupt te laten werken, maar met 1 Framesetje ben ik gewoon veel sneller klaar en het werkt ook nog eens goed. Bijkomend voordeel is dat er per request minder gegevens hoeven worden bijgewerkt. Enige nadeel is wellicht wat meer Javascript om de frames onderling te laten communiceren.

Kan iemand misschien aangeven waarom ik dit toch beter niet kan doen? Of waarom voor een CMS een normale pagina uiteindelijk toch fijner is dan een Frameset?

[djluc]

Waarom niet: javascript nodig voor communicatie tussen frames. Daar kan ook een hoop tijd in gaan zitten. Waar je ook nog naar kan kijken: met xmlLoad de formulieren en gegevens met de server communiceren.

[Verwijderd]

Waarom moet je Frames gebruiken en waarom denk je dat het maken van een CMS zonder frames moeilijker is? Je kan toch ook gewoon het systeem zo maken dat het menu in een cache gegooid wordt en elke keer wordt geinclude als je een pagina bezoekt.
/me ziet het probleem eigenlijk niet zo

[Verwijderd]

dit is juist correct gebruik van frames, niks mis mee

net als met tables: als je ze voor het juiste doel gebruikt is er niks mis mee.
frames voor cloaking of voor caching doeleinden zijn niet goed, in het geval van verschillende "panes" wel

[Verwijderd]

XMLHTTPRequest icm http://annevankesteren.nl...5/01/position-fixed-in-ie ?

[Genoil]

Verwijderd schreef op dinsdag 18 januari 2005 @ 17:32:
Waarom moet je Frames gebruiken en waarom denk je dat het maken van een CMS zonder frames moeilijker is? Je kan toch ook gewoon het systeem zo maken dat het menu in een cache gegooid wordt en elke keer wordt geinclude als je een pagina bezoekt.
/me ziet het probleem eigenlijk niet zo

Het is ook geen probleem, het is een overweging
Nou ik heb even verder zitten nadenken. Met een frameset heb ik:
• resizable panes out-of the box
• preview-frame is ook fluitje van cent (+ mogelijkheid front-end gebruiken om in CMS te navigeren)
• minder verversingen (niet dat dat echt wat uitmaakt maar het is mooi meegenomen)

XMLHTTPRequest icm http://annevankesteren.nl...5/01/position-fixed-in-ie ?

mja klinkt heel hip maar ik wil het allemaal niet te high-profile . het moet simpel worden en staan als een huis, dus ik laat technische snufjes liever even links liggen (ook icm met te verwachten opleverdatum...).

[ Voor 22% gewijzigd door Genoil op 18-01-2005 17:52 ]

[Verwijderd]

idd, ik snap die framesfobie ook niet echt, mits correct gebruikt zou het bijzonder nuttig zijn

ik kan me voor GoT ook wel een slpit screen versie voorstellen met het forum links en een thread rechts (of boven en beneden), met wat serverside scripting kan je deeplinken (nadeel van frames) naar een bepaalde thread zo fixen

/me gaat z'n eigen site ook maar eens zo'n versie geven: zondag update

[ Voor 16% gewijzigd door Verwijderd op 18-01-2005 17:50 ]

[jeanj]

Voor een quick build is frames natuurlijk hadnig, voor een uitdaging neem doe css. Kijk eens op http://www.csszengarden.com/, dat is allemaal css, met het zelfde html file onder elke pagina.

Misschien wil het het over een maand wel als <vul een editor in> uit laten en dan moet je alles weer herbouwen.
CSS rulez....

[Genoil]

jeanj schreef op dinsdag 18 januari 2005 @ 17:56:
Voor een quick build is frames natuurlijk hadnig, voor een uitdaging neem doe css. Kijk eens op http://www.csszengarden.com/, dat is allemaal css, met het zelfde html file onder elke pagina.

Misschien wil het het over een maand wel als <vul een editor in> uit laten en dan moet je alles weer herbouwen.
CSS rulez....

gehe ja dat "maar eeuwig herbouwen van CMSen" is wellicht een ander topic waard. Qua CSS wil ik het juist allemaal heel standaard houden, het moet gewoon een standaard windows classic look gaan krijgen zodat elke moron een vertrouwd gevoel krijgt bij het werken met het CMS.

[Juup]

Enige nadeel van frames is dat mensen niet de juiste URL in de adresbalk zien en dus ook lastig met bookmarken en URL naar vriendje mailen.

[djluc]

Juup schreef op dinsdag 18 januari 2005 @ 18:42:
Enige nadeel van frames is dat mensen niet de juiste URL in de adresbalk zien en dus ook lastig met bookmarken en URL naar vriendje mailen.

Ik denk niet dat je links naar je CMS wilt mailen

[Not Pingu]

Voor een back-end (want daar gaat het hier om) zijn frames zeker niet verkeerd. Ik gebruik ze ook in mijn CMS en het stelt je toch in staat om een functionele interface te maken. De meeste CMS-en die je her en der kunt downloaden maken gebruik van frames (Typo3 bijvoorbeeld).

[simon]

djluc schreef op dinsdag 18 januari 2005 @ 18:55:
[...]

Ik denk niet dat je links naar je CMS wilt mailen

wel handig als je snel iets wil uitleggen

[Not Pingu]

Simon schreef op dinsdag 18 januari 2005 @ 19:33:
[...]


wel handig als je snel iets wil uitleggen

Lijkt me sterk, sowieso mag iemand alleen op de back-end komen als ie is ingelogd. Als je iemand directe links gaat geven, moet diegene sowieso in kunnen loggen en rechten hebben om datgene wat je linkt te bekijken.

[JHS]

jeanj schreef op dinsdag 18 januari 2005 @ 17:56:
Misschien wil het het over een maand wel als <vul een editor in> uit laten en dan moet je alles weer herbouwen.

Met frames betekent niet zonder css .

[ Voor 30% gewijzigd door JHS op 18-01-2005 19:47 ]

[chris]

Misschien is deze link op useit.com wel interessant.

[simon]

chris schreef op woensdag 19 januari 2005 @ 11:53:
Misschien is deze link op useit.com wel interessant.

beetje outdated

[BtM909]

chris schreef op woensdag 19 januari 2005 @ 11:53:
Misschien is deze link op useit.com wel interessant.

We hebben het hier over een web-appplicatie. Niet over een of andere buzz-site

Ben zelf weinig voorstander van Frames, maar enige gedoe vind ik nog steeds het scripten om pagina updating (links klikken, rechts deels resultaat, rechts klikken, menu updaten, etc).

Voor een CMS kan het handig zijn om frames te gebruiken, simpelweg om de reden dat je sommige dingen altijd zichtbaar wilt houden

[Genoil]

Ik ben inmiddels al voor frames gegaan en tot zover bevalt het prima. Kreeg ook een ideetje om eens korte metten te maken met dat eeuwige gemauw over dat frames niet goed zijn voor een 'normale' website (klik)

[Reinier]

Genoil schreef op woensdag 19 januari 2005 @ 12:19:
Ik ben inmiddels al voor frames gegaan en tot zover bevalt het prima. Kreeg ook een ideetje om eens korte metten te maken met dat eeuwige gemauw over dat frames niet goed zijn voor een 'normale' website (klik)

Normale website?

Hij's wel leuk.

[Verwijderd]

Allereerst is wel mijn vraag, bedoel je puur frames, of iframes?

Waarom niet?
- Je moet de nodige kennis beschikken oa met Javascript om communicatie tussen de frames te laten verlopen.
- Er zitten in zowel Mozilla als IE nasty bugs, mbt base url als je vanuit een ander frame location.replace gebruikt. Ze zijn enorm lastig te reproduceren met een testcase en komen alleen voor als je echt de browsers tot het randje pushed.
- Bij het verlopen van de session moet je individueel controleren of personen nog zijn aangemeld en toegang hebben.
- Zijn iframes van elkaar afhankelijk, of maak je listeners aan mbv javascript, dan moet je zorgen dat je controleerd op beschikbaarheid, en listeners detached bij het verlaten van een iframe/frame.

Waarom wel?
- Zeker bij veel elementen, of intensieve interfaces zijn iframes de ideale manier om load te verdelen.
- Door het gebruik van iframes kun je "multithreaded" componenten inladen in je algehele canvas.
- Je hebt de mogelijkheid een applicatie layered op te zetten, met in de achtergrond ook een persistency layer voor hetgebruik van variabelen (bijv. cut copy & paste) zonder callback naar de server.

Overall, of je het wel of niet gebruikt hangt heel erg af van je applicatie, je kennis van Javascript, en je architectuur.

Wat doe ik zelf: .. ik gebruik iframes heel veel, puur omdat het mij qua verdelen van load voordelen biedt, het hergebruik van pagina's voordelen biedt, en de nadelen voor mij eigenlijk nihil zijn. De user experience van een uitgebreide applicatie die goed is opgebouwd met iframes is velen malen hoger dan die van een applicatie zonder iframes.

[Genoil]

Verwijderd schreef op woensdag 19 januari 2005 @ 12:25:
Allereerst is wel mijn vraag, bedoel je puur frames, of iframes?

puur frames. met name het split-window gedrag van framesets vind ik een pre. iframes zijn zo inflexibel wat dat betreft...

Waarom niet?
- Je moet de nodige kennis beschikken oa met Javascript om communicatie tussen de frames te laten verlopen.

check

- Er zitten in zowel Mozilla als IE nasty bugs, mbt base url als je vanuit een ander frame location.replace gebruikt. Ze zijn enorm lastig te reproduceren met een testcase en komen alleen voor als je echt de browsers tot het randje pushed.

ik heb al redelijk wat ervaring met CMSen in frames (maar was dus toch nog niet 100% overtuigd van het gebruik ervan in m'n nieuwe CMS), maar nog weinig problemen mee gehad. Wat bedoel je specifiek?

- Bij het verlopen van de session moet je individueel controleren of personen nog zijn aangemeld en toegang hebben.

Is een kwestie van een mooie basisklasse CMSPage die op elke request de sessie valideert.

- Zijn iframes van elkaar afhankelijk, of maak je listeners aan mbv javascript, dan moet je zorgen dat je controleerd op beschikbaarheid, en listeners detached bij het verlaten van een iframe/frame.

dit vanwege de memory-overflow bij het attachen van events? ja dat heb ik van jou geleerd

Waarom wel?
- Zeker bij veel elementen, of intensieve interfaces zijn iframes de ideale manier om load te verdelen.

Ik vind load niet het belangrijkste (wel handig uiteraard). Ik gebruik dan ook geen iframes, maar juist frames vanwege split-window effect a la UltraEdit (en ontelbare andere Windows apps). De functionaliteit van de verschillende panes is ook dusdanig verschillend dat het aan de backend mooie gescheiden componenten oplevert.

- Door het gebruik van iframes kun je "multithreaded" componenten inladen in je algehele canvas.

Ja maar daar doe ik het dus niet voor. Maar jij was volgens mij degene die ooit met de term "single-paged-interface" kwam o.i.d.? Wel mooi, maar lastig

- Je hebt de mogelijkheid een applicatie layered op te zetten, met in de achtergrond ook een persistency layer voor hetgebruik van variabelen (bijv. cut copy & paste) zonder callback naar de server.

eh...ja

offtopic:
[quote]
Normale website?

Hij's wel leuk.
[/quote]

Mja als het over load gaat is dit natuurlijk een ramp . De volgende todo qua die site is voor elk framepje een javascript appje maken die zonder verdere servercommunicatie zichzelf kan aanpassen en tegen z'n buren te zeggen dat ze dat moeten doen.

Wat trouwens wel een nadeel bij een Frameset voor een CMS, is dat je geen (cascading) uitklapmenu kunt gebruiken omdat de elementen niet over de "rand" van frames heen kunnen vallen. Maar aangezien ik toch voor een "basic" UI ga, gebruik ik non-cascading <SELECT> voor het "File Edit View" menu.

[ Voor 7% gewijzigd door Genoil op 19-01-2005 13:05 ]

[Verwijderd]

Genoil schreef op woensdag 19 januari 2005 @ 12:53:
puur frames. met name het split-window gedrag van framesets vind ik een pre. iframes zijn zo inflexibel wat dat betreft...

Want? Over het algemeen, voor backends, hoor ik alleen klachten over iframes van mensen die niet goed genoeg thuis zijn in javascript. Wat dat betreft kun je alles met iframes doen wat je wilt.

ik heb al redelijk wat ervaring met CMSen in frames (maar was dus toch nog niet 100% overtuigd van het gebruik ervan in m'n nieuwe CMS), maar nog weinig problemen mee gehad. Wat bedoel je specifiek?

Dat je een location.replace doet in een ander frame, en dat deze prompt een directory lager gaat zoeken naar het bestand. Of twee directories lager, ..etc..

Is een kwestie van een mooie basisklasse CMSPage die op elke request de sessie valideert.

Wel als je login pagina's wilt krijgen in de iframes zelf, niet als je op een nette manier de gebruiker van het systeem de mogelijkheid wil geven om opnieuw in te loggen, of een relocate wil doen naar de beginpagina.

dit vanwege de memory-overflow bij het attachen van events? ja dat heb ik van jou geleerd

Nee puur omdat referenties naar objecten in een ander frame niet meer bestaan. Je moet dus je referenties ook opruimen, en dit houdt in netjes coden en actief memory management.

Ik vind load niet het belangrijkste (wel handig uiteraard). Ik gebruik dan ook geen iframes, maar juist frames vanwege split-window effect a la UltraEdit (en ontelbare andere Windows apps). De functionaliteit van de verschillende panes is ook dusdanig verschillend dat het aan de backend mooie gescheiden componenten oplevert.

Er zijn niet veel applicaties die de browser tot het randje pushen, maar gebruik als voorbeeld eens een listview met 1000 elementen in een pagina met diverse GUI elementen als een treeview, menu, diverse communicatie lagen, als je vervolgens een className wijzigingen gaat doen in die listview dan merk je meteen wat ik bedoel met load verdelen. Je kunt dan gerust een seconde wachten totdat de class inderdaad is gewijzigd.

Ja maar daar doe ik het dus niet voor. Maar jij was volgens mij degene die ooit met de term "single-paged-interface" kwam o.i.d.? Wel mooi, maar lastig

Ik weet niet wie die term heeft bedacht, volgens mij was het Q42 die er voor het eerst mee kwam, ik in ieder geval niet. Ik vind het principe wel heel sterk, maar het is inderdaad geen simpele klus als je er nog geen ervaring mee hebt (tenzij je een kit van Backbase pakt als je er geen tijd voor hebt bijv. ).

Mja als het over load gaat is dit natuurlijk een ramp . De volgende todo qua die site is voor elk framepje een javascript appje maken die zonder verdere servercommunicatie zichzelf kan aanpassen en tegen z'n buren te zeggen dat ze dat moeten doen

Je wil dat helemaal niet zelfs, je wil dat elk element in je webpagina verantwoordelijk is voor jezelf. Vandaar listeners

Wat trouwens wel een nadeel bij een Frameset voor een CMS, is dat je geen (cascading) uitklapmenu kunt gebruiken omdat de elementen niet over de "rand" van frames heen kunnen vallen. Maar aangezien ik toch voor een "basic" UI ga, gebruik ik non-cascading <SELECT> voor het "File Edit View" menu.

En daarom gebruik ik zelf dus iframes in lagen Daarbi is het dus wel crossbrowser mogelijk. Voor IE is het popupObject daarvoor mogelijk maar die kan zelfs buiten browser canvas vallen.

[ Voor 9% gewijzigd door Verwijderd op 19-01-2005 13:12 ]

[Genoil]

Verwijderd schreef op woensdag 19 januari 2005 @ 13:10:
[...]


Want? Over het algemeen, voor backends, hoor ik alleen klachten over iframes van mensen die niet goed genoeg thuis zijn in javascript. Wat dat betreft kun je alles met iframes doen wat je wilt.

Want iframes hebben een vaste afmeting. Tuurlijk kan ik met 2 iframes en een brokje javascript ook wel "split-panes" maken, maar waarom het wiel opnieuw uitvinden?

Dat je een location.replace doet in een ander frame, en dat deze prompt een directory lager gaat zoeken naar het bestand. Of twee directories lager, ..etc..

oh nooit last van gehad.

Wel als je login pagina's wilt krijgen in de iframes zelf, niet als je op een nette manier de gebruiker van het systeem de mogelijkheid wil geven om opnieuw in te loggen, of een relocate wil doen naar de beginpagina.

Mja als je sessie verlopen is schrijf je gewoon een pagina die op onload op het top-level de frameset-reload met in 1 frame de login prompt.

Nee puur omdat referenties naar objecten in een ander frame niet meer bestaan. Je moet dus je referenties ook opruimen, en dit houdt in netjes coden en actief memory management.

Het is m'n doel zo weinig mogelijk logica naar de client toe te halen, dus ik was niet echt van plan dat soort referenties bij te gaan houden.

Er zijn niet veel applicaties die de browser tot het randje pushen, maar gebruik als voorbeeld eens een listview met 1000 elementen in een pagina met diverse GUI elementen als een treeview, menu, diverse communicatie lagen, als je vervolgens een className wijzigingen gaat doen in die listview dan merk je meteen wat ik bedoel met load verdelen. Je kunt dan gerust een seconde wachten totdat de class inderdaad is gewijzigd.

ja ok. maar dit CMS gaat een eenvoudige UI krijgen en is bedoeld voor kleine tot middelgrote websites.

Je wil dat helemaal niet zelfs, je wil dat elk element in je webpagina verantwoordelijk is voor jezelf. Vandaar listeners

eh heb je die 'site' gezien? het zijn 100 frames. Het ultieme doel is een soort modulaire website te maken zonder overkoepelende structuur, maar waarvan de losse onderdelen tegen hun buren zeggen wat ze moeten doen.

[Verwijderd]

Genoil schreef op woensdag 19 januari 2005 @ 13:24:

We praten langs elkaar heen. Ik bedoelde met referenties UI elementen. Als jij in MS Word een tekst selecteerd reageert de UI daarop door diverse menubalken, buttons, knopjes en labels te wijzigen op basis van jouw selectie. Dat bedoelde ik met verantwoordelijkheden, ik leg die verantwoordelijkheid voor status bij een UI element.

Ik heb nog een voorbeeld online staan waarbij er ook een menu over iframes wordt geplaatst.
http://www.mschopman.demon.nl/cms.gif

In dit dhtml menu zorgt elke button voor zichzelf dmv listeners. Ik heb dit ook zelf moeten schrijven aangezien er nog geen enkel menu op het web te vinden is met dergelijke functionaliteit.

[ Voor 15% gewijzigd door Verwijderd op 19-01-2005 13:31 ]