Toon posts:

[javascript] content met script aan innerhtml toekennen

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

Verwijderd

Topicstarter
Hoi,

Ik zit met het probleem dat ik een DIV tag waaraan ik via javascript dynamisch iets in wil zetten. Ik genereer de pagina via JSP, en ik weet van te voren niet wat dat 'iets' is.
Het is iniedergeval URLEncoded en kan van alles bevatten. tekst, tags, etc.

Wat ik doe is een javascript functie gebruiken die dat 'iets' als 1 lange (URLEncoded) string via de innerhtml property in de DIV schrijft.

Ongeveer als volgt:

JavaScript:
1
document.getElementById(ID).innerHTML = URLDecode( mystring );


Mystring kan de meest complexe HTML opmaak bevatten die er te bedenken is en dan nog gaat dit goed. Echter, als er ook maar een klein beetje javascript in voorkomt gaat het helemaal fout.

Ik heb flink gezocht met google, en algemeen wordt aangeraden om de javascript buiten de DIV te houden. Echter, in mijn geval weet ik niet of er javascript in voorkomt. De string ontleden, javascripts eruit halen, renamen, buiten de DIV schrijven via DOM, etc etc... wordt erg snel heel erg vies en complex.

Weet er iemand een makkelijke methode om HTML die javascript bevat via innerhtml aan een DIV toe te kennen?

Verwijderd

Ik kan wel truukjes vinden die werken, maar dan voert hij het script niet meer uit.. heb je dus niets aan.

Denk dus toch dat je de scripts er uit zult moeten filteren, zo smerig hoeft dat toch neit te worden?

Verwijderd

Topicstarter
Het wordt redelijk smerig omdat het niet om 1 DIV gaat maar om meerdere (potentieel oneindig veel) die allemaal stuk voor stuk een stuke code dynamisch inserted krijgen (hoewel slechts 1 tegelijk).

Het werk wat ik dus zou moeten doen is:

1) Alle javascripts eruit filteren (opzich al rottig genoeg)
2) Deze apart direct op de pagina zetten (op een willekeurige plaats)
3) Een unieke naam geven (ze staan nu immers allemaal tegelijk op de pagina)
4) Alle referenties naar het javascript opzoeken in de originele HTML en deze vervangen door de nieuwe naam.

Het simpele alternatief is om een telkens een andere hidden DIV op de pagina te zetten, die hidden te maken, en daar de HTML inclusief javascript direct in schrijven. Ik neem dan de mogelijk dubbele javascript namen even voor lief. Als ik de innerhtml van de ene DIV naar de andere DIV copieer werkt het opzich wel.

Probleem daarmee is dat ondanks het feit dat de 'bron' DIVs hidden zijn, ze toch de layout beinvloeden in alle andere browsers behalve IE.

Ik vraag me eigenlijk ook gewoon af waarom je nou via innerhtml niet direct javascript mag schrijven. Zo'n raar idee is dat toch niet?

Verwijderd

Verwijderd schreef op donderdag 16 december 2004 @ 18:21:
Ik vraag me eigenlijk ook gewoon af waarom je nou via innerhtml niet direct javascript mag schrijven. Zo'n raar idee is dat toch niet?
Volgens mij moet dat toch ook kunnen?
Over wat voor soort javascript praten we? Heb je misschien ergens een voorbeeldje waar het fout gaat?

  • crisp
  • Registratie: Februari 2000
  • Laatst online: 00:54

crisp

Devver

Pixelated

JS die door midel van innerHTML wordt toegevoegd wordt niet uitgevoerd:
code:
1
2
3
4
5
<div id="bla">bla</div>
<script type="text/javascript">
var str = '<scri'+'pt>alert(\'hoi\');</scri'+'pt><h1>kopje</h1>';
document.getElementById('bla').innerHTML = str;
</script>


en voor zover ik weet is daar ook geen eenvoudige workaround voor.

Intentionally left blank


Verwijderd

Topicstarter
Dat was ook mijn eerste reactie "het moet toch kunnen", maar het kan dus niet:

Voorbeeldje:

De code die URLEncoded in een javascript variable staat. Dit is een lange string en deze wordt extern aangeleverd. Decoded ziet het er zo uit:

HTML:
1
2
3
4
<table>
   <script language="javascript" type="text/javascript" src="http://www.example.com/myjava.js"> </script>
<tr><td>dit is een test</td></tr>
</table>


myjava.js bevat alleen een test functie die nog niet eens gebruikt wordt. Bv:

JavaScript:
1
2
3
function bar ( kaz ) {
 var foo = "dit is een test";
}


