Dev Studio is quickly becoming a "head-to-desk" application when it comes to styling reports, mostly because I'm new to WF, partly because I also do web dev, where styling is straightforward; my newest issue is that ReportPainter copies a chosen stylesheet to the application folder of the report.

Ultimately I will have around 150 reports, and for ease of maintenance they are divided into five different application folders, with one "common" app folder to hold stylesheets and images for use by the reports in each of the five applications.

I want to have just one place where my custom stylesheets live, for the obvious reasons. The trouble is that when, in the ReportPainter, I choose my style file, it lets me pick it from another application folder, but then it COPIES it to the local application folder, which I do not want it to do.

How do I get around this behavior? Is there a way to turn it off, or is there a location I can put my shared stylesheets so that they don't get copied to each application folder? Where are the default stylesheets, which apparently don't get copied when used?

This message has been edited. Last edited by: J.Hines,

Answer: You can't.

I asked myself the same question a while ago. But I figured out why WF does this. And it's for a good reason.

Suppose you have 1 application 'X' with the style-sheets.
And 2 other applications 'Y' and 'Z' with reports refering to the style-sheet in application 'X'.

What is a user is authorized for application 'Z' but not for 'X'?



but that's not what you want to hear...

What we've done is create a very simple stylesheet ( the WF kind ) with only references to classnames.
And make a elaborate stylesheet ( the CSS kind ) with definitions of the classes. Since the CSS is linked by the user's browser it must be in the web-applications. Et viola ! One single location to change the look and feel..

e.g.
portal.sty

$
TYPE=DATA,
     CLASS=datas,
$
TYPE=TITLE,
     CLASS=titles,
$

portal.css

.titles
{
border: 0px;
border-top: 1px solid #dddddd;
border-left: 1px solid #dddddd;
border-right: 1px solid #dddddd;
font-weight: bold;
background: #eeeeee;
text-align: left;
font-size: 7pt;
}

.datas
{
border-top: 1px solid #000000;
border-bottom: 1px solid #000000;
border-left: 1px solid #dddddd;
border-right: 1px solid #dddddd;
}
.datas *
{
border: 0px;
}

( and yes, you'll have to copy the .sty in all applications )

And don't forget to

SET CSSURL=http://<weblocation>/approot/baseapp/portal.css

G'luck
Dave

This message has been edited. Last edited by: Dave,

Thanks Dave, you're right, not the solution I hoped for, but very workable nevertheless, and in fact answers another question I had which was how to effectively use an external CSS file without assigning class names in every procedure.

So thank you on both counts.

My question then is how to convert some of the WF stylesheet declarations to CSS declarations. For instance, I have these three styles for a bold header with a second line that is not bold. The second line looks like "Client:

 
TYPE=HEADING,
    LINE=1,
    style=bold,
    size=12,
    justify=left,
$
TYPE=HEADING,
     LINE=2,
     OBJECT=FIELD,
     ITEM=1,
     SIZE=10,
     STYLE=NORMAL,
$
 
TYPE=HEADING,
     LINE=2,
     OBJECT=TEXT,
     ITEM=1,
     SIZE=10,
     STYLE=NORMAL,
$ 

Can I assign a class to the field object of the second line of the heading, or am I restricted to just assigning high-level classes by TYPE?

This message has been edited. Last edited by: J.Hines,

---

Prod: 8.2.0.4 OS:Windows 10 Output:AHTML, Excel 2007+

The life of a designer is a life of fight against the ugliness.

Glad to have been helpful :-)

Yes, you can add the CLASS='' to any part of the style sheet.

In fact you have to do this by hand if you have a procedure with a drill.

in my example I have to add the CLASS='datas' to all, just to keep it the same look.

Greets,D

Don't forget that the CSS style will not work for PDF reports. You'll need regular WF styling for PDF.

Francis, how about for Excel reports? I have no PDF, just HTML, AHTML, and Excel2000/2007.


I just found another solution that works I think better, but still having a browser caching issue.

I have a common WF stylesheet (commonstyles.sty) in my common app folder, but in the folder where my procedure is, I have a very simple WF stylesheet that simply says INCLUDE master_ahtml. So:

  
  -icr-common [app folder]
  |___ master_ahtml.sty
  
  -icr-group1 [local app folder]
  |___ happy-procedure.fex
       |____ ON TABLE SET STYLE * INCLUDE=ahtml, $

  |___ ahtml.sty
       |____ INCLUDE master_ahtml

This actually does work and doesn't cause my common stylesheet to get copied to the local folder. Does anyone have any reasons why I shouldn't use this approach?

