mboost-dp1
JavaScript åben en ny boks
Jeg vil anbefale dig at kigge på jQuery det gør bare livet meget nemmere når du skal lave javascript ting.
Herefter kan du bare google på det du skal bruge og så finder du næsten helt sikkert nogen der har løst problemet.
Hvis du stadig ikke finder noget, så skriv her igen så skal jeg nok lige lave lidt html og js til dig der kan det du beskriver.
Herefter kan du bare google på det du skal bruge og så finder du næsten helt sikkert nogen der har løst problemet.
Hvis du stadig ikke finder noget, så skriv her igen så skal jeg nok lige lave lidt html og js til dig der kan det du beskriver.
Rent teknisk er det jo bare at rendere et DIV element med position: absolute og et z-index højere end nul.
Men man plejer at få javascript til at gøre det. Dog er det godt at kende det grundlæggede bag ved.
Prøv f.eks. at køre følgende på en ny side:
Men man plejer at få javascript til at gøre det. Dog er det godt at kende det grundlæggede bag ved.
Prøv f.eks. at køre følgende på en ny side:
<div style="position: absolute; z-index: 10; margin: 10px; width: 90%; height: 90%; background: blue;">foobar!</div>
Jo det har jeg sådan set... Kan selvfølgelig godt ske at jeg har misforstået OP... Men hvis han dynamisk vil opdatere siden uden et refresh er AJAX vel mere eller mindre den eneste måde, at du så kan bruge jquery for at gøre dit arbejde lettere er så en anden sag...
Efter nærmere granskning af OP og din post så er jeg ret forvirret... Han efterspørger javascript der dynamisk tilføjer nyt indhold uden refresh og du giver ham et flot kodeeksempel på en DIV med absolut position
Efter nærmere granskning af OP og din post så er jeg ret forvirret... Han efterspørger javascript der dynamisk tilføjer nyt indhold uden refresh og du giver ham et flot kodeeksempel på en DIV med absolut position
Det er rigtigt.. My bad, skulle have formuleret mig bedre.. Og mente selvfølgelig XMLHttpRequest.. Ikke godt at skrive på forummer før den første morgen kaffe er indenbords..
(Har IE forresten ikke fået understøttelse af XMLhttpRequest fra og med version 7?)
(Har IE forresten ikke fået understøttelse af XMLhttpRequest fra og med version 7?)
Han efterspørger jo muligheden for at åbne en box et vilkårligt sted på siden, istedet for et nyt vindue.reefermadness (7) skrev:Han efterspørger javascript der dynamisk tilføjer nyt indhold uden refresh og du giver ham et flot kodeeksempel på en DIV med absolut position
Denne boks kunne i princippet indeholde en iframe, som viste den anden side. Der er ingen grund til at overdrive med javascript hvis man kan undgå det.
Og jeg bryder mig ikke om når AJAX benyttes som buzzword for hvad der er alm. javascript og ikke nødvendigvis udnytte xmlhttprequests overhovedet.
Ligesom man entligt heller ikke benytter XML i AJAX requests mere, så det burde omdøbes til AJAJ (J = Json)
du har ret!..
Hader også selv AJAX buzzwordet (WEB 2.0 mig i røveren :-P, endnu et klamt buzzword..)!
Men det er nu engang det folk forstår..
Man kunne bruge iframes, men ikke ligefremt optimalt.. "forespørgelsen" ville f.eks kunne ses i browser historikken + en del andre ulemper.. Bla problemer med browserens cache..
Man behøver vel egentlig heller ikke kaste sig ud i det vilde javascript for at lave det han vil, men det letteste ville vel være at udnytte xmlhttprequest, hvis det endelig skulle laves i javascript.
Hader også selv AJAX buzzwordet (WEB 2.0 mig i røveren :-P, endnu et klamt buzzword..)!
Men det er nu engang det folk forstår..
Man kunne bruge iframes, men ikke ligefremt optimalt.. "forespørgelsen" ville f.eks kunne ses i browser historikken + en del andre ulemper.. Bla problemer med browserens cache..
Man behøver vel egentlig heller ikke kaste sig ud i det vilde javascript for at lave det han vil, men det letteste ville vel være at udnytte xmlhttprequest, hvis det endelig skulle laves i javascript.
Windcape (11) skrev:
Ligesom man entligt heller ikke benytter XML i AJAX requests mere, så det burde omdøbes til AJAJ (J = Json)
Dem der vil have max. hastighed på deres AJAX bruger sikkert JSON.
Dem der går ind for reusable server side kode og et højt sikkerhedsnoveau foretrækker XML.
Windcape (14) skrev:Nu er det vist kun Java som ikke har standard JSON bindings, så det tvivler jeg på.
...
Ahemmm.....
http://www.json.org/
har du lyst til at tage den udtalelse op til overvejelse, igen?
Nej, det har jeg ikke, da jeg skrev standard.
ASP.NET har JSON som en mulighed i AJAX.NET og WebServices, og PHP5 har det indbygget i json_encode og json_decode
Og hvis min hukommelse ikke svigter mig som har ruby og python samme muligheder.
Java tilgengæld, er ikke blevet opdateret i et århundrede, så der skal du ud og finde 3rd parts biblioteker.
Men så igen, Java's XML standard xml biblioteker er bygget på beans modellen, og har et ligeså elendigt output, så de skal ud og finde 3rd parts stuff under alle omstændigheder.
(XStreams er meget populært til begge dele)
ASP.NET har JSON som en mulighed i AJAX.NET og WebServices, og PHP5 har det indbygget i json_encode og json_decode
Og hvis min hukommelse ikke svigter mig som har ruby og python samme muligheder.
Java tilgengæld, er ikke blevet opdateret i et århundrede, så der skal du ud og finde 3rd parts biblioteker.
Men så igen, Java's XML standard xml biblioteker er bygget på beans modellen, og har et ligeså elendigt output, så de skal ud og finde 3rd parts stuff under alle omstændigheder.
(XStreams er meget populært til begge dele)
For at uddybe overstående lidt:
Jeg forventer at et framework som enten er Web Orienteret (PHP/ASP.NET) eller har en Web Orienteret del (Java, Python, Rails) bliver opdateret jævnligt for at holde sig trit med moderne standard teknikker.
Det er rart at man ikke skal downloade et bibliotek lavet af en eller anden studerende på den anden side af jorden, for at lave noget meget gængs, som f.eks. JSON eller XML.
Det er samme grund til at Microsoft har valgt at shippe JQuery med ASP.NET MVC frameworket. Med forbedret dokumentation og intellisense. (Kom ind i kampen Eclipse!)
Jeg er ikke synderligt imponeret over SUNs måde at opdatere deres framework (Java).
Det er en absolut nødvendighed at have opdateringer når nye teknologier bliver standard, altså gerne en eller flere gange om året.
(Og så at putte alt nyt de sidste 5 år i java.util er en dårlig måde at gøre detpå).
Jeg forventer at et framework som enten er Web Orienteret (PHP/ASP.NET) eller har en Web Orienteret del (Java, Python, Rails) bliver opdateret jævnligt for at holde sig trit med moderne standard teknikker.
Det er rart at man ikke skal downloade et bibliotek lavet af en eller anden studerende på den anden side af jorden, for at lave noget meget gængs, som f.eks. JSON eller XML.
Det er samme grund til at Microsoft har valgt at shippe JQuery med ASP.NET MVC frameworket. Med forbedret dokumentation og intellisense. (Kom ind i kampen Eclipse!)
Jeg er ikke synderligt imponeret over SUNs måde at opdatere deres framework (Java).
Det er en absolut nødvendighed at have opdateringer når nye teknologier bliver standard, altså gerne en eller flere gange om året.
(Og så at putte alt nyt de sidste 5 år i java.util er en dårlig måde at gøre detpå).
Jeg synes ikke jeg kan se at det skal være et problem at benytte sig af et 3. parts lib. Der er bare nogle ting der ikke høre til default API'et ved et programmeringssprog.
Java er heller ikke synderligt rettet imod web udvikling, men er noget mere versitilt, og kan også bruges til desktopapplikations udvikling.
At man skulle opdatere et programmeringssprog eller framework flere gange om året ville blive et mareridt. Tænk på de compatibility problemer der skulle tages højde for.
Når nu alt kommer til alt, så må jeg jo acceptere at du foretrækker andre frameworks og programmeringssprog frem for java, men det er vel også derfor der er en del sprog at vælge imellem.
Hvis du nu alligevel skulle være interesseret i at snuse mere til java relaterede teknologier, så kan jeg anbefale dig at kigge på Grails (Groovy baseret rapid development framework) - der er JSON understøttelse i hvert fald med (som standard).
Java er heller ikke synderligt rettet imod web udvikling, men er noget mere versitilt, og kan også bruges til desktopapplikations udvikling.
At man skulle opdatere et programmeringssprog eller framework flere gange om året ville blive et mareridt. Tænk på de compatibility problemer der skulle tages højde for.
Når nu alt kommer til alt, så må jeg jo acceptere at du foretrækker andre frameworks og programmeringssprog frem for java, men det er vel også derfor der er en del sprog at vælge imellem.
Hvis du nu alligevel skulle være interesseret i at snuse mere til java relaterede teknologier, så kan jeg anbefale dig at kigge på Grails (Groovy baseret rapid development framework) - der er JSON understøttelse i hvert fald med (som standard).
Næsten alting de laver i dag er rettet mod webudvikling.Corholio (18) skrev:Java er heller ikke synderligt rettet imod web udvikling, men er noget mere versitilt, og kan også bruges til desktopapplikations udvikling.
GUI i java laves mere og mere i SVG end i Swing, og SVG er altså ikke en del af standard Java.
Microsoft klarer det da ganske fint. (Og PHP gør også).Corholio (18) skrev:At man skulle opdatere et programmeringssprog eller framework flere gange om året ville blive et mareridt. Tænk på de compatibility problemer der skulle tages højde for.
Windcape (19) skrev:Næsten alting de laver i dag er rettet mod webudvikling.
Hrmmm... hvem er de? For Sun targeter så vidt jeg kan se ikke web-platforme specifikt - eller måske skulle jeg hellere sige at jeg ikke kan se de er begyndt at favorisere web-platforme.
Windcape (19) skrev:GUI i java laves mere og mere i SVG end i Swing, og SVG er altså ikke en del af standard Java.
Nej... SVG bruges til vektor-baseret grafik, ikke til grafiske brugergrænseflader (jeg skal ikke udelukke at det kan gøres, har bare ikke hørt om det før). Derudover er SVG er XML-baseret, Java har understøttelse for SVG - ergo, Java understøtter SVG (det bliver nemmere med Batik som 3rd party lib.
Swing er stadigvæk ganske populært, og det bliver spændende at se deres applikations framework i Java 7.
Windcape (19) skrev:Microsoft klarer det da ganske fint. (Og PHP gør også).
.NET framework versions liste
Jeg går ud fra at de releases der er lavet indenfor samme år er bugfix releases. Jeg tvivler på at der er kommet ny funktionalitet til i løbet af dem. PHP.... ja, "don't get me started", hehe :)
Sorry, jeg mente SWT. (Standard Widget Toolkit).
Hvorfor så mange vælger at ignorer det er mig en gåde.
Men folk har vel en grund til at vælge hamrende langsomme og ustabile Java EE løsninger, som koster millioner mere i licenser :)
PHP benyttes til mange betydelige store sites.Corholio (20) skrev:PHP.... ja, "don't get me started", hehe :)
Hvorfor så mange vælger at ignorer det er mig en gåde.
Men folk har vel en grund til at vælge hamrende langsomme og ustabile Java EE løsninger, som koster millioner mere i licenser :)
Windcape (21) skrev:Sorry, jeg mente SWT. (Standard Widget Toolkit).
Okay, så er jeg med. SWT er udemærket til at lave brugergrænseflader med, men er begrænset til flere platforme end der findes JVM'er til. (og ja, jeg har hørt om ordsproget der siger at: "At sige at java er godt fordi det virker på flere platforme, er som at sige at analsex er godt fordi det virker på flere køn" :)
Windcape (21) skrev:PHP benyttes til mange betydelige store sites.
Hvorfor så mange vælger at ignorer det er mig en gåde.
Jeg ignorerer ikke at PHP har sin plads. Jeg vil heller ikke ignorere at PHP vil kunne bruges til store sites.
Jeg har bare nogle problemer med PHP:
- Selvom du bruger et MVC framework (jeg foretrækker selv CodeIgniter og CakePHP) kan du lave noget rod, da intet forhindrer dig i at inkludere en random side med kildekode.
- Grundet at PHP er så typeløst et sprog og tillader at lave introspection baseret på tekststrenge:
$boo = 'FooClass';
$instance = new $boo;
Bliver IDE-support en noget tvivlsom affære (jeg har forsøgt mig med Zend Developer Studio, PDT (Eclipse og er ikke imponeret).
- Du er afhængig af at moduler er installeret på din apache webserver (lidt den samme problematik som du ser ud til at ha' med 3rd party komponenter).
- Safemode (hvorfor dælen eksisterer det? Jeg er klar over at der er planer om at afskaffe det i PHP 6).
- Der er ingen support for pakker i PHP (foldere er ikke pakker, da intet i kildekoden angiver kodens placering).
- Fejlbeskeder i PHP er nær "sort snak" - her er Google min ven, men alligevel.
Windcape (21) skrev:Men folk har vel en grund til at vælge hamrende langsomme og ustabile Java EE løsninger, som koster millioner mere i licenser :)
Jeg har set din smiley, så jeg kan godt ane en smule sarkasme.
En applikationesserver kan godt være gratis, så der er ingen grund til at betale licenser i million-vis. Her tænker jeg på Tomcat, Resin, JBoss, Jetty osv. osv.
Java er ikke betydeligt langsommere end PHP - men bruger til gengæld en del mere hukommelse.
Jeg vil påstå at stabilitet ikke har noget med programmeringssproget at gøre, men derimod selve kvaliteten af koden bag applikationen samt valg af framework.
Nu har java også nogle af de samme problemer. Ved pakker vil jeg personligt hellere have rigtig namespaces som i C++ og C#.
Og nu er et JSP stacktrace heller ikke særlig brugbart, samt at du låser dig typisk til de moduler du installere på din application server.
Og lige mht. SWT, så er der er altså minimalt hvor mange der udvikler enterprise niveau applications med henblik på forskellige platforme.
Typisk har du allerede valg og betalt for en given platform inden projektet overhovedet starter. Fordi typisk skal du alligevel bruge noget 3. parts software som kræver en bestemt platform (Database Servers anyone?). Så det er altså en dårlig undskyldning, der bruges alt for meget.
Derudover vil jeg vuderer at Mono er ligeså cross-platform kompatibelt som Java til gængse program typer.
Og om man så vil se at det er SUN eller "random script kiddie" som har lavet ens bibliotek som en sikkerhed for god kode, er op til en selv.
Og nu er et JSP stacktrace heller ikke særlig brugbart, samt at du låser dig typisk til de moduler du installere på din application server.
Og lige mht. SWT, så er der er altså minimalt hvor mange der udvikler enterprise niveau applications med henblik på forskellige platforme.
Typisk har du allerede valg og betalt for en given platform inden projektet overhovedet starter. Fordi typisk skal du alligevel bruge noget 3. parts software som kræver en bestemt platform (Database Servers anyone?). Så det er altså en dårlig undskyldning, der bruges alt for meget.
Derudover vil jeg vuderer at Mono er ligeså cross-platform kompatibelt som Java til gængse program typer.
Det kan vi godt blive enige om.Corholio (22) skrev:Jeg vil påstå at stabilitet ikke har noget med programmeringssproget at gøre, men derimod selve kvaliteten af koden bag applikationen samt valg af framework.
Og om man så vil se at det er SUN eller "random script kiddie" som har lavet ens bibliotek som en sikkerhed for god kode, er op til en selv.
Windcape (23) skrev:Og nu er et JSP stacktrace heller ikke særlig brugbart.
Øhhh...du får lige nøjagtigt at vide hvor fejlen opstod (eller hvor den skyldige exception blev kastet). Så bliver det vist ikke mere brugbart?
Windcape (23) skrev:samt at du låser dig typisk til de moduler du installere på din application server
I modsætning til hvilken anden platform, hvor man ikke låser sig til de moduler man installerer på sin server?
Windcape (23) skrev:Og om man så vil se at det er SUN eller "random script kiddie" som har lavet ens bibliotek som en sikkerhed for god kode, er op til en selv.
Jeg vil altid foretrække biblioteker / API'er der er udviklet af firmaet som opfandt programmeringssproget, frem for en "random script kiddie". Nok ligesom du foretrækker Microsofts API implementation af JSON (de)-serialisering, fremfor de 3rd. parts libs jeg linkede til (json.org).
Windcape (14) skrev:Nu er det vist kun Java som ikke har standard JSON bindings, så det tvivler jeg på.
JSON encode and decode er ikke en del af hverken Java SE API eller Java EE API, men der er masse af Java implementationer.
Corholio har allerede nævnt json.org, men der er også andre: XStream, GWT, RichFaces etc..
Du kan også få JSON til C.
Men det ændrer ikke på at JSON er en JavaScript web lightweight thingy.
Som data format for noget SOA/ESB/WS vælger man XML.
Windcape (14) skrev:Derudover er sikkerheden det samme, hvis man ved hvad man laver.
Ingen som ved hvad de laver vælger teknologi og arkitektur udfra en en forudsætning om at udviklere ikke laver fejl.
Erfaringen vise nemlig at det gør de. Tommelfinger reglen siger 1 fejl per 1000 linier kode.
Derfor skal man kode defensivt således at en enkelt fejl ikke totalt gennemhuller ens sikkerhed.
Bruge et format der er eksekverbart kode er en helt unødvendig risiko.
Windcape (16) skrev:Java tilgengæld, er ikke blevet opdateret i et århundrede, så der skal du ud og finde 3rd parts biblioteker.
Windcape (17) skrev:
Jeg er ikke synderligt imponeret over SUNs måde at opdatere deres framework (Java).
Det er en absolut nødvendighed at have opdateringer når nye teknologier bliver standard, altså gerne en eller flere gange om året.
Stort set kører Java med samme opdaterings interval som Microsoft.
Microsoft har opdateret 4 gange på 7 år.
SUN har opdateret 6 gange på 13 år.
Windcape (16) skrev:Men så igen, Java's XML standard xml biblioteker er bygget på beans modellen,
Java har flere XML biblioteker:
W3C DOM - ikke bean baseret
SAX - ikke bean baseret
StAX - ikke bean baseret
JAXB - bean baseret
Meget langtfra at alle er bean baseret!
Windcape (17) skrev:(Og så at putte alt nyt de sidste 5 år i java.util er en dårlig måde at gøre detpå).
Et hurtigt kig siger at:
- 1.5 tilføjede bl.a. til java.lang, java.util, java.util.concurrent, og java.lang.management
- 1.6 tilføjede bl.a. til java.net, javax.script, javax.xml og javax.tools
Meget langtfra at alt er i java.util!
Windcape (21) skrev:Men folk har vel en grund til at vælge hamrende langsomme og ustabile Java EE løsninger, som koster millioner mere i licenser
Java EE løsninger er uhyre sjældent ustabile.
Java EE løsninger er vel langsomme i ca. samme omfang som andre teknologier. Dårligt design kan også gøre en Java EE løsning.
Man vælge at betale IBM eller Oracle for sin Java EE server eller hente en gratis fra Redhat eller Apache.
(der er flere mulige, men det er nok de mest oplagte)
Windcape (23) skrev:Nu har java også nogle af de samme problemer. Ved pakker vil jeg personligt hellere have rigtig namespaces som i C++ og C#.
Java packages er ligesom C++ og C# namespaces.
Windcape (23) skrev:Og lige mht. SWT, så er der er altså minimalt hvor mange der udvikler enterprise niveau applications med henblik på forskellige platforme.
Det er rigtigt almindeligt at udvikle enterprise applikationer med henblik på forskellige platforme.
(dog næppe så meget SWT GUI apps)
Windcape (23) skrev:Typisk har du allerede valg og betalt for en given platform inden projektet overhovedet starter. Fordi typisk skal du alligevel bruge noget 3. parts software som kræver en bestemt platform (Database Servers anyone?). Så det er altså en dårlig undskyldning, der bruges alt for meget.
Der laves produkter som skal køre hos forskellige kunder med forskellige platforme.
Firmaer skifter platform. Der er rigtigt mange som skifter fra kommercielle Unix'er til Linux i disse år.
Det er ret sjældent at man ser Java applikationer i den virkelige verden som er knyttet til en bestemt database.
Det er mere et .NET og PHP fænomen.
Windcape (23) skrev:Derudover vil jeg vuderer at Mono er ligeså cross-platform kompatibelt som Java til gængse program typer.
Java er tilgængeligt for flere platforme end Mono.
Og Mono mangler en del i forhold til MS .NET, så en portabel Mono app passer ikke godt ind i MS verdenen.
Men en C# GTK# GUI app der bygger med Mono er rimeligt portabel.
Blizzard har baseret alle deres webløsninger i forbindelse med World of Warcraft , Starcraft 2, og Diablo 3, i Java EE.arne_v (30) skrev:Java EE løsninger er uhyre sjældent ustabile.
Og det er hamrende ustabilt, fyldt med fejl, og hamrende langsomt.
Måske er det uhyrt sjældent, fordi at der er stort set ingen Java EE applications som kører med et ligeså stort bruger-pres fra slutbrugerer.
Og det er ikke langt fra balanceret load!
Hvorfor? Det er ikke en risiko hvis man kan kode ordenligt.arne_v (26) skrev:Bruge et format der er eksekverbart kode er en helt unødvendig risiko.
Nogle gange er hastighed mere vigtig end sikkerhed, som f.eks. GMail, eller javascript heavy administrationssystemer / rappoteringsystemer.
XML support i forskellige er et mareridt uden lige, medmindre man benytter JQuery eller lign. værktøjer. Og selv de fleste standard js libs er baseret på JSON, og ikke XML.
Windcape (33) skrev:Hvorfor? Det er ikke en risiko hvis man kan kode ordenligt.
Sådan fungerer virkeligheden ikke.
Hvis man sætter 100 udviklere til at udvikle i et år, så vil der blive lavet et større antal fejl inkl. sikkerhedsmæssige fejl.
Det er nærmest en naturlov.
Og man kan ikke forhindre det. Ud af de 100 udviklere er der 10 rigtigt gode, 80 ok og 10 dårlige. Det kan ikke lade sig gøre at finde 100 gode ud af 100. Og selvom man kunne, så har gode udviklere også dårlige dage. De har lige fået barn og barnet har grædt hele natten. De havde et kæmpe skænderi med konen lige inden de tog på arbejde.
Ideen om at man bare skal vide hvad man laver fører lige ud over afgrunden.
Man vælger teknologi og arkitektur så der er sikkerhed i dybden. Selvom der sker en bøf et sted så bliver den fanget i næste lag. Jo flere sikkerheds foranstaltninger jo bedre.
Windcape (33) skrev:Nogle gange er hastighed mere vigtig end sikkerhed, som f.eks. GMail,
Glimrende eksempel.
GMail er et af de sites som har været ramt af sikkerhedshuller i forbindelse med brug af JSON !
Ja, kender skam fint til GMail eksemplet. Det var et så stort slag for industrien at alle seriøse udviklere forstod at de skulle servere JSON med den rigtige content-type.
http://haacked.com/archive/2008/11/20/anatomy-of-a...
Men det er ikke et sikkerhedshul for GMail, det er et XSF spoof, der udgør et slutbruger problem.
Hvis det var firmaets interne webmail som du havde åbnet efter at havde logget ind med VPN eller lign. så er det ikke særlig meget sikkerhed at miste der.
Men problemer som forkert content-type kan netop løses ved at udviklerne bliver tilbudt APIs som håndere det, samt at dagens browsere bliver opdateret til at omgå problemet.
http://haacked.com/archive/2008/11/20/anatomy-of-a...
Men det er ikke et sikkerhedshul for GMail, det er et XSF spoof, der udgør et slutbruger problem.
Hvis det var firmaets interne webmail som du havde åbnet efter at havde logget ind med VPN eller lign. så er det ikke særlig meget sikkerhed at miste der.
Men problemer som forkert content-type kan netop løses ved at udviklerne bliver tilbudt APIs som håndere det, samt at dagens browsere bliver opdateret til at omgå problemet.
Gå til top
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Programmering
Gå til bund