Volgens de methode die ik in de openings post beschrijf stop ik dan de string in de innerhtml van een DIV. Als ik de <script> tag eruit laat staat de table er gewoon, maar zodra de script tag erin komt wordt er niks op het scherm gezet. Zoals duidelijk, het script doet feitelijk nix en wordt ook niet aangeroepen. Alleen de aanwezigheid van script is al voldoende om de boel te frustreren. Ik heb overigens getest met Firefox 1.0, IE6.0 en Mozilla 1.7.

Verwijderd

Topicstarter
crisp schreef op donderdag 16 december 2004 @ 18:41:
JS die door midel van innerHTML wordt toegevoegd wordt niet uitgevoerd:
[...]
en voor zover ik weet is daar ook geen eenvoudige workaround voor.
Daar was ik al bang voor na mijn zoektocht op het web :(

De enige andere methode die werkte op deze manier was om (serverside) het stuk HTML wat script bevat in een hidden DIV te zetten, maar dit vind ik niet super mooi plus dat het ook niet altijd werkt (maar iniedergeval werkt het wel met javascript content).

Zijn er nog andere manieren om content dynamisch in een DIV te krijgen?

  • Wolfboy
  • Registratie: Januari 2001
  • Niet online

Wolfboy

ubi dubium ibi libertas

Ik kan eigenlijk alleen serverside manieren bedenken, of je zou een iframe in een div moeten zetten maar of je dat wil :/

Blog [Stackoverflow] [LinkedIn]


  • crisp
  • Registratie: Februari 2000
  • Laatst online: 00:54

crisp

Devver

Pixelated

Verwijderd schreef op donderdag 16 december 2004 @ 18:48:
Dat was ook mijn eerste reactie "het moet toch kunnen", maar het kan dus niet:

Voorbeeldje:

De code die URLEncoded in een javascript variable staat. Dit is een lange string en deze wordt extern aangeleverd. Decoded ziet het er zo uit:

HTML:
1
2
3
4
<table>
   <script language="javascript" type="text/javascript" src="http://www.example.com/myjava.js"> </script>
<tr><td>dit is een test</td></tr>
</table>

[...]
In mijn voorbeeld wordt de <h1> wel degelijk geschreven. Bedenk echter dat het voorbeeld wat je nu geeft in feite gewoon invalid HTML is: een script-tag mag niet tussen een table en een tr-tag in voorkomen :)

De meest eenvoudige oplossing lijkt me gewoon alle script-tags te strippen met een eenvoudige reguliere expressie.

Intentionally left blank


Verwijderd

Topicstarter
Serverside kun je natuurlijk alles erin stoppen, maar waar het om gaat is dat ik (serverside) een soort 'repository' van content aan maak op de pagina. De gebruiker kan dan met een druk op de knop deze content zichtbaar maken in een van de DIVjes op de pagina.

Server side zou ik dit ook kunnen realiseren door het geheel een form te maken zodat de druk op de knop een request wordt naar de server die dan de juiste content op de juiste plek zet. (de pagina wordt er dan ook nog eens kleiner van). Helaas vond 'men' (mijn opdracht gevers) dat dat niet acceptabel was.

Op de innerhtml manier werkt het echt instant. Zeer jammer dat javascript nou weer roet in het eten moet gooien. Als ik de content niet in javascript variablen stop maar in hidden DIVjes werkt het wel. Vreemd genoeg beinvloeden deze in mozilla en firefox af en toe de layout (ook al zijn ze hidden). In IE gebeurt dit nooit.

Zijn er hier andere mensen die het ook zo doen? Content in een hidden DIV zetten en dan via javascript overcopieeren naar een zichtbare DIV?

Verwijderd

Topicstarter
crisp schreef op donderdag 16 december 2004 @ 19:19:
[...]

