Thinking about this, ideally, this would the way a "ideal JS/DOM/HTML"
system would behave:
<head>
<script>
function divConstructor(self) {
...
}
</script>
</head>
<div id="id1" onConstructor="divConstructor(this);">
</div>
What happens now is that when the page is being rendered (spit out by
the server and received by the browser), when DOM sees elements like
tis <div> with the onConstructor event, it can dynamically spawn
element constructors.
Of course, people might just say, why now just embed the <script> with
a document.write("<div>....") at the HTML spots you need it?
Can't argue that.
So if anything, its a matter of style. Clean consolidated coding.
Putting all your scripts in a file, etc vs spigetti code
programming. :-)
--
HLS
Pops wrote:
> Rey, I think, if its the same thing I am thinking would be where many
> developers and working sites mix up HTML and <SCRIPT> tags at the same
> time throughout the page.
>
> <head>
> </head>
> <body>
>
> <table id="id1">......
> <script>
> ... do something for this table any anything else above
> </scrpt>
>
> <div id="id2">.
> <script>
> ... do something for this div any anything else above
> </scrpt>
> </div>
>
> </body>
>
> Ideally, the "practice" tells ya to put all your <scripts> in the
> <head> block. This promotes" clean programming. It also promotes
> things like jQuery document.ready().
>
> So the different is one a broken up process of painting/script
> operations as the page is rendered vs waiting its all done and then
> starting it with document.ready. So imagine taking all the embedded
> <scripts> and consolidating it to the top or all at the bottom which
> would have the near/same affect with document.rendy.
>
> This plug in allows you to consolidate your code and passing it the
> id1 and id2 would in effect have the same dynamic operation as when
> the page was being loaded and it reached the ids to process the
> script.
>
> This would have a positive effect in display speeds allowing people to
> not lost the speed they once saw, that was probably noticable in
> larger pages anyway.
>
> Make sense?
>
> I have not seen the plugin, but conceptually I say this is major
> engineering piece of work for jQuery. in fact, I vote for it to be
> part of the stock library in future releases.
>
> Great job to the author!
>
> --
> HLS
>
> Rey Bango wrote:
> > Hi Bennett,
> >
> > Yes I read the original post plus what you wrote on your site. What I'm
> > asking for is an actual example, not just a "hypothetical" scenario.
> >
> > Rey...
> >
> > Bennett McElwee wrote:
> > >> I'm really interested in understanding more about this plugin. Could you
> > >> give an example of when and how it might be used? I know you listed some
> > >> sample code on your page but I'd like to get a use case for it.
> > >
> > > [From the original thread:]
> > >
> > > Here's a simple example of where jQuery.ready is insufficient. A large-
> > > ish page (50kb) uses jQuery.ready to add rounded corners to the header
> > > at the top of the page. The title displays straight away with square
> > > corners; then the rest of the page loads (a delay of a second); then
> > > jQuery.ready fires and the corners abruptly become rounded. If we
> > > rounded the corners as soon as the header was available then the user
> > > experience would be smoother.
> > > - from
> > > http://groups.google.com/group/jquery-dev/browse_thread/thread/263b3ee5c6e4e63e/896356fc3f78c65d
> > >
> > > Generally this is useful when you want to use unobtrusive JavaScript
> > > to set up the page. Another example is setting up event handlers. You
> > > normally have to do this in jQuery.ready(), but this means the
> > > handlers don't get set up until the entire DOM has loaded. Until that
> > > time, the affected element will be inert, causing irritation when
> > > users click it expecting to see their popup calendar or whatever. The
> > > gap may only be a second or two, but it's long enough to annoy users
> > > and result in helpdesk calls. This recently occurred on a production
> > > site I am working on: the site uses YUI, so I was able to use
> > > YAHOO.util.Event.onAvailable() to set up the event as soon as the
> > > element was ready. That made me wonder whether such a facility existed
> > > in jQuery; hence the elementReady plugin.
> > >
> > >
