[JS] location.href stout, verkeerde pad

[Verwijderd]

Ik heb een enorm wazig probleempje. Ben het nog nooit eerder tegengekomen.

Ik heb een pagina waarop 2 iframes aanwezig zijn, als kolommen.
iframe 1: treeview
iframe 2: tabpane

Zodra ik in de treeview een node aanklik, worder er in de pagina (parent van iframe treeview) de attributen van de node in een variabele geplaatst.

Vervolgens wordt de functie editInstance() aangeroepen, die de details van de node in het tabpane iframe opent.

So far so good...

Vervolgens ga ik wat wijzigingen in het tabpane iframe, en doe opslaan. Nu wordt het treeview frame gemeld dat de parentNode van de geselecteerde Node moet worden geselecteerd, en krijgt die een refresh voor zijn kiezen om de childNodes opnieuw in te laden.

Vervolgens wordt opnieuw editInstance() aangeroepen, die de parentNode details opent.

En hier gaat het fout.. zonder enige aanleiding vindt de browser het nodig om 2 niveaus dieper in de directorystructuur te gaan.

Dit is de functie

code:

function editInstance(){
        if(typeof saved_instanceclass == 'undefined'){
            alert('Fout: geen actieve selectie');
            return;
        }
        
        switch(parseInt(saved_instanceclass)){
            case #Request.Config.Form#:
                document.frames["tabpane"].location.href = "keys/form.cfm?instanceid="+saved_instanceid;
                break;
            case #Request.Config.Page#:
                document.frames["tabpane"].location.href = "keys/page.cfm?instanceid="+saved_instanceid;
                break;
            case #Request.Config.Fieldset#:
                document.frames["tabpane"].location.href = "keys/fieldset.cfm?instanceid="+saved_instanceid;
                break;  
            case #Request.Config.Input_Text#:
                document.frames["tabpane"].location.href = "keys/input_text.cfm?instanceid="+saved_instanceid;
                break;
            case #Request.Config.Input_Textarea#:
                document.frames["tabpane"].location.href = "keys/input_textarea.cfm?instanceid="+saved_instanceid;
                break;
            case #Request.Config.Input_Checkbox#:
                document.frames["tabpane"].location.href = "keys/input_checkbox.cfm?instanceid="+saved_instanceid;
                break;
            case #Request.Config.Input_Radio#:
                document.frames["tabpane"].location.href = "keys/input_radio.cfm?instanceid="+saved_instanceid;
                break;
            case #Request.Config.Input_Select#:
                document.frames["tabpane"].location.href = "keys/input_select.cfm?instanceid="+saved_instanceid;
                break;
            case #Request.Config.FreeText#:
                document.frames["tabpane"].location.href = "keys/freetext.cfm?instanceid="+saved_instanceid;
                break;
            default:
                alert('Exception ##23: class niet geregistreerd\n\nDiagnostic information:\ninvoked class = '+saved_instanceclass);
                break;
        }
    }

Als ik nu bijvoorbeeld de case "Page" pak, en hier ga alerten dus:

code:

case #Request.Config.Page#:
alert(document.frames["tabpane"].location.href);
document.frames["tabpane"].location.href = "keys/page.cfm?instanceid="+saved_instanceid;
alert(document.frames["tabpane"].location.href);
break;

krijg ik in de eerste alert, het correcte pad terug. Nu wijzig ik vervolgens alleen de templatename, naar keys.cfm, en wat gebeurt er, deze template wordt 2 directories lager aangeroepen

Is iemand dit probleem bekend?

[WvdWest]

Niet bekend mee. Zou het zo kunnen zijn dat het script kijkt naar de dir van de pagina waarin dit script staat en dus niet naar de dir van de huidige pagina in het frame

bijv

code:

DIR website
       index.html
       DIR subpagina
              inhoud.html
              DIR subsubpagina
                     info.html