In mijn voorbeeld wordt de <h1> wel degelijk geschreven. Bedenk echter dat het voorbeeld wat je nu geeft in feite gewoon invalid HTML is: een script-tag mag niet tussen een table en een tr-tag in voorkomen :)
Inderdaad! Het jammere is dat ik zoals ik al eerder zei geen enkele invloed op de content heb. De opdracht gever kijkt er alleen naar of het stuk HTML het 'los' wel doet. Is dat het geval dan is het voor hem een zaak dat ik het niet goed doe :(
De meest eenvoudige oplossing lijkt me gewoon alle script-tags te strippen met een eenvoudige reguliere expressie.
Dat lijkt me inderdaad het beste en dat was ik ook al van plan te doen. Om het geheel functioneel te houden zet ik dan, server side, de script code los op de pagina. Ik zit alleen een beetje met de situatie van dubbel voorkomende functie namen, of nog erger variable namen.

Als er een methode was om dynamisch javascript op een pagina te zetten, en uitvoerbaar te maken dan had je nooit een probleem als je maar 1 stuk tegelijk erop zet. Nu komt alle javascript er dus tegelijk op te staan en dat kan zeker conflicten gaan opleveren. Alles renamen kan alleen sluitend als ik server side een echte javascript parser heb waarbij ik de syntax tree kan doorlopen. Tis niet onmogelijk, maar gaat voor nu wellicht even te ver.

Verwijderd

Ga lekker je opdrachtgever vertellen dat hij geen JavaScript moet gebruiken in z'n code. Is het zo moeilijk om dat van hem te vragen? :?
Sommige dingen *kunnen* gewoon niet op een fatsoenlijke manier. Je moet je nu in allerlei bochten wringen om de fouten die je opdrachtgever maakt te corrigeren.

Zoals je zelf aangeeft blijf je problemen houden met methodes en variabelnamen. Dé ideale oplossing is er dus niet... helaas

[ Voor 19% gewijzigd door Verwijderd op 16-12-2004 21:05 ]


Verwijderd

Topicstarter
Verwijderd schreef op donderdag 16 december 2004 @ 21:03:
Ga lekker je opdrachtgever vertellen dat hij geen JavaScript moet gebruiken in z'n code. Is het zo moeilijk om dat van hem te vragen? :?
Sommige dingen *kunnen* gewoon niet op een fatsoenlijke manier. Je moet je nu in allerlei bochten wringen om de fouten die je opdrachtgever maakt te corrigeren.
*lach* Ik zou het graag doen maar dat is echt onmogelijk. Het gaat om een soort content management systeem waar content inzit die gewoon javascript bevat. De plek waar die content neergezet wordt *zou* het ook geen probleem moeten zijn, maar gelukkig heb ik daar helemaal niks mee te maken.

Het deel waar ik wel mee te maken heb is een soort van previewer voor alle stukjes content die in de DB staan.

Overigens is het zelfs de opdrachtgever zelf niet die perse javascript wil. Dat zijn weer zijn gebruikers die dat in het systeem stoppen. Maw, zelfs de opdrachtgever weet niet welke content er allemaal in gaat komen. Natuurlijk moet het wel redelijk blijven, als iets echt niet haalbaar is dan zeg ik dat ook zeker.

Verwijderd

Topicstarter
Gerelateerd aan dit, ik merk nu ook dat innerhtml niet werkt met een <form> tag die binnen een table staat.

Dus:

code:
1
2
3
4
5
<table>
<form>
...
</form>
</table>


Werkt niet (plek van de DIV blijft leeg) als ik dit er via innerhtml inzet, terwijl dezelfde HTML constructie ander wel zichtbaar is. Als de form tag buiten de table staat, werkt het wel, en weer, als ik vanaf een andere DIV copieer werkt het ook. 8)7

Concreet voorbeeld. Deze werkt niet:

HTML:
1
2
3
4
5
<div id="bla">bla</div>
<script type="text/javascript">
var str = '<table><form action="iets.html"><tr><td>data</td></tr></form></table>';
document.getElementById('bla').innerHTML = str;
</script>


Maar deze wel:

HTML:
1
2
3
4
5
<div id="bla">bla</div>
<script type="text/javascript">
var str = '<form action="iets.html"><table><tr><td>data</td></tr></form></table>';
document.getElementById('bla').innerHTML = str;
</script>


Ik kan natuurlijk ook wel weer deze mogelijkheid gaan afvangen door het weer te parsen en forms voor tables te zetten, maar het is toch raar dat het HTML is wat het opzich doet in de browser, maar dan via innerhtml niet werkt?

[ Voor 142% gewijzigd door crisp op 17-12-2004 12:28 . Reden: sorry, deed edit ipv quote :o ]


Verwijderd

Ik heb ooit een tokenizer voor JavaScript geschreven die een String interpreteert en er een nette Array van maakt en alle attributen matched etc. Misschien kan je die porten naar PHP en op die manier alle javascript filteren...

Verwijderd

Verwijderd schreef op vrijdag 17 december 2004 @ 00:29:
Misschien kan je die porten naar PHP en op die manier alle javascript filteren...
Je aanbod is vriendelijk, maar wie zegt dat TS PHP gebruikt? Het kan toch ook ASP of JSP zijn (of mischien nog wel wat anders)

  • crisp
  • Registratie: Februari 2000
  • Laatst online: 00:54

crisp

Devver

Pixelated

Verwijderd schreef op donderdag 16 december 2004 @ 23:01:
Gerelateerd aan dit, ik merk nu ook dat innerhtml niet werkt met een <form> tag die binnen een table staat.

Dus:

code:
1
2
3
4
5
<table>
<form>
...
</form>
</table>


Werkt niet (plek van de DIV blijft leeg) als ik dit er via innerhtml inzet, terwijl dezelfde HTML constructie ander wel zichtbaar is. Als de form tag buiten de table staat, werkt het wel, en weer, als ik vanaf een andere DIV copieer werkt het ook. 8)7
[...]