Also, it appears the browser is caching the stylesheet. Any way to keep that from happening? This is more troublesome with Excel output since you can't refresh it like you can with HTML output; the only way is to close the browser altogether, but in HTML, you can only refresh, a browser close/reopen uses the cached sheet. How do I tell it not to cache regardless of format?

This message has been edited. Last edited by: J.Hines,

Okay, I take it back. ReportPainter has once again decided it can only do things one way, and it's aggravating.

While the report runs fine using the above method, with the internal stylesheet including the common stylesheet, reports will now no longer open in the ReportPainter due to "Unknown parsing error" which basically means it can't find the stylesheet.

I'm new to WF development and I already loathe it in places. I would love to find a product that provides great report-building capabilities but that doesn't make it so hard to apply design that doesn't look like it was done in the mid-90s.

If you open the Excel output in a new window (using target="_blank"), then you can shift+reload that window to get an uncached version of the sheet out.

The parsing error is AFAIK not because report painter can't find the stylesheet, but because report painter doesn't understand dialog manager code. If you comment those lines out, then report painter is happy again. A word of warning: It will move all those comments out of the way to just before the report definition.

The product dates back from before relational databases (and language design classes it would seem) and apparently that's a reason that things are as they are. Unfortunately that also implies there has been plenty of time to fix at least some of those issues.

That said, WebFOCUS does have a number of good features, mostly in the core FOCUS language.

But note that CLASS= does not always work as expected.

When you specify SET HTMLCSS=ON, WFRS inserts css rules, and attaches matching class declarations to corresponding html tags -- but in the process it suppresses user-supplied CLASS declarations appearing in the stylesheet section with respect to those html elements.

That interferes (gratuitously, I submit) with the developer's degrees of freedom.

It needn't be so. In the generated CSS rule, the filter of, say, ".wf023" is equivalent to "[class~=wf023]", which formally matches elements whose class consists of space-separated words one of which equals wf023. A class value of either "wf023" or "wf023 myclass1" would fire the rule. So WF could generate a class value that combines the WF generated trigger value and the user-specified CLASS value, and the browser would apply both the wf-generated and the user-supplied css rules.

Naturally they have to play nicely together; but guidelines can be provided to cover conflict avoidance and conflict resolution.

[What do you say, Mr Glick?]

I agree with you Wepp and J. I'm used to web dev, where it's largely "if you design it, you can build it with CSS" and I was just under the incorrect assumption that I would have the same level of control and freedom here as well, and sadly that's not the case.

I didn't really know any FOCUS before starting this project, but I am quickly learning it and preferring the text view to anything in the painter.

To answer my original post, it seems that, despite my refreshing the view after trying my solution, the internal stylesheets are in fact copying the common stylesheets to the local folder, thus defeating the entire purpose of having shared stylesheets.

So I throw up my hands in defeat on this one. I'm just going to use WF stylesheets in each of my five application folders since there's no way to point to a common one, and though I like Dave's workaround, since I have some Excel output, I don't want to have to mess with how WF will translate CSS into Excel style. So my "solution" is to have three stylesheets (one for each of three output formats I'm using) and just copy the sheets to each additional application folder.

Thanks so much for everyone's help and ideas. It's just as important to find out what can't be done as to have the solution I was looking for.

quote:

But note that CLASS= does not always work as expected.

When you specify SET HTMLCSS=ON, WFRS inserts css rules, and attaches matching class declarations to corresponding html tags -- but in the process it suppresses user-supplied CLASS declarations appearing in the stylesheet section with respect to those html elements.

We always use SET HTMLCSS=OFF and then supply our own cascading stylesheet using CSSURL. Our FOCUS-stylesheet for HTML output contains lots of CLASS=a b c references to classes defined in that cascading stylesheet.

Over a time of several months I have largely automated the process of including the right files and the right stylesheets depending on the desired output format. I also wrote and fine-tuned the stylesheets during that time.

One thing that I ran into is that if you make heavy use of CSS classes, the CLASS-property in the FOCUS stylesheet is limited to 23 characters. You tend to run into that limitation if you're in the habit of combining classes (see also j.gross's example).
I opened a case about that and they fixed the documentation to mention that limitation - which is of course only marginally helpful.

What I find really lacking in FOCUS styling is that the various bits of HTML that make up a report have NO distinguishable identifiers that could help you style them. It would be helpful to be able to style the entire header- or footer-section or the report table. Instead you're limited to styling individual lines or cells in those, for example: TYPE=HEADING, CLASS=foo,$ - which adds class="foo"[1] to each line in the heading.

[1] Heh, nothing so nice! It adds CLASS=foo instead; capitals for the attribute name and no quotes around the attribute value.