Als je nu in index.html een script maakt die info.html moet laden op de plaats waar inhoud.html staat dan zal je vermoedelijk subpagina/subsubpagina/info.html moeten gebruiken ipv subsubpagina/info.html.

Als je de locatie opvraagt van het frame waar inhoud.html in staat, zal je inderdaad de goede locatie terug krijgen. Als je echter de pagina wilt vervangen zal je moeten uitgaan van de root van de pagina waarin het script staat.

HTH

[ Voor 24% gewijzigd door WvdWest op 23-07-2003 10:05 ]

[Verwijderd]

De pagina waarin dit script staat is gelijk, daarom is dit ook zo vaag. De directory framework bestaat wel, maar ligt 2 niveaus dieper.

Als ik echt via bijv. een <a href="javascript:editInstance()">test</a> de functie aanroep wordt wel de goede locatie geladen.

Ik heb sterk het vermoeden dat ik tegen een bug ben aangelopen van de browser, iets icm events, maar kon er niets over vinden op google.

De alert die ik krijg voordat de nieuwe location.href wordt gezet is:
http://ic-sol1/iforms/classes/form_editor/keys/input_text.cfm?instanceid=7A7479

De alert die ik krijg nadat de nieuwe location.href is gezet is:
http://ic-sol1/iforms/classes/framework/keys/page.cfm?instanceid=7A7571

De classes directory structuur is beknopt:
- form_editor
- keys
- framework

Erg vreemd iig.

[ Voor 36% gewijzigd door Verwijderd op 23-07-2003 10:26 ]

[WvdWest]

En als je nou de locatie van de huidige pagina uit het frame leest en vervolgens deze ombouwt tot een statische URL ipv een dynamische? Is wel minder mooi en moet eigenlijk niet nodig zijn maar wellicht helpt het wel

[Verwijderd]

WvdWest schreef op 23 July 2003 @ 10:26:
En als je nou de locatie van de huidige pagina uit het frame leest en vervolgens deze ombouwt tot een statische URL ipv een dynamische? Is wel minder mooi en moet eigenlijk niet nodig zijn maar wellicht helpt het wel

Maakt geen verschil uit. Wat wel verschil uitmaakt, is dat als ik een fully qualified url meegeef, de pagina wel uit het juiste pad wordt gehaald.

Dwz. http://www.domein.nl/ etc...

Maar dit is in principe geen optie, want in één klap is je hele applicatie niet meer schaalbaar.

[Verwijderd]

tenzij... je heel naar een var maakt met fullpath en die er met een var er iedere keer voor zet...

[WvdWest]

Dat bedoelde ik ook. Het is niet mooi en moet zeker anders kunnen maar het zou wel moeten werken. Fullpath kan je weer opvragen met dezelfde methode waarop je nu je alert "vult" zodat het toch nog enigsinds dynamisch is.

[Verwijderd]

Now we're talking

[Verwijderd]

Verwijderd schreef op 23 juli 2003 @ 12:59:
tenzij... je heel naar een var maakt met fullpath en die er met een var er iedere keer voor zet...

Daar heb je wel een punt.. als we elkaar begrijpen bedoel je dus met LastIndexOf() werken

[WvdWest]

Inderdaad. Dat bedoelen wij (toch dannydude )

Zo ben je toch flexibel terwijl je wel met fully qualified url's werkt.

[Verwijderd]

jahoor WvdWest, helemaal op dezelfde lijn

[Verwijderd]

Dan ga ik dat zo is uitproberen, en kom ik er nog op terug.

[Verwijderd]

Nou ik kom er maar weer op terug Ik krijg het voor elkaar om exact dezelfde situatie in een andere app voor elkaar te krijgen.

Wederom een pagina met daarop 2 iframes.

pagina (1)
- > iframe (treeview) (2)
- > iframe (andere zut) (2)

Ik voeg iets toe wat in de treeview moet worden bijgewerkt. Ik roep een functie aan in niveau 1, pagina. Deze functie roept een functie aan in de treeview op niveau 2, en in de treeview iframe wordt een functie aangeroepen die het andere iframe aanpast.

