[Javascript] frame onload functie verliezen in frameset?

woensdag 2 december 2009 19:20

Acties:

0 Henk 'm!

Topicstarter

Hallo allen,

Ik bouw een CMS dat gebruik maakt van frames.
Frame 'preview' laat een preview van de website zien waar aan wordt gewerkt.
Frame 'browser' laat een browser zien en laadt eigenschappen van de pagina waaraan wordt gewerkt.

De framesets heb ik gedefinieerd in frames.php. In frames.php worden ook alle javascripts ingeladen in de head.

Onderstaand een samenvatting van de file:

HTML:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">
<html>
    <head>
        ..
        <script language="javascript" type="text/javascript" src="bin/javascript/controllers/framecontroller.js"></script>
        <script language="javascript" type="text/javascript" src="bin/javascript/controllers/previewcontroller.js"></script>
        ..
    </head>
    <frameset name="horizontala" id="structure" rows="*, 25" framespacing="0" frameborder="no" border="0">
        <frameset name="horizontal" id="horizontal" cols="*, 25" framespacing="0" frameborder="no" border="0">
            <frameset name="vertical" id="vertical" rows="*, 0" framespacing="0" frameborder="no" border="0">
            <frame src="../index.php" name="preview" onload="javascript: readyPreview();" >
                <frame src="control.php" name="control" scrolling="no" onload="javascript: readyControl();">
            </frameset>
            <frame src="browser.php" name="browser" scrolling="no" onload="javascript: readyBrowser();">
        </frameset>
        <frame src="taskbar.php" name="taskbar" scrolling="no" >
    </frameset>
</html>

Het systeem werkt lekker: Na het klikken op een link in het preview window (frame 'preview') en het compleet laden van de doel pagina, wordt de functie 'readyPreview()' aangeroepen. De functie staat in previewcontroller.js

JavaScript:

function readyPreview()
{
    current_page_id = frames[0].current_page_id;
    current_language_id = frames[0].current_language_id;
    ready_preview = true;
    
    if(ready_browser) previewLoaded();
    
    if (initload){
        hideTool();
        edit = false;
    }
    readFrame(0);
}

Deze functie zorgt er voor dat de juiste parameters worden doorgegeven voor het laden van o.a. frame 'browser'.

Tot zover werkt het helemaal naar wens en de functie functioneerd naar behoren. Ik kan bewerkingen uitvoeren en de url van frame 'preview' aansturen vanuit frame 'browser' en vice versa etc. Ook kan ik ajax aanroepen doen die een callback hebben naar javascript functies. Alles werkt zoals bedoeld is.

Totdat ik een bepaalde bewerking uitvoer in frame 'browser' middels een ajax methode. De methode is niet anders van opzet dan de anderen. De callback wordt netjes afgehandeld. Deze bewerking voert geen bewerkingen uit op welk DOM element dan ook.

Wanneer ik nu op een link klik in frame 'preview' (of frame 'browser' die de url veranderd van frame 'preview') en er een nieuwe pagina wordt geladen in frame 'preview' krijg ik een error message en wordt de onload functie niet gevonden.

FireBug geeft aan:

code:

1
2
3

readyPreview is not a function 
http://localhost/imagin35/admin/frames.php
Line 1

IE7 Developer tool geeft:

code:

1	Object doesn't support this property or method

Ook Chrome vertikt het om de functie aan te roepen na de desbetreffende ajax bewerking.

Ook bij het intypen van de code 'javascript: readyPreview()' in de adresbalk (top parent niveau: frames.php) krijg ik de foutmelding, waar ik hem voorafgaand niet kreeg (en de functie gewoon werd herkend en uitgevoerd). Ander functies kunnen wel worden aangeroepen.

Als ik mijn DOM inspecteer middels Firebug krijg ik netjes bovenstaande frameset html (dus inclusief onload functies).

Kortom:
- Het verliezen van de onload functie voor frame 'preview' vindt crossbrowser plaats
- Andere functies kunnen gewoon worden aangeroepen (ook functies in previewcontroller.js); script blijft 'intact'.

Heeft iemand een idee wat er hier fout kan gaan waardoor de functie verloren is gegaan?

woensdag 2 december 2009 20:42

Acties:

0 Henk 'm!

Tarilo

Zonder op je vraag in te gaan. Mag ik weten waarom je frames gebruikt? Zeker tegenwoordig lijkt me dat geen voordelen hebben t.o.v. andere methodes.

woensdag 2 december 2009 20:43

Acties:

0 Henk 'm!

HuHu

Sebastiaan11 schreef op woensdag 02 december 2009 @ 19:20:
Hallo allen,

Ik bouw een CMS dat gebruik maakt van frames.
...

En daar gaat het al fout.

Gebruik gewoon geen frames, zeker niet als je de beschikking hebt over een server-side taal als PHP en je bezig bent met iets nieuws bouwen.

woensdag 2 december 2009 22:23

Acties:

0 Henk 'm!

Sebastiaan11

Topicstarter

Ik gebruik frames omdat ik zo de preview -het eindresultaat/website- naast het CMS kan laten draaien. Tevens kan ik via de frameset de child frames uitlezen, en in het geval van de preview 'injecten' met tools waardoor het mogelijk wordt om op een element te clicken en het direct te bewerken in de preview zelf. Ik hoef zo nauwelijks mijn website te laten commiteren aan het CMS.

Begrijp me goed: In de website zelf zal ik echt geen frames opnemen (met uizondering van iframes voor banners). In de CMS komt het juist mooi van pas.

