Ok, the title is a dumb one, but one of the nice new tags in ColdFusion 8 is the cftooltip tag. As you can imagine, it creates a DHTML based tooltip. It is rather easy to use as well:
<cftooltip tooltip="The following table displays sales for products over the past year.">
<table>
<tr>
<th>Product</th>
<th>Sales</th>
</tr>
<tr>
<td>Apples</td>
<td>3,313</td>
</tr>
<tr>
<td>Bananas</td>
<td>5,491</td>
</tr>
<tr>
<td>Cherries</td>
<td>1,232</td>
</tr>
</table>
</cftooltip>
Whenever someone hovers their mouse over the table, the text explaining the data will pop up. The tag has a few optional arguments for how quickly the tool tip should appear or go away, but the other main attribute you can use is sourcefortooltip. Here is a simple example:
<cfloop index="x" from="1" to="5">
<cftooltip sourcefortooltip="test3.cfm?id=#x#">
<cfoutput>
<p>
This is the #x# paragraph.
</p>
</cfoutput>
</cftooltip>
</cfloop>
Now when the user mouses over the paragraph, ColdFusion will do an AJAX request to test3.cfm?id=X, where X is a value from 1 to 5. You can return any HTML you would like, including images. Here is the simple file I used:
<cfparam name="url.id" default="">
<cfoutput>
<b>Tip #url.id#</b>: This is an example of a dynamic tooltip.
#timeFormat(now(),"H:mm:ss")#
</cfoutput>
Why the time? I was testing. ColdFusion caches the result of the tooltip text, so even if you mouse away and return back over the item, the seconds value is not going to change. This is probably a good thing performance wise, but something you don't want to forget.
Personally, I can see this being very useful for forms. I can imagine using this quite a bit for buttons, links, etc, to make it clear what each item does. Since I have the ability to slow down the appearance of the tooltip, I can set this to a good value such as not to bug people who actually know what they are doing.
Archived Comments
No demo? You must be slipping!
:)
Could be pretty handy, but I'd be interested in seeing how much javascript code they're using for a simple tooltip. My guess is at least 100k.
Heh, no, not 100k. ;) I do plan on doing more demos - I'm just waiitng till I move this site. I _should_ be moving it this week.
Nice idea for caching the tooltip. Is there a way not to use the cached results.
It would definitely be useful to have an option to not use cached results if needed. One thing I'm really curious about is how much javascript gets generated by Scorpio, it's probably going to be a factor in how much I use all these DHTML/Ajax tools, since I'm pretty comfortable working in javascript anyway.
This is a great tool. I was playing with it and found that you can interact with the window. So, you could put links in it that the user could click on. It is missing a couple things however. Oddly enough, I dug around the js files that create the window and these options are there. There just needs to be a way to tap into them.
I wish it could do the following:
Allow for drag.
Allow for a close button.
Ability to disable autoclose.
Corner Arrow.
I have to admit, I'm not a fan of tags like this in the language. IMO it clutters up the language. I'm not against the functionality, it's neat and probably very useful.
Seems to me that this type of tag should be released by Adobe as custom tag or CFCs. CF8 has a handful of this type of UI tag that I'm just not convinced should be in the core language.
Might be worth noting that some cfform tags support this by simply adding a tooltip attribute (that was previously only used in flash forms).
For example:
<cfform name="testForm">
<cfinput type="text" name="test" tooltip="This is my toolTip!" />
</cfform>
@Steve Nelson...
I agree with you. It's a nice feature I suppose, but I have two issues with their implementation:
1) The size of the js libraries is WAY out of control. See a post by Rey Bango on Ben Nadel's cfwindow post. The libraries needed to run the window totaled up to 330k.
2) Like you said, does this really need to be in the core language.
@Dave Ferguson...
cftooltip doesn't need dragging, as it's not meant for that. If you want drag functionality then use the cfwindow tag. That's probably why you saw it in the core library, as it's there for cfwindow.
I'm starting to get a little irked. I think many people like Rey Bango and others who are _shocked_ that it takes a large JS library to pull off some of the amazing new AJAX/UI stuff are missing the point.
Whats the point? Well - would you want to include a huge library of JS _just_ for a cfwindow/cfmenu/cftooltip? Probably not... Would you want to include them for a full blown AJAX application? Yes. Before anyone complains one more time do me a favor - go log into GMail - tell me how long it takes. 10-15 seconds? Why? Because it is an AJAX _application_ - not a web site with some AJAXy stuff. Like everything else let's consider use cases before we blow everything out of proportion. Would you create a Flex SWF for a simple log in to an HTML site?
Ironically my captcha texts answers that question: "no"
@Andy
You are correct, CFWINDOW is more suited for that type of implementation. I have not had the opportunity to check it out yet, but I will soon.
--Dave
@Todd: Missing the point? Are you kidding me? Did you read my posting or are you just irked because of the comments on this post? You'll see that I'm giving advice to folks about being careful on how file size affects your application. Nowhere do I put down CF8's Ajax functionality. In fact, I even tell people to use it.
And in terms of understanding what it takes to pull off amazing JS stuff, I do it EVERY DAY. On top of that, I'm a member of the jQuery project team so I live it every day. I'm keenly aware of what's involved which affords me the luxury to be able to offer advice on gotcha's that others, who may not be as involved, haven't see yet. Couple that with my 10 years of doing ColdFusion development and I think I'm certainly not missing the point.
@todd...
Also, another thing to point out is that while CF8s library requires 300+k of JS code to show a simple modular window, jQuery offers that same functionality in less than 26k, cross-browser and EASY to set up.
--- jQuery (compressed) = 19kb (http://code.jquery.com/jque...
--- jqModal = 2.85k (http://dev.iceburg.net/jque...
---- (adding in CSS and drag n drop support bumps it to 5k total)
So, please don't think I'm griping about SOME file size, I'm just complaining about unnecessary file size.
I just pasted these pieces of code over at hostmysite cf8 demo sites. And none of them worked. Has anybody had success with this tag?
Figured it out ... had to get them to add a mapping to CFIDE ... sweet :)
@Todd: I wanted to do a file size test using your Feed Reader demo. Its a great example of what you can do with CF8 and its definitely an elegant implementation. So I used FireBug to hit up your demo here:
http://h127171.cf8beta.com/...
and it came out to a nice healthy 717KB!! Almost a meg for a web page! w00t!
So I did it using jQuery. I even used your feed.cfm and feeds.cfm from your download:
http://h127187.cf8beta.com/...
I'm seeing 25kb for the whole page and I included a nice fade in effect and some progressive enhancement by binding the anchor tags for the authors dynamically.
Now, 717kb for something that should've only taken max 30kb doesn't seem quite right to me and neither does your argument that you need to pull in huge libraries to make an Ajax application.
Rey: I certainly did not mean any disrespect to you or anyone else. We are still talking about an unreleased product. I guess I'll reserve further discussion until we see the final product.
Nice work on your version though - that is cool. I certainly don't have the skills personally to master jQuery right now without digging into it. Maybe that's why I'm such a big fan of the CF Ajax stuff.
@Todd: Thank you for the reply.
The CF8 stuff is very compelling and it excites me because I see it as a nice stepping stone for those that want to migrate into a full library such as jQuery, Prototype, Spry or YUI. Its Ajax for the masses. What I'm trying to do is educate folks on some of the things that I've had to contend with. I've seen how important file size is because it could mean the difference between someone using your site or leaving it. In usability studies, its been shown that the average consumer will not wait past 3-5 seconds for a page load. So if you already have a page this 50kb and now you tack on another 700kb, you're going to see an increase in download and page rendering time.
I want folks to use the CF8 tags but I also want them to have some ideas of what to expect. The best thing would be for Adobe to allow the YUI -min flag to be set so we can streamline the lib size. As you mentioned, its still prerelease so lets keep our fingers crossed.
Finally, as for jQuery, I think you would be VERY surprised as to how quickly you can pick it up, especially since AjaxCFC now uses it under the hood.
So where are your custom tag implementations of jQuery? ;)
Teasing of course, but I think it would definitely be cool.
Ya know, I never really gave that much thought but I'm going to see if that's possible. It would be very cool to do something like that! Also, if you want to know more about jQuery and just how easy it is to get cranking check these links out:
http://docs.jquery.com/Tuto...
http://15daysofjquery.com/
http://www.learningjquery.com/
You can use CF8's Ajax controls for quick and dirty stuff and jQuery for more involved and precise work.
I have to agree with Rey, it's worrisome that these files are that big because the average user might not realize the implications of using them. They just think they're throwing in some cool features, but 500kb of js files is a pretty hefty sum. I wouldn't discourage people from using the features, but I really hope that in seeing the power they provide that people will realize that this is the power of javascript and as such make an effort to learn it better. That way they can implement a lot of this functionality unobtrusively (no inline javascript) and they can minimize the files needed. Plus it gives you more options for frameworks to use. You can use Prototype, jQuery, Dojo, YUI, Ext, or whatever else. I'm kind of partial to Ext (sorry Rey!), but any one of those frameworks will do wonders for you. Just get familiar with javascript, it will be useful no matter what you use to code server-side, and you'll be a better web developer for it.
@Thomas: Well said my man. And no worries about Ext. Ext isn't a standalone framework in itself. It relies on a base set of classes from either YUI, Prototype and, yes, jQuery!! Actually jQuery was the second lib that Jack Slocum integrated with (YUI being the first). Jack's sharp and his stuff is top notch. Its also a little heavy but managed right, it provides such RICH UI controls.
@Thomas: BTW, Steve Cutter has a very good series of articles about using jQuery with Ext. Here's the first one:
http://blog.cutterscrossing...
I don't know why that slipped my mind, that is actually one of the coolest things about Ext, I was playing around with it with Prototype. I still got the impression there was some repeated functionality though, which might be less if you used it with YUI. But oh well. Hey also have that custom build tool now, I haven't used it but I assume you could shave off quite a bit of file size if you pick only the things you really need. Slocum's the man.
yeah. Jack is an animal. He does some great work.
I notice that the first example doesn't work with Firefox on a mac. The scroll bar is displaying in front of the actual tooltip.
Also I wonder if the ajax request is using a GET method which will cache on IE?
Ray I imagine you were using FF so perhaps Adobe have implemented their own caching here.
Michael, it worked fine for me on Firefox/OSX.
To your second comment, I'm on FF/OSX.
Hmm, strange.
I'm using FF 2.0.0.4 on Mac OSX and still getting the problem. Gotta love these little UI intricacies!
Ok, let's take it down a notch here and add some FUD control.
First, somehow we went from "234k" to "717k" for teh same example that highlighted, then we somehow got to "almost 1MB", and heck, soon we'll be at 1 GIGABYTE to run a window.....quick! Grab your pitchforks and rally the men :)
Let's take it down just a smidgen here...
First, we aren't done guys. We thought we'd get this out for you to play with though, and we appreciate the feedback. Second, when you use complex controls, like CFLAYOUT and SPRY components as in the example, you'll get those included, and all their dependencies, plus our stuff.
In Rey Bango's examples, he is using the border layout to implement a very simple condition (left and right layout areas, which is best done with a div-based layout and minimal CSS), which it is definitely overkill for. He's also using Spry, which all adds to the download size.
We'll be spending more time in the next few days playing with jQuery, and we'll post some more evaulations of it so folks can understand the real deal.
Damon
I double-checked at the time in Firebug, and Rey's numbers seemed correct, it was 717k for the WHOLE PAGE. The javascript includes were somewhere in the 500k ballpark. Regardless, I don't think anybody's out of bash the product, it's just feedback and recommendations, I think we're all pretty excited about this CF release. The fact that it's still beta can only make us more excited about the final release!
@Damon:
Actually, you're incorrect on two things. First, Nowhere was it mentioned that the same sample app "234k" to "717k". Andy Matthews made mention to a post I had made about another demo app made by Dan Vega that was a page size of ~330kb. My reference to 717k was made re: Todd Sharp's demo Feed Reader app. Next, I didn't make the demo app shown here:
http://h127171.cf8beta.com/...
The above is Todd's application and FireBug reported a page size of 717kb. *My version* is here:
http://h127187.cf8beta.com/...
The above used jQuery and FireBug reported a page size of 25kb.
The only reason this was even done was because Todd had made a comment about me "missing the point". That has since been resolved and I thought this was a closed case.
Finally, I'm not sure what you mean by "so folks can understand the real deal". Considering that the CF community is heavily involved with jQuery, I would hope that you folks look at it objectively.
@Thomas: Thank you for verifying the figures. There was never any intention to bash CF8 at all but more an effort to show that these page sizes are a concern that needs to be considered. In fact, in my posting (the one that triggered all of this) not once did I mention jQuery (or anyother lib) as to not detract attention from the specific issue or make comparisons.
I'm sensing that folks are a bit sensitive these days and it could very well be because of that ComputerWorld article. I truly hope that I can continue to post my observations without it being misconstrued in some way. Ironically, it took these comments to get an Adobe rep out to say that a solution is already in the works. I guess some good came out of it.
Rey, sorry, I just meant that you had referred to the app in question (RSS reader). Someone above mentioned 717k, when in fact that the size of the entire app, including downloaded data.
Again, the design of that app was easy, but as I pointed out, used CFLAYOUT, SPRY, and our stuff.
We'll see if we can't make it down to 25k or less for the final for simple stuff like this. If you take SPRY and the Yahoo imports out of it, you get more of an apples-to-apples comparison with your simple example, and we end up with about ~31k (the size of the core cfajax Javascript).
More to come in terms of intelligent optimizations, since we've go the majority of the capability and ease of use done.
Rey, a "solution" isn't in the works, since there's not really a problem here, except that we're continuing to optimize the current solution.
I think what you sensed was only sensitivity to objectivity. Any attempt to do an apples-to-apples comparison needs to be just that and fair and open and complete in the CF community, or watch out! :)
Again, a properly coded example like the oone you posted would be about 31k, vs your 25k.
Damon
@Damon: Thanks for the reply. Whatever you can do to minimize those files would be very helpful. My concern lies in the fact that many of my client's target audience still use dial-up so page size is a big concern for me. And while I do make regular use of jQuery, my intention is to be able to leverage CF8's widgets as well, especially because of the ease of data binding. That's a very attractive feature. So again, whatever you folks can do to slim down the .js files would be a HUGE help.
@Damon: I'm not sure how much more objective I can be. I take an existing app (Todd's feed reader) built using the tools that Adobe incorporated into CF8 and compared it to a solution built from the ground up with another library. How am I not being objective? Did I skew the results somewhere?
As for filesize, I'm glad that you broght it down to 31k which seems more in line with what an app like that should be. So I think your next task is to post the code and a blog entry explaining best practices on optimizing the CF8 Ajax widgets so we can all benefit from the optimizations. That coupled with the compression that you'll be doing on the libraries before release (ie: the solution) should effectively stop anymore discussions about file size.
Yeah, we're on it, but developers will need to conscious of the tradeoffs involved where higher levels of client side functionality (UI and layout components, data binding functionality, etc) = larger downloads.
We'll do our part to make sure there's sufficient control over what gets downloaded to be able to make the right choices.
But understanding the trade-offs of functionality vs download size is, and will continue to be something all app developers need to be aware of.
Thanks for raising the flag!
Damon
@Rey, yeah, when you include all the UI stuff, the entire Spry libarry, etc and compare that to a jQuery app that doens't use any of that, I'd say that's hardly fair.
A more apples-apples would be to use CFAJAXPROXY ad the base CF Ajax stuff to vs jQuery, and you'll see that's 31k vs 25k.
HTH
Dmaon
@Damon: Ah, I get it. So if you don't take advantage of the cool CF8 Ajax controls available, then it'd be a fairer comparison. ;)
I sent you my code and I'm really interested in seeing a demo of how to streamline the code with the CFAjax stuff. Can you build a quick and dirty example so we can check it out?
Sorry, no can do right now. I would, however, challenge you (or anyone who'd like to) to try it though, without using jQuery, and just the base CF Ajax plumbing.
Let's see thjose Ajax chops in action Rey :)
Damon
We had some conversations with Rey about this, which he blogged here:
http://www.reybango.com/ind...
It is also worth noting that the tooltip tag can handle html formatting tags like:
<CFINPUT type="text" name="Crit5_Value" tooltip="<b>Title Text</b><br>This is my toolTip!">
This makes it look a little fancier and opens up a lot of possibilities.
I would like to be able to use the tooltip functionality here using a CFC to access a table of specifically relevant tooltips. I tried, but it doesn't work. Any ideas to make this work more directly than creating a CFM to call the CFC?
While you can't do CFC:...., you can call a CFC via a url:
mycfc.cfc?method=mymethod&returnformat=plain
I'll do a blog entry on this later today.
Is there a way to control the x and y offset for the tooltip?
Not that I know of.
@Chris,
Regarding cftooltip positioning:
In CFIDE\scripts\ajax\yui\container\container-min.js, can you try changing yOffset=25 to desired offset? CF10 uses YUI 2.3, so cftooltip doesn't have an xyoffset attribute since YUI added that in 2.8.
Thanks,
-Aaron