Common applications of .js to prompts.

[MDXpressor]

Hi All,
I'm trying to force a tree prompt display to re-expand to the current selection once the page reloads.  Further, I generally admonish the use of scripts, but I do recognize that it makes stuff better, and in some cases you just shouldn't do it any other way.  If I had a script to re-expand a tree prompt I would never go live without it. 

I am a .js lightweight (read: I plagiarize other peoples good ideas and give back to karma with answers in other topics). I could use a mentor, and there's no better community for mentors, than Cognoise...  If this were a Classified Ad, it would read:  Willing to trade MDX experiences for .js education.

Do you have any examples of .js that you simply won't deploy without? 
Do you use jQuery to manage those standard scripts?
Do you leverage the dojo toolkit?

[bdbits]

"MDX experiences" ... hmm, can you be more specific? I need to know what is up for trade.  ;)

You should browse through http://cognospaul.com/ for some real gems. This is the same CognosPaul who hangs around here. There is some really good stuff on his blog. I seem to recall there are some posts dealing with tree controls so maybe that can even help your current problem.

Personally I try to find ootb ways to do things but yeah, sometimes that just does not do the trick. Things are somewhat better in 10.2 so I no longer need js to do things that are now in the UI. The newish prompt API can simplify things a bit when you do need javascript. If you have not looked into that you should. I mostly find myself using javascript for mundane things - dynamically setting defaults for prompt controls, altering styles not normally possible from the Cognos UI (e.g. horizontal radio buttons), tweaking inline prompts, etc. And though not strictly javascript, I have made a lot of use of HTML items that include snippets of javascript in an onclick event. For example, dropping buttons on reports to rerun searches based on inline prompts without auto-submit, or export to PDF/Excel/etc. Some of these are not cannot-live-without, but all help to make the reports look that much more professional, refined, and looking less like a "Cognos report" and just more pleasing to use for the end user.

I have not used jQuery for Cognos stuff. I understand the DOM pretty well due to past work experiences, and for the little things I do I find I do not need it. Very much a ymmv kind of thing, I suppose. Funny you mention dojo, as I was recently tracing through some of the Cognos libraries and that is what they appear to be using. I did not know that and now it is something I will likely be looking into for my own education if nothing else.

One thing I will say more for the benefit of others reading this rather than for you, MDXpressor. I see a lot of people flailing about with javascript and getting very frustrated. Most of the time, I feel this is due to a lack of knowledge on how web pages are put together and how javascript works with that, independent of anything Cognos specific. If someone does not understand the DOM and how to manipulate it with js in general, they really ought to step back and learn a little before tackling Cognos pages. Due to the dynamic page generation, sometimes just getting a reference to the thing you want to change can rely on what many would call advanced techniques. People should try and understand what the script is doing, especially before trying to change it.

I like Cognos. It's expensive, but I think it is pretty capable in the right hands. That you can manipulate it the way we do with javascript is pretty cool and sometimes, actually fun.  8)

[navissar]

Do you have any examples of .js that you simply won't deploy without? 
Do you use jQuery to manage those standard scripts?
Do you leverage the dojo toolkit?

Well.
I seldom deploy without some sort of tabbing solution (This one is my personal favourite because it can be managed after I've left - that's why I've written it to begin with : http://cognospaul.com/2013/12/22/tab-solution-thats-easy-maintain-without-code-guest-post/).
I never hand over a solution without some scripts/css to handle design issues, such as re-shaping prompt buttons. This is a fine example, IMHO, of a mixture of OOTB functionality which is then empowered by scripts: I create a block, style it to look like a fine, modern looking button, and use JS to copy the style to the actual prompt button.
I have a solution I've written based on prompt API which goes over all the prompts on page, gets their names and selected values, and then displays that in the report page. I ALWAYS use that because it saves an awful lot of time on dragging in layout calcs for the same purpose.
Since I try to avoid S&S prompts like the plague, I have a bunch of solutions to replace these I often use.
So all in all, a typical solution I deliver would have quite a bit of scripting in it. My rule-of-thumb is: Use scripts when you cannot use OOTB functionality for UX, functionality and/or better dev times. When you do, make your script as general and up-gradable as possible .

jQuery:
Nope. Nope nope nope nope nope. It is VERY tempting to implement jQuery plugins which save on code and look nice and sleek. Thing is, these ALWAYS end up clashing with Cognos objects on some scenarios, resulting in horrific errors and terrible looks. So nope. Pure JS or none at all for me. (Having said that, I have been toying around with angularJS, and thought of some ways to incorporate it in Cognos).

Dojo: Never actually needed a toolkit, but it might be useful for beginners.