Hi guys and gals,
How do you create nice buttons which drop down when you hover over them with the pointer.
e.g. You hover over the text and more options drop down: http://www.prominic.net/ is an example.
Not exactly like this, but you get the general idea. Is it in depth and you need to use java? If so I am screwed.
Thanks for any advice.
Matt.
Subject: Web Site Drop Down Buttons
Typically they are known as DHTML menus and do not involve Java.Rocky Oliver recently posted an article on this subject:
http://www.lotusgeek.com/SapphireOak/LotusGeekBlog.nsf/d6plinks/ROLR-69EJPF
Also lots of DHTML menus on the web if you search google.
Subject: RE: Web Site Drop Down Buttons
Just a note that DHTML is kinda the same as JavaScript. DHTML is just Microsoft’s name for JavaScript, probably because of some copyright issues with Sun/Xerox, like always. As I understood, DHTML does everything what JavaScript does plus a ton more, and the programming language is 99% identical.
Subject: RE: Web Site Drop Down Buttons
No – DHTML is not a language, it’s the result of combining JavaScript (Microsoft’s version of the language is called JScript), HTML and (usually) CSS to create “dynamic HTML”. By using JavaScript (or JScript) to manipulate the in-memory HTML document, its data, its elements and the properties of its elements, you can transform the page to appear almost any way you want. Almost every aspect of a web page can be altered or removed, and new elements can be added on-the-fly as required. There’s nothing you can’t do with DHTML – except make it work properly in Netscape 4.x without medication.
Subject: RE: Web Site Drop Down Buttons
Thanks for the clarification, Stan.
Subject: RE: Web Site Drop Down Buttons
Mika,
Please don’t tell me you wrotye what you did? Where did you ever get this notion?
Subject: Web Site Drop Down Buttons
They are usually done with JavaScript, and you’ll find tons of examples which you can use in your own applications, when you look in google for “javascript pulldown menu” or “javascript popup menu”.
I found this one interesting:
These one’s are also nice:
Subject: RE: Web Site Drop Down Buttons
Thanks guys,
I will have a look at the link(s) and let you know if I am able to put something useful together.
Not that your links are bad, just that I am an L plate domino developer and everything seems to be taking lots of time.
Just spent (if honest) the best part of 2 days sorting a nice looking table using “Output as HTML”, with images, document links and everything else you take for granted when just browsing. . . .
Cheers,
Matt.
Subject: RE: Web Site Drop Down Buttons
A small hint regarding views on the web: Sooner or later you will end making them as LotusScript agents anyway (when you reach the limits of Notes views, or when your database grows bigger, and you need faster performance), so why waste time using Views at all. On the web you usually show like 100-500 lines per page, and Notes Views are very clumsy making that small amount of data come up fast. That’s one reason for the perfomance lack, another big performance lag is caused by categorized views on the web, which easily take 10-20 seconds to open, while an LotusScript agent does the same job and much more (including relational database joins, editable fields in the view level, buttons, thumbnails, and much more) in far less than 1 second. And not to speak of search results views, which show the response documents in no sense-making order, with a simple LS agent you can show the search results nicely ordered by main documents, and each response document under them.
Subject: RE: Web Site Drop Down Buttons
Hi Mika,
Interesting observation with the performance of agents versus views. If you are referring to calling agents from a url (http://host/db/agent?OpenAgent) or from a WebQueryOpen agent, then I have never seen an improvement in performance versus views.
Have you done any scalability tests to prove this? I’m currently working on a project where the goal is to remove all ?OpenAgent url calls and to eliminate all WebQueryOpen agents due to the fact that when the server is under a heavy load, these agents will significantly slow the server down. CPU usage goes thru the roof and thus end-users experience very poor response times.
We’re still on R5 and I’m told that WQO agents and agents called from the url are much faster in ND6.
Jack
Subject: RE: Web Site Drop Down Buttons
Jack, my own experience is 180 degrees off of Mika’s suggestion. I have found that a restrict-to-category view displaying a single document’s data on a minimal “Treat as” $$ViewTemplate was the best way to achieve near-real-time updates of in-browser data via HTML requests or XMLHttp requests (both GETs). In a particularly-poor implementation (Domino was used because it was available and quick to build on, not because it was the best tool for the job), I had a peak of 1500 users making 36 such requests per minute each (6 items to update, one update request per item every ten seconds) with no noticeable lag on a single-processor PIII-800.
(The application, for anyone interested, was an online charity auction set up in four hours for a bit of emergency fundraising. There were six items auctioned per day, with updates of high bidder and bid on each item every ten seconds or on bid, whichever came first – competition was at least as big a driver as the items themselves or the charity. The “you can’t have it, it’s mine” frenzy at the end of the day, combined with the giggling spectators, worked the heat sinks on the old dev server pretty hard, but it did survive.)
Subject: RE: Web Site Drop Down Buttons
I had one extreme case, where a view in a production database took over 4 minutes (!) to open. Some customers complained that they cannot even open the view, because it timed out on their browser. The view was put as embedded view in a viewtemplate form, and displayed with the singlecategory option, so it was categorized by the lookup key. I rewrote the view with an agent (removed the categorized column, and put it as plain sorted, and using view.getalldocumentsbykey got the documents in the documentcollection), and it opened in 1 second.
Subject: RE: Web Site Drop Down Buttons
Ahhh. I bet that the category column was looking at a field that had many entries. I too have seen this slow down categorized views. You definitely don’t want to use a field for a categorized column if this field always contains a lot of entries.
One approach that you could have done instead of the agent, however, was to use &StartKey=xx and &UntilKey=xx~ in the url to get all of the data for this key/category. You still change the column from a category column to a plain sorted one and hide it from display.
Subject: RE: Web Site Drop Down Buttons
The web server was still 5.0.13a when we had to fix this issue. It seems that the UntilKey URL parameter did not exist in R5, since it’s not mentioned in the R5 Designer Help.Another problem would be to determine the value for UntilKey, I don’t see any mention in the R7 Designer Help that you could say something like !UntilKey=A (until key is not A), and the Form only has the value for StartKey available.
Subject: RE: Web Site Drop Down Buttons
Note that Jack’s untilkey was the same as the startkey, except there was a “~” at the end. The untilkey is a “failure value” – you want a value that will not include anything beyong the current “category”, but which does not actually appear in the view.
Subject: RE: Web Site Drop Down Buttons
You’re right. They do not do a good job of documenting all of the available parameters.
The UntilKey came out in 5.0.8. It was done for the iNotes development team so that they could use the xml returned by the ?readviewentries url command while working with the calendar. To work with date/time columns you also must use the &KeyType=time parameter.
Take a look at this post I did a while back:
http://www-10.lotus.com/ldd/nd6forum.nsf/0/ae818b3d21a6010885256f48007d7f6d?OpenDocument