Werkt jQuery aan een zeer groot document?

Hallo daar programmeren peps! Ik heb een vraag re: jQuery. We hebben een softwaretoepassing die een zeer groot HTML-rapport produceert ... groot in de orde van 500-2000 afgedrukte pagina's. Het kan Google Chrome tussen de 12-20 seconden nodig hebben om het van de harde schijf te laden.

Er is een JavaScript in gebruik dat alleen dient om de HTML-versie van het rapport wat extra functionaliteit te geven. Op dit moment worden alle gebeurtenissen afgevuurd van inline HTML onclick s enzovoort.

Als ik convert naar jQuery en selecteurs gebruik om de gebeurtenissen te binden, kunnen de selectors gemakkelijk 10 van duizenden elementen matchen. Bovendien zou de gebruikelijke manier om jQuery te gebruiken (bijv., $ (document) .ready() ) ervoor zorgen dat de klikgebeurtenis niet vuurt totdat het document volledig is geladen.

So the questions are: Is jQuery up to this task? Or am I better suited leaving inline script? If it is, are there certain techniques I need to use to make it work well? And is there a way to circumvent the "no events until document load" scenario?

And a secondary question (this one just occurred to me as I was writing this): This report is being sold to a client. What are my license obligations if jQuery is included as apart of the report?

Edit

@ jfriend00: Ik heb een beetje een verlies geleden over hoe dit te doen (het rapport opsplitsen). Het rapport wordt uitgegeven in 2 formaten: HTML en PDF. De klanten willen een digitale handleiding beschikbaar hebben waarop ze secties kunnen afdrukken. Ze willen ook de HTML-versie omdat deze ankers bevat die belangrijke onderdelen koppelen. Het JavaScript zorgt voor een pop-up die een weergave biedt van de onderliggende gegevens waarop het rapport is gebaseerd. Wat er is gebeurd, is dat we een schaalprobleem hebben tegengekomen. De gegevens die worden geanalyseerd, zijn enorm toegenomen en dat geldt ook voor de omvang van het resulterende rapport.

Om vertrouwelijke redenen kan het rapport niet online of op een intern intranet worden weergegeven. Het moet een deliverable zijn die op een lokale machine voor individuen wordt uitgevoerd.

Als iemand tips heeft over hoe je dit op een elegante manier moet aanpakken, zou ik graag je ideeën horen. Dit is een probleem waar ik al een tijdje mee te maken heb.

 2
toegevoegd bewerkt
Bekeken: 7
de bron
@epascarello bedankt voor de link!
toegevoegd de auteur jwatts1980, de bron
@ jfriend00: Ik heb de vraag bijgewerkt met wat extra informatie met betrekking tot je reactie.
toegevoegd de auteur jwatts1980, de bron
@ jfriend00: De enige manier om dat te bereiken, is door ze een gecomprimeerde map met HTML-bestanden te sturen. Om de pagina's snel te houden, zou ik het rapport waarschijnlijk moeten opsplitsen in 100-200 afzonderlijke documenten.
toegevoegd de auteur jwatts1980, de bron
@ jfriend00: Ik stel je advies op prijs. Onze klantfeedback was alleen positief over de rapporten. Maar ik denk dat dit komt omdat ons rapport de enige manier is waarop ze de informatie kunnen krijgen die ze nodig hebben, dus ze houden het vol. Maar dat is mijn mening als de ontwikkelaar, niet de klanten. Zoals je al zei, kan ik me niet voorstellen dat ze het rapport gemakkelijk vinden om mee om te gaan. Maar het kan moeilijk zijn om de tijd en de kosten te rechtvaardigen om iets te veranderen wanneer de klanten geen ontevredenheid hebben geuit.
toegevoegd de auteur jwatts1980, de bron
jquery.org/license
toegevoegd de auteur epascarello, de bron
Doe jezelf en je kijkers een groot plezier. Uw webpagina heeft een nieuw ontwerp nodig. U moet meer dynamisch gedrag toevoegen zodat gegevens op aanvraag worden geladen in plaats van 2000 pagina's gegevens die allemaal tegelijk worden geladen. jQuery werkt hier goed mee, zolang je genoeg geheugen op de computer hebt en geduld hebt - het is gewoon een kwestie van hoelang je wilt wachten totdat bepaalde bewerkingen zijn voltooid.
toegevoegd de auteur jfriend00, de bron
Aangezien niemand ooit 2000 pagina's van een rapport wil lezen, is de manier waarop u dit probleem doorgaans oplost, dat u de kijker toestaat naar de gewenste gegevens te navigeren waarin zij zijn geïnteresseerd en vervolgens laadt en geeft u alleen die gegevens weer met ajax of met een nieuwe pagina belastingen. Als ze dan andere gegevens willen zien, laadt u dynamisch verschillende gegevens en geeft u deze weer. Dit vereist een meer doordacht ontwerp en opnieuw nadenken over hoe de kijker je wil vertellen wat ze willen zien en vervolgens alleen die informatie kan ophalen en weergeven. Maar de schaalbaarheid en prestaties zijn groter.
toegevoegd de auteur jfriend00, de bron
Ik weet het onderwerp niet, dus ik kan het niet helpen om het op te splitsen, maar als je je geen redelijke manier kunt voorstellen om een ​​navigatie met meerdere pagina's van de resultaten te maken, dan begrijp je of niet wat de kijker misschien wilt of je bent niet echt nadenken over het probleem. Niemand heeft 2000 pagina's tegelijk op het scherm nodig.
toegevoegd de auteur jfriend00, de bron
Of u kunt een voorsprong nemen en leiderschap tonen met uw klanten en voorstellen dat hun gegevens groot genoeg zijn geworden dat de gebruikerservaring begint te lijden vanwege zowel de moeilijkheid om te vinden wat ze willen als vanwege de laadtijdprestaties. overweeg een nieuw project dat komt met een ontwerp dat beter werkt met de grotere hoeveelheid gegevens voor nu en de toekomst. Ik begrijp dat de klant de rekeningen betaalt en dat hij beslist waar hij de $ moet uitgeven, maar soms moet je hem op de hoogte brengen van de problemen die er zijn.
toegevoegd de auteur jfriend00, de bron
500-2000 pagina's is overkill ... op de een of andere manier opgesplitst
toegevoegd de auteur darioo, de bron

