In my previous post I wrote about how you can reduce the time it takes to publish your Yahoo! Store; and how that trick does nothing for speeding up the editor itself. To make the editor more responsive, the ONCE operator is not the answer. What you need to do - besides of course optimizing your RTML code to make it more efficient - is to identify and turn off slow pieces of your RTML - but do it only in the editor. As I mentioned in the previous post about speeding up store publishing , one of the most expensive or slowest pieces of RTML code you can have is a site-wide navigation bar, and especially cascading navigation bars, that not only reference the home page and its contents, but all of their contents as well. It is easy enough to turn off any piece of RTML code by using the WHEN operator. You can, for example, create a custom yes-no variable called "in-editor", and then take your existing site navigation and stuff it inside a WHEN @in-editor operator. This will do the

Recently I did a complete redesign in a store. As part of the redesign, I added a hierarchical, DHTML menu navigation bar to the site. In a typical setup, such a navigation bar works like this: use WITH-OBJECT :index to reference the home page, then cycle through the contents field, create a menu label for each page you find there, and for any such page, create a sub-menu if the page also has contents. If you didn't know until now, whenever you reference another object in RTML, such as using WITH-OBJECT or FOR-EACH-OBJECT, such a reference causes a disk lookup on the server. This is what we call an "expensive" operator; it is expensive in terms of processing power and time, so a navigation bar in general, and a hierarchical navigation bar in particular is an "expensive" template. In the store I was working in, they had over 4,000 pages, and of course, each of those pages had the navigation bar on them. So not surprisingly, the time it took to publish this site w