Thanks for the overwhelming reply!
I agree: the most elegant and perfect jQuery plugin would ideally just allow you to call the given interface generically and always work intelligently
- on any site that fulfills the criteria you mentioned. That would be absolutely awesome!
Boy, I would readily spend months on this, to get it working properly, given that the underlying design is sound.
Thanks for taking your precious time to participate in the development!
(I've got plenty of time at the moment, because I'm on a long professional leave of reconvalescence)
Just wondering, would you be prepared to participate on the forth-development of the above Gist at GitHub?
That's a nice and centralised platform for collabaration and maybe some other developers might join in, maybe even "Balupton", if he's got the time.
I guess the guy didn't have the time to forth-develop the Gist because he's pursuing other projects.
Just quickly checked and couldn't find your own profile at GitHub, but you seem to have mentioned GitHub in another thread, afaic remember.
Wonderful, that you regard this as "next gen" development. I find it very promising, too, and would like to improve it as much as possible, even if it would be alright
if the plugin is only used for very simple sites, of which there are tons anyway.
Now to the technical bits:
Broken links -> I chose to delegate the hard work to the external "urlinternal" plugin for generically checking whether a link is internal, instead of doing my own dodgy link handling.
If the link is broken beforehand - GIGO, I suppose?
per page CSS -> maybe you've got an idea on this or even experience. Really tricky would be page-specific CSSs that are mutually exclusive across the site?
Otherwise theoretically manageable. (edit - see pseudo-code design of the "Script Remembering Handler" below, which could also handle CSS's along the way)
scripts not re-firing -> in one incident here: http://www.oeko-fakt.de/produkte/ (see table that pops up after selecting anything on the combo-box) I opted to hack into the respective JS and instead of wrapping the salient master code in ".ready()", we wrapped it in a function that get's called in the callback section of the plugin. It works, but is not exactly elegant.
Educating people to do this would be awkward and make the procurement of the plugin less attractive for complex jQuery or otherwisely dynamic site. Now, my first and intial idea was to re-trigger ".ready()" and the whole associated (now internal) ReadyList manually, because that would be nice and generic and one could do without tampering the other jQuery code.
But after some basic research and looking at some highly-rated threads at "stackoverflow", it seemed that that route once was viable, but in the later jQuery versions has been suppressed.
Now, the readylist is not exposed anymore, cannot be tampered with and re-triggering ".ready()" has no effects at all, because it is "called once and only once".
An idea would be to go lower-level in the DOM handling, so to say "beneath" jQuery and trick the browser into refiring the low-level DOMReady and ideally anything subsequently like jQuery's ".ready()" (along with the whole ReadyList) - maybe I'll research that one a bit more, or raise a dedicated thread in forum.jquery.com.
Balupton's Gist used to be and still is popular and being used. For your convenience, I can quickly describe in pseudo-code what he has offered as a solution to the challenge:
- AJAX pull gets the whole HTML of target page
(- in between, he caches this away with a neat regular expression -> by the way, it might be possible to cache away the CSS references on this pass, too)
(- this is in order to dump it successfully into the jQuery selector in it's entirety, which would otherwise fail)
(- he then later on pulls back all script inner texts)
- Re-engineers the script tags, attached to the content div along with their inner texts.
- In most cases, they probably fire correctly, although there also has been criticism in the comments section
Why, I'm hesitating to procure this 1:1 is because it seems that this is a bit redundant?
Even if it works in most cases and requires very litte JS code, I think it's somewhat run-time superfluous because the common JSs ought to be in memory anyway,
as only the content div is loaded dynamically. The entire original <head> for example, not to mention other common parts of the page should still be there??
(especially nasty if some script doesn't appreciate being loaded several times, apart from the waste of run-time)
In my opinion, the better algo would be to do something like a brief and generic delta-analysis of which scripts (and potentially CSS's, too) are to be loaded additionally, instead?
Does jQuery offer something like a UNIX "filecmp" (i.e. FileCompare) on plain text sections? After all, in my algorithm, I've got the current page at my disposal and the target page, too, at the same time. It would be the differences/deltas that would require attention...
<QUOTE>4. attempts to re-fire scripts led to build-up; a plugin on one page stays loaded for every page thereafter, and safely dismantling any and all script is futile.</QUOTE>
We've talked about the first part of this sentence above - do you reckon a generic way for re-firing the actual event could be performed somehow?
The second bit is the really hard part. How do you unload or at least disable page-specific scripts? Must admit, I haven't even thought about that, because it seems to be the usual case, that a resident script is just idle, when superfluous, but does not interfere. But I get your point - an entire jQuery plugin that remains resident across AJAX calls can lead to really funny results, surely.
Maybe I'll raise a thread on this topic, too, at forum.jquery.com.
If we're being nice and thorough, and really ambitiuos, I think the ideal solution would require it's own rather intelligent object, that handles these jobs.
Here's the pseudo-code at the highest level that comes to my mind:
- On "click" the object does a delta-analysis of target page scripts, against the current page's ("filecmp").
- It loads them in after target div injection.
- It remembers them (!)
- On subsequent "click" or "popstate", it unloads them again
(actually the last step should be performed before injection, just starting with an empty memory)
As you mentioned, if, generically speaking, there is an exception/error along the way, that can't be gracefully descended, an escape to a hard page refresh is possible.
(along with priorly logging the error to the console)
It's very interesting to read about the project you put so much effort into. I'm glad to here, that the visible result was promising and you could see the potential advantages.
Did you also attempt to engineer a generic tool (independent of web-pages). Or was it specific to the web page?
Did you use Balupton's excellent "history.js" along with the "History API"?
Would be great to here from you again, and I really cherish your profound professional experience!
(btw thanks very much for all the various support in this forum in the past...)
(please give me a quick hint, whether you'd be prepared to participate centrally at the development of the Gist.
Be it only one or a few comments along the line - that would be invaluable)
To sum it all up, in terms of research / feasibility studies the issue I'm currently thinking about most, is how to re-trigger ".ready()", be it at lower level.
It really ought to be one of the most frequently asked DOM related questions??
What do you think about that point?
(again, if you agree it's a good idea, I'll be happy to raise a dedicated thread, after doing some exhaustive research on the web, whether there is a workaround or similiar)
Talk to you soon and kind regards