Naming Conventions in html elements in Report Studio

[EarthDog]

Hi All!
I have been reading on how to use javascript for various actions (like show/hide elements or default prompt dates).
On the later the code is something like:

Code Select Expand

<script type="text/javascript">
var fdf = getFormWarpRequest();
var listDateFrom = fdf.txtDatePDateFrom
var ftp = getFormWarpRequest();
function last90Days()
{
var ndays = 90;
var dtToday = new Date();
var dtlast90Days = new Date (dtToday - (86400000*(ndays)));
var strlast90Days = [dtlast90Days.getUTCFullYear(), dtlast90Days.getMonth()+1,
  dtlast90Days.getDate()].join("-");
return strlast90Days;
}
pickerControlPDateFrom.setValue(last90Days() );
</script>

I can see that this works only if the name of the prompt is set to DateFrom. Cognos prepends this control with pickerControl

I found no documentation on how cognos decides on all these naming conventions . Is there any info anywhere on that?

[CognosPaul]

This PDF might help. It's still missing a few objects, like pickerControl.

In general Cognos, and later IBM ,tended to be a bit tight lipped about the various functions available for prompts. Part of the reasoning is that they didn't want to support previous versions - if you wrote any JS it would be up to you to fix it on upgrades.

The Prompt API in 10.2 was their first supported JS API for Cognos. It's actually an abstraction layer - the underlying prompts still work with the same JS functions from 8.4, but you can call them through a standardized prompt. This actually allows them to make changes to the underlying API, and changing the function contents in the Prompt API to match. This allows reports to continue working through an upgrade.

Depending on the browser you're using, you can explore the various functions available in the API. I personally like Firebug, but any of the modern dev toolbars should work. Try also calling various functions and methods with this:

Code Select Expand

function getMethods(myObject)
{
  var funcs=[];
  for(var name in myObject){
    funcs.push(name)
  }
  return funcs.join(', ');
}



For example, in the console, run getMethods(getFormWarpRequest()); to see a list of functions associated with the form. Or getMethods(fdf.txtDatePDateFrom); to see what you can do with the dates. It's not perfect, but it's fun (at least for me) seeing what you can dig up.

[EarthDog]

I see...a whole new world to explore manually.....I found the api docs in the report studio user guide.

i suppose that you are behind this: http://cognospaul.com/ ..Added you in feedly!

What about everything else except prompts?

I mean about the main report area. What are the guidelines there for naming, giving id to elements e.t.c?

Its trivial to add jquery to any report so i need to get to know how Cognos automatically builds up the DOM.. Are there any resources/practices about this?

[bdbits]

I was poking around yesterday looking for the pdf CognosPaul mentioned, as that was how I originally got started with it myself. I was hoping to find an updated version but I do not think there is anything else available, for the reasons mentioned.

The advice to use Firebug (or other inferior dev tools :) ) is spot on and can help you understand a great deal about how Cognos pages are put together. You should do what you can with the newer prompt APIs. Cognos broke a lot of javascript between I think it was 8.2 to 8.3 and took a lot of grief over it; the prompt API is an effort to avoid that ever happening again. I am not sure whether the things I have done in the past are all supported but a lot of javascript snippets that show up on various web pages are.

If you want to gain your own access over things on a Cognos report page, learn to love the HTML Item. You can put anything in there, so you can for example create a <div> around a block of stuff you want to manipulate, add javascript snippets, custom controls, etc. Better yet, create re-usable objects and throw just the objects into a report and use layout component references. Then when you want to make a change to the way you are doing something, you have only one place to do it. It's a fun technique, we now use it with most of our projects.

And CognosPaul's blog is awesome.  8)

[EarthDog]

If you want to gain your own access over things on a Cognos report page, learn to love the HTML Item. You can put anything in there, so you can for example create a <div> around a block of stuff you want to manipulate, add javascript snippets, custom controls, etc. Better yet, create re-usable objects and throw just the objects into a report and use layout component references. Then when you want to make a change to the way you are doing something, you have only one place to do it. It's a fun technique, we now use it with most of our projects.

And CognosPaul's blog is awesome.  8)

I am loving HTML ..this period i am heavily using Laravel with knockoutjs so i am in the mood of doing funstuff with cognos reports.

Point me to this "re-usable objects" theory please ..

[bdbits]

I declare, I thought I posted about this technique before but you think I could find it? No - the answer is no.

Basically you create a blank report. In the report you place an object, let's use an HTML Item that has a custom button with javascript to pop an alert() for demonstration purposes. Give the item a name, then save this pseudo-report. This is now your component library.

Create a new report. Drag a "Layout Component Reference" item from the toolbox onto your report. In the dialog, pick "Another report" and hit the "..." button. Select your component library report you just created. Now the dialog will show you the objects on that "report", so pick your HTML Item button and click OK. So now you should see the HTML Item sitting there on your report. (By the way, if you set the Description property on the original item, that will show here.) Run the report, and your custom button will automagically show and you can click it to see the alert().

One caveat is that layout component references are not for data-based items like lists, crosstabs, etc. But you can create headers, footers, and other bits of standard layout you want to re-use as well as HTML Items with custom stuff in them. Oh, another use for HTML Items is creating <div>s with CSS so you can re-use them across reports. I used that on a project with pretty good results.

Hope that helps.

[CognosPaul]

Yay fans! Another example of merging JS and layout components: http://cognospaul.com/2011/09/06/layout-component-references/

This is also a much safer method of dealing with JS in Cognos, as the unpublished functions are liable to change without any warning at all. I've also asked (read, begged) the dev team for any JS documentation and got the following reply:

Code Select Expand

Hi Paul,

Nice hearing from you.

I checked with my development team. We unfortunately don't have a list of documented explanation for them. This is not something we'd publish anyways. We are not at a stage where we want to give the flexibility to customers to interact with these functions. Many of them will change from version to version. Please use them cautiously.

Cheers,

In cases where I'm interacting with internal functions, I try to use them as components. That way if (more likely when) the internal JS api is updated, we can fix the JS in just one place, instead of searching all over for it.

[EarthDog]

Thank you both guys!!!

I believe that IBM should focus more on the front end and on report design.

Developer documentation should be clarified more with use cases ,and of course front end lifting should be unified and brought to current standards...