Zolang ik vanuit het treeview iframe een functie aanroep, gaat het prima, anders gaat de browser gewoon lekker 2 directories terug.

Dit gaat dus goed:
iframe treeview -> click op node -> functie in iframe treeview doet document.location in iframe andere zut

Dit gaat dus niet goed:
pagina niveau 1 -> roep functie aan in iframe treeview om node te setten -> functie in iframe treeview doet document.location in iframe andere zut

Ik zou dus momenteel echt niet weten waar het fout gaat. Het lijkt wel of diverse paden in de browser door elkaar worden gewisseld en de browser de weg kwijt is (of het pad...).

[crisp]

document.location is deprecated, het is window.location of document.URL - deze kunnen verschillend zijn (ik zou zelf weer even in de docu moeten duiken om te kijken wat het verschil precies ook alweer was).

[Verwijderd]

crisp schreef op 08 October 2003 @ 10:40:
document.location is deprecated, het is window.location of document.URL - deze kunnen verschillend zijn (ik zou zelf weer even in de docu moeten duiken om te kijken wat het verschil precies ook alweer was).

Ik denk persoonlijk dat het probleem iets te maken heeft met de "referer" van een aanroep op een javascript function. Ik heb alleen geen flauw idee hoe ik het kan omzeilen.

Alle bestanden staat in dezelfde directory:

index.html
en daarin -> iframe:tree.html
-> iframe:canvas.html

Zodra ik vanuit tree.html op een treenode klik, wordt canvas netjes geladen voor de juiste node. Zodra ik dus vanuit index.html, de functie in tree.html aanroep, die canvas.html hoort te laden (volgt u het nog ) krijg ik dus, dat wat normaal http://www.domein.nl/pad1/pad2/pad3 wordt gewijzigd naar http://www.domein.nl/pad1/ terwijl die in pad3 hoort te blijven.

[Hangloozz]

En dat treedt op in alle browsers waarmee je getest hebt?

[Verwijderd]

Hangloozz schreef op 08 October 2003 @ 11:24:
En dat treedt op in alle browsers waarmee je getest hebt?

Ik heb het helaas alleen kunnen testen in MSIE 5.* en 6 omdat het een IE only app betreft.

Ik ben nu bezig met een case, althans dat probeer ik want ik kan de bug hier niet mee reproduceren

Zwaar frusti.. en ik heb al van alles geprobeerd, window.location, document.location, strings replacen, etc. etc.

Enige wat ik nog kan bedenken is voor elke template een base path zetten, maar of dat veel zin heeft.

[Hangloozz]

vaag, ik heb pas ook nog een site gebouwd die helemaal dreef op javascriptnavigatie icm Iframe's maar heb dit niet ondervonden...

De tests die je gedaan hebt, waren die lokaal van een fileserver of op een webserver?
Ik heb weleens gehad dat via een fileserver (C:\\html\mijndoc.html) het zaakje niet goed werkte maar via een webserver wél.

[Verwijderd]

Ik heb ondertussen "iets" gevonden via google, en het moet idd iets te maken hebben met base href's.

Hier spreken ze nog wel over de oude versies, maar er zijn meer onbedoelde "features" meegenomen naar nieuwere versies dus de mogelijkheid zou kunnen bestaan.

"NN 2.02, MSIE3 and Opera can fail to load a page using top.location.href = relative_URL when the parent frame has a different base HREF to the page performing the location change, this is a feature and not a bug, the relative_URL is relative to the top.location and not the current page."

[Verwijderd]

Ik heb heel eventjes een tijdelijke oplossing toegepast. Helaas moet het zo Ik heb Microsoft al gespammed met deze "bug/issue/feature". Misschien komt daar nog wat uit. Het heeft iig iets met het resolven van relative urls te maken bij geneste framesets.

details.location.href = details.location.href.substring(0,details.location.href.lastIndexOf("/")+1) + "details_groups.cfm";