4 antwoord

Wat betreft document.ready kunt u de functie .live() gebruiken om uw evenementen te binden, zodat de gebeurtenishandlers worden toegevoegd wanneer elementen aan de DOM worden toegevoegd:

In plaats van:

$(function() {
    $().bind(, );
});

U kunt .live() gebruiken:

$().live(, );

Beschrijving van .live() ( http://api.jquery.com/live/ ):

Voeg een handler toe aan de gebeurtenis voor alle elementen die overeenkomen met de huidige   selector, nu en in de toekomst.

4
toegevoegd
de bron
Ik zal dit proberen als ik uiteindelijk overstap naar jQuery. Bedankt voor je antwoord!
toegevoegd de auteur jwatts1980, de bron

jQuery is voor vrijwel elke taak. De vraag is of de browser waarin deze rapporten worden geladen, up-to-date kan blijven. Je zou een "start processing" -richtlijn elk bepaald aantal regels in het rapport kunnen insluiten, zodat na (laten we zeggen) 100 regels van het rapport er een JS-call is om je script op die 100 regels te starten.

Vervolgens nog eens 100 regels rapport en een andere functieoproep. Pijnlijk, maar in ieder geval die eerste paar honderd regels zouden interactief zijn terwijl de rest van de pagina wordt geladen.

Wat # 2 betreft, dat is een juridisch probleem. jQuery's met dubbele MIT/GPL-licenties, dus je bent waarschijnlijk in orde, maar praat zeker met een advocaat. "Maar sommige willekeurige weirdo op het internet zei dat het goed was!" is geen geldige verdediging als/wanneer u voor de rechter wordt gesleept bij een copyrightovertreding.

2
toegevoegd
de bron

Wat betreft het licentiegedeelte vind ik het prima, want jQuery is gratis te gebruiken en heeft geen specifieke regels voor de implementatie van clients.

Wat het uitvoeringsgedeelte betreft, denk ik dat jQuery niet het probleem is. Natuurlijk zal alles een beetje vertragen met een grote DOM. Ik denk dat je ook naar browsers moet kijken omdat ze allemaal verschillende js-engines gebruiken om je scripts uit te voeren.

Als het script toch langzamer gaat werken, wil je misschien dingen splitsen of meer specifieke selectors toevoegen en dan je rapport beetje bij beetje behandelen.

1
toegevoegd
de bron

Pagineer uw document met 500-2000 afgedrukte pagina's en gebruik ajax om de inhoud dynamisch te laden.

1
toegevoegd
de bron