Dat heeft dan ws ook weer te maken met het feit dat het invalid HTML is ;)

Als dat zo uit een CMS komt rollen dan zou ik de leverancier van dat CMS daar maar eens op gaan wijzen...

[ Voor 10% gewijzigd door crisp op 17-12-2004 12:29 ]

Intentionally left blank


  • flowerp
  • Registratie: September 2003
  • Laatst online: 04-02 02:01
Toch is het merkwaardig dat een HTML constructie die elke browser wel accepteerd als het direct in de body staat, opeens niet meer geaccepteerd wordt als het via innerhtml gezet wordt. Dat is gewoon inconsequent gedrag van browsers. HTML is valid of invalid. Het mag niet zo zijn dat het via de ene methode afgekeurd wordt en via de andere methode niet.

Ik vraag me af wat er gebeurd als je hetzelfde stuk HTML, dus met de <form> binnen de <table>, via DOM dynamisch opbouwt. Gaat het dan ook fout? (zal het zelf ook eens gaan proberen)

It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.


  • Fuzzillogic
  • Registratie: November 2001
  • Laatst online: 01-07-2025
Let ook op dat innerHTML (en outerHTML) helemaal niet volgens de standaards is. De browsers ondersteunen dit wel, maar eigenlijk dien je de W3C DOM hiervoor te gebruiken.. Met echt XHTML werkt innerHTML waarschijnlijk zelfs helemaal niet.

  • crisp
  • Registratie: Februari 2000
  • Laatst online: 00:54

crisp

Devver

Pixelated

Nexxennium schreef op zaterdag 18 december 2004 @ 13:04:
Let ook op dat innerHTML (en outerHTML) helemaal niet volgens de standaards is. De browsers ondersteunen dit wel, maar eigenlijk dien je de W3C DOM hiervoor te gebruiken.. Met echt XHTML werkt innerHTML waarschijnlijk zelfs helemaal niet.
Klopt, bij XHTML met de juiste mimetype kan je alleen nog maar innerHTML uitvragen, maar niet wijzigen. Ook document.write() kan niet meer in XHTML.
flowerp schreef op zaterdag 18 december 2004 @ 12:58:
Toch is het merkwaardig dat een HTML constructie die elke browser wel accepteerd als het direct in de body staat, opeens niet meer geaccepteerd wordt als het via innerhtml gezet wordt. Dat is gewoon inconsequent gedrag van browsers. HTML is valid of invalid. Het mag niet zo zijn dat het via de ene methode afgekeurd wordt en via de andere methode niet.

Ik vraag me af wat er gebeurd als je hetzelfde stuk HTML, dus met de <form> binnen de <table>, via DOM dynamisch opbouwt. Gaat het dan ook fout? (zal het zelf ook eens gaan proberen)

Ik denk dat je het via DOM ook niet zal lukken. Browsers passen waarschijnlijk bij het setten van innerHTML al error-correctie toe.
Inconsequent of niet, invalid HTML blijft invalid en het is dus geen excuus dat het bij 'normaal' gebruik wel werkt en op een andere manier opeens niet...

Intentionally left blank


  • flowerp
  • Registratie: September 2003
  • Laatst online: 04-02 02:01
De inconsequentie is mischien nog niet eens technisch zo raar (invalid is vaak undefined behaviour = alles kan gebeuren, werken, niet werken, of soms wel soms niet), maar het is wel een sociaal probleem:

Gebruikers vinden dat hun HTML goed is, want ze hebben het op meerdere browsers geprobeerd (en dat zijn dan nog schappelijkere mensen dan diegenen het alleen op IE geprobeerd hebben). Echter, als het met JOUW javascript methode niet werkt om het op het scherm te krijgen dan ben JIJ een webdesigner of programmeur van likmevesie.

Ik heb zelf ook een aantal keren in de korte periode dat ik werk (1 jaar) met klanten en een manager overhoop gelegen over vergelijkbare issues.

Toch vind ik het wel vreemd dat de gangbare browsers dan niet tenminste een warning geven zodat jij als designer de klant kunt laten zien dat een browser het wel toevallig pikt maar dat het toch echt geen correcte HTML is.

It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.


  • crisp
  • Registratie: Februari 2000
  • Laatst online: 00:54

crisp

Devver

Pixelated

flowerp schreef op zaterdag 18 december 2004 @ 14:06:
[...]Toch vind ik het wel vreemd dat de gangbare browsers dan niet tenminste een warning geven zodat jij als designer de klant kunt laten zien dat een browser het wel toevallig pikt maar dat het toch echt geen correcte HTML is.
Maar dat zou je zelf in kunnen bakken ;)

Intentionally left blank

Pagina: 1