If you've still got a strange delay, try logging information to the console
(like onClick, before ajax call, after ajax response, when elements are
written to the page, etc). It would be helpful to see if the delay is in
clueTip, in the ajax call (as you suspect it is already slow), or a jQuery
css selector query. Have you tried making the same request from the server
without ajax (just typing the url into the browser to see how long it takes)
?
I was going to recommend optimizing the query selectors to see if there was
any impact, but I see Karl beat me to it.
I don't know the innards of clueTip, but with activation:'click' set, does
hoverIntent even come into play? Have you tried using the hoverIntent:false
property in clueTip?
As for tweaking hoverIntent, the default 'over' interval is already pretty
fast (1/20th of a second)... so the over function would be called as quickly
as .05 second... and with a little motion .1 or .15 second. To tweak
hoverIntent I would rather change the sensitivity (to a greater value,
~10-15) to make it activate more often instead of changing the polling
interval. When I have some more time (next week/weekend) I'll update the
hoverIntent page with a discussion about changing plug-in settings.
Please let us know what you find.
Brian.
On 1/3/08, Shawn <[EMAIL PROTECTED]> wrote:
>
>
> I wish this page fit the normal ideals. I agree with everything you
> said. But in this particular instance, none of it will work. :) The
> page in question is more of a full application, than a simple data page.
> So the usual (and great) suggestions you have made are not quite
> applicable. I've already applied these ideas to simplify the page a
> fair deal, yet show the same data. There's just too much in the way of
> data requirements (processing/joins etc. rather than volume of data).
>
> This particular delay was just odd when I saw it (a second or two delay
> before I could tell ClueTip was firing). I *know* there are other things
> going on (the development server is in a VMWare image that's in
> desperate need of a rebuild, for instance) but I'm not (yet) comfortable
> enough with ClueTip to say if I have things configured right. So I
> wanted to double check that before tackling the larger issues.
>
> Thank you muchly for the response!
>
> Shawn
>
>
> McLars wrote:
> > I don't know anything about the clueTip. Hopefully, someone else can
> > help you with that. Are you sure Ajax is necessary, though? You say
> > you want the application to be snappy (a laudable goal), but it sounds
> > like there is a bit of a speed hit with the database. So, even if you
> > get the Ajax to fire sooner, I'd think that could still make the
> > response slow--especially if your users are very remote.
> >
> > It would probably feel more responsive if the tip info was preloaded.
> > If it takes too long to get the tip info while the server is building
> > the initial page, perhaps you could fire off an Ajax query for the
> > entire page's tips as soon as the DOM is ready. There will probably be
> > bit of a time while the user is reading the page before they start
> > hovering over stuff.
> >
> > Overall, you can get more data out of a database faster in one chunk
> > rather than separate calls for each date. Unless you really have a lot
> > of dates on the page, it might be faster to just get them all at once.
> > For example, if you had a month calendar, that would only be 31 days
> > of data. Even a year's worth might not be bad if each record is small.
> > Since you're talking about tips, I'm guessing it isn't much. Ajax is
> > best suited for when there is either just too much data to load at
> > once or the data might change during the lifetime of the page. You are
> > right to focus on the user experience. Do what's best for them, not
> > what's cool to program.
> >
> > If you wanted to get fancy, you could have the page load up with the
> > dates slightly grayed and then light them up as the data is loaded.
> > That way the users can start reading the page right away, and they can
> > see that activity is going on in the background.
> >
> > Larry
> >
> >
> > On Jan 2, 4:28 pm, Shawn <[EMAIL PROTECTED]> wrote:
> >> I'm seeing an odd delay before the Cluetip code fires. I'm wondering
> if
> >> I have cluetip configured badly, or if the problem is elsewhere in my
> >> code (most likely, but need to check...). Here's the Cluetip code:
> >>
> >> $(this).attr("rel", "xhr/dayDetails.cfm").cluetip({
> >> activation : "click",
> >> positionBy: "mouse",
> >> mouseOutClose: true,
> >> sticky: true,
> >> closePosition: "title",
> >> ajaxSettings : {
> >> type: "GET",
> >> data: "e=" + eid + "&sd=" + dt + "&d=" + dt
> >> },
> >> onShow : function (ct, c) {
> >> $("#dayDetailTip").children(".taskdetail:even").css("background-color",
> >> "#fff");
> >> $("#dayDetailTip").children(".taskdetail:odd").css("background-color",
> >> "#ddd");
> >>
> $("#dayDetailTip").children(".taskdetail").unbind("click").click(function
> >> () {
> >> var id = this.id.toString().split("-")[1];
> >> task.edit(id);
> >> $("#cluetip-close").click();
> >> });
> >> }
> >>
> >> });
> >>
> >> What I'm seeing is a 1 or 2 second delay before my Ajax activity
> >> indicator (via .ajaxStart() ) shows up. SO, that would seem to mean
> >> that nothing is happening for that 1 or 2 second period. I would
> assume
> >> the Ajax via ClueTip would fire almost instantly??
> >>
> >> I know it's only a second or two, but it makes the application feel
> >> sluggish. The called Ajax page (dayDetails.cfm) already is doing stuff
> >> with the database that incurs a performance penalty. So This delay
> just
> >> adds to it. (And I'm looking at the SQL side of things to see if I can
> >> speed it up. Not promising though - it's a non-trivial task).
> >>
> >> If it helps, I do have the hoverIntent plugin loaded (as well as a
> bunch
> >> more). I have tried setting the hoverintent delay to 0 with no effect.
> >>
> >> Thanks for any tips.
> >>
> >> Shawn
>
