Styling Notes Views on the Web

Okay so a Web Application that uses Notes Views.

I would like to control the style (font-family, font-size, font-color etc.) of the view column titles and view column data.

Without Treat view contents as HTML the only way I see to do this is using the view column property box, change the font, size, colour etc. I really want to be able to set this in a style sheet (css) so that it can change for different users and different other things. Maybe I’m missing something, but the view properties always seems to override what I set in the css.

e.g. TD { font-color : red ;}

So I turn to “Treat view contents as HTML” where I can do everything that I need, but I hit the character limit in my view column titles!

{edit}The limit is 79 characters so the below example just fits, but I had to shorten my class names, shorten javascript function name (the javascript function is to sort by that column) and change from using spans to TD’s to get it within the limits. I’m also going to want to highlight the column in some way to show that it’s the column that is sorted. Not sure how to do that yet either but I’m sure it will involve more characters in the view column title!!!

View Column Title = Publication Name<A HREF=Javascript:sotC(‘0’)>^{/Edit}

I’m probably dreaming, but I thought it was possible to specify a formula for view column titles, although I can’t really see a valid reason for using that if it were possible.

So I suppose my question is, how can I specify a class for a view column (title and data) and/or how can I override the font properties in the properties box with my css.

Thanks

Ross

Subject: Styling Notes Views on the Web

If you want CSS to work from a stylesheet you need to leave everything at default sans serif 10pt… Domino will then serve a plain-vanilla table with the column titles as TH elements and the data in TDs. Well, not quite plain vanilla, since responses are created using tables nested in TD elements in the main table. If you set any other text properties, they are applied locally, that is, within the table’s markup – and in the game of CSS specificity, local wins over global every time. If you can eliminate the local styles, you should be able to style the view as you want without adding classes – unless you have to support older versions of Internet Exploder, which didn’t understand selectors like TD>TD>TD (that is, “apply this style to the third consecutive TD sibling”).

“Treat as HTML” can still work for you – you just need to use extra columns to do the HTML-spitting. Unfortunately, you lose a lot of functionality with “Treat as HTML” – I have yet to find a reasonable way to represent a categorized view that works in quite the same way as the real deal (you need to jump through a lot of hoops to get 80% of the way there), and you need to have a nearly-identical vanilla Notes view handy for each “Treat as” view to do a lot of the back-end stuff. Mind you, there’s a lot you can do with “Treat as” that you simply “can’t do in Notes”, by having the view spit JavaScript, f’rinstance, with column formulas like this:

“writeEntry("” + @Text(@DocumentUniqueID) + "", “"” + @DocLevel + “"”

“,"” + FieldName_1 + “"”

and so forth. The writeEntry() function doesn’t necessarily have to create a flat table (although it can) – I have used a similar strategy to create calendars, online games of chance (for charity fundraising during the United Way silly season), Gantt charts, and so forth. But since it relies on JavaScript, that sort of thing is best left for situations where a non-tabular data visualization id the object of the game.

I have created a bit of JavaScript that tidies up a “Display using HTML” view, and you may want to consider trying it out just for the halibut. It can be modified to eliminate tags and local styles as well. It is, as all things are at OpenNTF.org, free – gratis and libre – and open source (although there is an obfuscated/minified version there to minimize the download hit).

Subject: RE: Styling Notes Views on the Web

Thanks Stan, although I didn’t understand your writeEntry() example.

"f’rinstance, with column formulas like this:

“writeEntry("” + @Text(@DocumentUniqueID) + "", “"” + @DocLevel + “"”

“,"” + FieldName_1 + “"”

and so forth. The writeEntry() function doesn’t necessarily have to create a

flat table (although it can)"