Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#3 Dynamic loading of scripts

closed-fixed
nobody
None
5
2008-08-18
2008-06-30
No

It would be nice if there were a "dynamic loader" script which would scan whole document searching for source code listings to highlight and after finding them generate (using DOM probably) some script elements which would load apropriet script files.

Discussion

  • gnombat
    gnombat
    2008-07-01

    • status: open --> open-accepted
     
  • Logged In: YES
    user_id=2169537
    Originator: NO

    I've got something that seems to work pretty good for this. There is a live example at

    http://emarcotte.com/test/shjs/test.html

    The shjs directory there has both sh_main.js and sh_main_dyn.js. The _dyn version is the one that supports the dynamic loading. It uses a sort of ajax technique (the XMLHttp objects), but doesn't do it asynchronously, to fetch javascript from a given path and then evals whatever it gets back. To set up the path I added an optional argument to the sh_highlightDocument function. If you don't pass the argument it assumes the current directory.

    Should I attach a diff here or send it to a mailing list?

     
  • gnombat
    gnombat
    2008-08-13

    Logged In: YES
    user_id=1294975
    Originator: NO

    The synchronous XMLHttpRequest is problematic - it could freeze up the browser.

     
  • Logged In: YES
    user_id=2169537
    Originator: NO

    Yeah, I was thinking about that. Given the way I did the look up for languages, I have to wait for it to respond or I may miss the results.

    I was thinking of maybe adding a timeout that would somehow check if results got back yet if not, reschedule another timeout, otherwise attempt the highlighting.

    Any other ideas?

     
  • Logged In: YES
    user_id=2169537
    Originator: NO

    Doh. Yeah a timeout is not smart probably. I've altering it a bit so that it is asynchronous. When the ready state becomes done, I try to highlight. Unfortunately, since it burns through the 'pre' elements really fast and creates a request for each it will end up probably fetching the same resource several times.

    In my test file (same as before) it has two sh_java classes and if you watch requests in Firebug you will see it fetching two sh_java.js files.

    Any suggestions ideas to improve it would be good. I'll clean it up some more later tonight.

     
  • Logged In: YES
    user_id=1023200
    Originator: YES

    I think it should be done in the following way:
    1. A simple and small script is attachet to web page with function called when page is loaded (ie. onload).
    2. This function scans whole document (or part, whatever) and search for thins it could hilight. If nothing is found processing stops here.
    3. A list of files to include is built and a set of <script type="text/javascript" src="path/to/script/foo.js"></script> tags is added at the end of head element -- this can be easily done with DOM.
    4. Also a <script type="text/javascript" src="path/to/script/main.js"></script> (or some different name) is added.
    5. Scripts loaded from 3 register "hilighters" (or whatever you want it to be called) and script from 4 does the hilihgting.

     
  • Logged In: YES
    user_id=2169537
    Originator: NO

    Is there a benefit to the script element method over doing the xml request approach? I was originally going down that road, but there is a problem that the script elements are not evaluated until after the are parsed. Of course, the approach you describe would resolve this, but it also seems a bit more complicated.

    I've got an initial asynchronous version at http://emarcotte.com/test/shjs/test.html (uses sh_main_dyn.js which is a modified sh_main.js). It maintains basically the same sort of usage approach, that is existing pages will still work, and will be able to make use of the dynamic bits too, if the script files are not already included.

    The only drawback I can see at the moment, aside from not having cleaned ups some tiny duplicated bits of code, is that it will fetch the same file twice. I think to fix the multiple fetch issue I just have to record a map/dictionary of languages with currently pending requests or something.

    Thanks for feedback :)

     
  • gnombat
    gnombat
    2008-08-14

    Logged In: YES
    user_id=1294975
    Originator: NO

    I think the only difference between loading scripts with dynamic script elements vs. asynchronous XMLHttpRequests is that the XMLHttpRequest cannot load scripts from a different host (i.e., the same origin policy).

     
  • Logged In: YES
    user_id=1023200
    Originator: YES

    I have an impression that inserting elements into HEAD element is more portable then XMLHttpRequest. Also, synchronous aproach is simpler to debug and maintain then asynchronous. Moreover, with my code, some languages may share common base (as in example, java and cpp both require c-common).

    If the fact that hilihgting is done after all files are loaded is an issue it can be fixed by letting each file call some fancy function by it's own. It's not an issue really.

     
  • Logged In: YES
    user_id=1023200
    Originator: YES

    http://home.elka.pw.edu.pl/~mnazarew/temp/dl-example-2/dl.html -- highlighting is done as soon as script doing the job is loaded. Also some script may share common codebase but shared script have to sort before all other files, ie. it may start with "0.". Files are never loaded two times even if dynamic loading is done several times.

     
  • Logged In: YES
    user_id=2169537
    Originator: NO

    Doesn't that seem like a bit of overkill? Do any of the language definitions actually have inter-dependencies? Your solution is sounding more like a general purpose javascript import thing where as I think something a little lighter would be better for this, maybe I'm wrong? Wouldn't it also require making changes to the various language definition files to make it work? As far as the xml object support goes, it should work as far back as IE 5, and the shjs site's browser list doesn't go back as far as the browsers that would support it.

    Maybe it is possible to do the script element approach, and add event listeners to the document for when they've been loaded/executed, so that you wouldn't have to alter the language definitions? I've not looked into this at all so I have no clue really.

    The 'other domains' issue is maybe problematic. There is a reason for it, though, you don't necessarily want someone injecting scripts into your pages from some unknown place.

    I'm gonna stick with my xmlhttp one for my own site anyway, its pretty simple and gets the job done.

     
  • Logged In: YES
    user_id=1023200
    Originator: YES

    Removing the part which allows language definitions have dependencies is like a one minute work yet it also allows some languages to be defined in scripts different then language name. For instance a c.js may define a c and cpp languages where in the former words such as this, class, true, false, etc. would not be treated as keywords.

    As of changing language definition files I haven't looked into them so I cannot tel you if changing them would be required but even if IMO it's not a big issue.

     
  • gnombat
    gnombat
    2008-08-18

    Logged In: YES
    user_id=1294975
    Originator: NO

    The latest version, SHJS 0.5, can now do dynamic loading - currently it uses the asynchronous XMLHttpRequest implementation, but this may change in the future. I made the interface a bit more flexible (and a bit more complex) - see http://shjs.sourceforge.net/doc/documentation.html for details.

    I'm marking this feature request as closed, but feel free to open up new bugs and/or feature requests with respect to the current dynamic loading implementation.

     
  • gnombat
    gnombat
    2008-08-18

    • status: open-accepted --> closed-fixed
     
  • Logged In: YES
    user_id=2169537
    Originator: NO

    Nice. Working well on my side. Good catch with the added the suffix part, I've been using the minified lang files for my live stuff and obviously my test version wouldn't work with those!

    Thanks!

     
  • Adam Katz
    Adam Katz
    2010-02-26

    Ticket 2959860 (which should have been an enhancement request) takes this a step farther, creating a dynamic loader to be called from the body which includes the ability to set a theme (nontrivial since style tags aren't allowed in the body). My code has been submitted but is not a patch and likely needs some integration work.