Iemand die wel op de vraag in wil gaan? Ik denk namelijk dat het niet perse hoeft te liggen aan de frameset, daar de functie ook niet meer direct aan te roepen is.

woensdag 2 december 2009 23:04

Acties:

0 Henk 'm!

Sebastiaan11

Topicstarter

Aaargh, wat ik al dacht: Het ligt niet aan de frames.

Ik gebruikte in één van mijn functies een verkeerd geschreven variabele:

JavaScript:

1	readyPreview = false; //ipv ready_preview

Dat zou verklaren waarom er een functie verloren gaat.

Stom, daar ik normaal altijd netjes 'var = foo_bar' en 'function fooBar()' aanhoud...

woensdag 2 december 2009 23:09

Acties:

0 Henk 'm!

TeeDee

CQB 241

HuHu schreef op woensdag 02 december 2009 @ 20:43:
[...]

En daar gaat het al fout.

Gebruik gewoon geen frames, zeker niet als je de beschikking hebt over een server-side taal als PHP en je bezig bent met iets nieuws bouwen.

Waarom zou TS in dit specifieke geval geen frames (mogen) gebruiken? Een live-preview in een frame naast je huidige pagina/editor/whatever heeft imo voldoende legitieme redenen om het zo te doen. Wat dan? 'AJAX', 'XHR', live rendering via een serverside taal?

Heart..pumps blood.Has nothing to do with emotion! Bored

donderdag 3 december 2009 02:28

Acties:

0 Henk 'm!

Verwijderd

Sebastiaan11 schreef op woensdag 02 december 2009 @ 23:04:
Aaargh, wat ik al dacht: Het ligt niet aan de frames.

Frames zijn niet het probleem misschien, maar de interoperabiliteit tussen frames (en misschien zijn er nog meer redenen) belemmeren de maker, in tegenstelling tot bijvoorbeeld een complete 1-pagina opzet en javascript / xml.

[ Voor 7% gewijzigd door Verwijderd op 03-12-2009 02:29 ]

donderdag 3 december 2009 03:05

Acties:

0 Henk 'm!

curry684

left part of the evil twins

Verwijderd schreef op donderdag 03 december 2009 @ 02:28:
[...]

Frames zijn niet het probleem misschien, maar de interoperabiliteit tussen frames (en misschien zijn er nog meer redenen) belemmeren de maker, in tegenstelling tot bijvoorbeeld een complete 1-pagina opzet en javascript / xml.

Met alle respect, maar je hebt net zoals een aantal andere respondenten in dit topic de topicstart simpelweg niet gelezen, of iig niet verder dan HuHu treffend illustreert.

Frames zijn zelden nuttig, meestal ongewenst, maar in zeldzame gevallen zowel wenselijk als nuttig, zoals als je 2 volstrekt ongerelateerde pagina's side-by-side in dezelfde viewport wilt tonen. Laat dat nu exact zijn wat Sebastiaan11 wil.

* curry684 ruikt een enorm 'eval is evil' en 'goto is voor noeps' gehalte in dit topic. Net als die 2 technieken worden frames meestal fout gebruikt, maar alle 3 hebben in uitzonderlijke gevallen hun unieke nut. Er is niets mis met goto, eval of frames, alleen met mensen die ze voor de verkeerde dingen op de verkeerde manier misbruiken. En met de mensen die niet verder kijken dan hun neus lang is bij beoordelen of ze toevallig een keer het goede ding op het goede moment aan het handje hebben

Professionele website nodig?

donderdag 3 december 2009 08:51

Acties:

0 Henk 'm!

HuHu

TeeDee schreef op woensdag 02 december 2009 @ 23:09:
[...]

Waarom zou TS in dit specifieke geval geen frames (mogen) gebruiken? Een live-preview in een frame naast je huidige pagina/editor/whatever heeft imo voldoende legitieme redenen om het zo te doen. Wat dan? 'AJAX', 'XHR', live rendering via een serverside taal?

Zo te zien gebruikt TS frames voor heel wat meer zaken dan alleen de preview. Een live-preview in een frame is inderdaad heel handig, al zou ik dan een iframe gebruiken en de rest gewoon zonder frames doen.

donderdag 3 december 2009 08:54

Acties:

0 Henk 'm!

TeeDee

CQB 241

curry684 schreef op donderdag 03 december 2009 @ 03:05:
[...]

Hmm, dat is eigenlijk wel wat beter dan dat ik het probeerde uit te leggen.

Heart..pumps blood.Has nothing to do with emotion! Bored

donderdag 3 december 2009 19:25

Acties:

0 Henk 'm!

Sebastiaan11

Topicstarter

Mede forum bezoekers, dank voor de feedback en jullie visie.

Ik behoud mijn 'preview' frame, maar heroverweeg het extra nut voor de overige frames. In dit geval komt het heel handig uit in verband van controle houden over de size van de frames waardoor 'hide' effect mogelijk is, maar dat is ook herschrijfbaar.

Wat fl!pull terecht opmerkt is dat de interoperabiliteit tussen frames voor problemen heeft gezorgd. Met name het synchroniseren van processen is een uitdaging.

donderdag 3 december 2009 20:28

Acties:

0 Henk 'm!

Tarilo

Versta me niet verkeerd. Frames kunnen in bepaalde gevallen absoluut een voordeel hebben, maar in dit geval zag ik niet zo snel waarom je in deze situatie frames zou gebruiken.

Daarom mijn vraag en ik ben het met je eens dat dit een treffend voorbeeld is van een goed gebruik van frames.

Pagina: 1

Reageer

Onderwerpen