<img alt="Liferay" height="36" src="http://cdn.www.liferay.com/osb-www-theme/images/custom/heading.png" width="146" />

Rank: New Member

Posts: 8

Join Date: December 2, 2010

Simple question from a Liferay rookie: Why does Liferay use this css.jsp file? What is it doing that CSS files cannot already accomplish more efficiently? Why not just take the styles unique to this JSP file and merge them into the standard set of CSS files used by a Liferay theme? Putting CSS in JSP seems to do nothing but introduce a big mess because it can introduce style definitions into the page from outside the CSS files (of which there are already too many) causing much time wasted trying to track down where these styles are coming from.

Most importantly: Is there an easy way to disable this css.jsp file from being used at all and what is the negative impact of doing so?

RE: Why the css.jsp file?

February 22, 2011 7:52 AM

Answer

Jonathan Neal

LIFERAY STAFF

Rank: Junior Member

Posts: 66

Join Date: August 29, 2007

Hi there!

In Liferay (portlets, plugins, and themes) the main stylesheet asset is named main.css, or main.jsp if the stylesheet is written with JSP functionality. JSP functionality is only used when absolutely necessary to perform server-side processing (like, for example, linking to the appropriate directory for image assets).

When any stylesheets are written with JSP functionality, a css_init.jsp is included in the docroot directory (of the portlet, plugin, theme). If no stylesheets require JSP functionality, then a main.css file will be used, (a main.jsp file will not be used, and a css_init.jsp is not included).

Mark as an Answer

RE: Why the css.jsp file?

February 23, 2011 7:15 AM

Answer

Rank: New Member

Posts: 8

Join Date: December 2, 2010

JSP functionality is only used when absolutely necessary to perform server-side processing (like, for example, linking to the appropriate directory for image assets).

Interesting. But doesn't each portlet or theme potentially have it's own CSS file(s) and images? And if so, why would we need dynamic path logic? Wouldn't the idea be to put all images common to the portal in one place (which would be well known and therefore available via static references in the CSS), and all portlet specific images in each portlet's WAR (which would also be well known and therefore static in the CSS as well). Still not seeing the need for JSP in the CSS. Maybe an example would help if somebody has one handy. I suppose maybe it makes sense if you have paths/context roots that are violently changing on a regular bases. When does that happen though?

I can see how using JSP to generate the CSS adds flexibility. I'm suggesting that maybe it's flexibility similar to the flexibility you get when you put SQL in JSP. You can do it, but you really shouldn't. It seems like CSS from JSP falls into the same category of a good technology being used badly to solve a problem that could be better solved by other means.

Thanks for the explanation though - and quickly too. I'm still learning how Liferay works and you've been very helpful.

Mark as an Answer

RE: Why the css.jsp file?

February 23, 2011 7:31 AM

Answer

Jonathan Neal

LIFERAY STAFF

Rank: Junior Member

Posts: 66

Join Date: August 29, 2007

Let's look at a very common example of JSP functionality being used inside CSS. I'm pulling this from the blogs portlet. To be specific, this is from lines 35-44 of \webapps\ROOT\html\portlet\blogs\css\main.jsp.

1.portlet-blogs .entry-author {
2 background: url(<%= themeImagesPath %>/portlet/edit_guest.png) no-repeat 0 50%;
3 border-right: 1px solid #999;
4 color: #999;
5 float: left;
6 font-weight: bold;
7 margin-right: 10px;
8 padding-left: 25px;
9 padding-right: 10px;
10}

In this example, <%= themeImagesPath %> is being used to reference the current theme path, which could be /cool-theme, or /awesome-theme, or (if you so chose) /plugins/awesome-theme. There is no way for the CSS to what the path to /portlet/edit_guest.png really is. Therefore, JSP functionality is (unfortunately) required.

I'm brainstorming now, and I'm not sure if anyone will even read this, but...

I would prefer it if all portlets bundled their own resources so that the assets could be referenced relatively, like background: url(../images/edit_guest.png), or, in instances where assets are shared between portlets, like background: url(../../shared-assets/images/edit_guest.png). It should be noted that "shared-assets" is an imaginary name I am giving this directory (and without much thought, so that I may reply quickly to your post).

What do you think?

Mark as an Answer

RE: Why the css.jsp file?

February 23, 2011 7:53 AM

Answer

Rank: New Member

Posts: 8

Join Date: December 2, 2010

background: url(<%= themeImagesPath %>/portlet/edit_guest.png) no-repeat 0 50%;

I see the problem. That is particularly tricky to handle in a case where you (Liferay) are providing a means to interject useful information into the CSS so that we (portal developers of the world) don't have to regenerate ALL the Liferay CSS files every time we want to use the means you've provided (e.g. when creating a new theme).

So the best practice seems to be that portal developers should keep their CSS in CSS files referencing resources bundled with the individual portlets; recognizing that Liferay has to internally render CSS using JSP to ease the maintenance and setup for theme developers. That seems like a workable compromise - at least as long as the Liferay CSS generators stay out of the way. That was my initial frustration in this case because I could not find where the styles were defined that I was seeing in the page. This may be just a documentation problem, or possibly more a theoretical concern than a practical one. Has anybody else had a problem with JSP generated styles getting in the way?

Interesting. Thanks again!

Mark as an Answer

RE: Why the css.jsp file?

February 24, 2011 6:49 AM

Answer

Jakub B

Rank: Junior Member

Posts: 82

Join Date: August 12, 2009

Jonathan Neal:

I'm brainstorming now, and I'm not sure if anyone will even read this, but...

I read it, I also agree solid idea for portlets.

Mark as an Answer

RE: Why the css.jsp file?

March 4, 2011 5:33 AM

Answer

Rank: New Member

Posts: 8

Join Date: December 2, 2010

background: url(<%= themeImagesPath %>/portlet/edit_guest.png) no-repeat 0 50%;

I had a thought on this. Instead of using JSP to generate the CSS, why not make a Liferay "theme service" of some sort. Liferay knows what your active theme is, and it can be different for different users. All those rules already exist, so why not package them into a servlet available at a well-known root. Then the CSS in the example above would have a static context root for all theme specific resources like this:

1background: url(/themes/mycooltheme/portlet/edit_guest.png) no-repeat 0 50%;

All resources in a theme would be rooted to /themes/<theme name> instead of using JSP to generate the context roots. Maybe a change you could consider for a future release? I think it would be much cleaner, more intuitive, and more clearly separate the page generation from the page styling.

Mark as an Answer

RE: Why the css.jsp file?

March 4, 2011 7:03 AM

Answer

Rank: Liferay Legend

Posts: 4496

Join Date: September 1, 2006

May work on the portal level, but not the portlets...

The portlets themselves use JSP so that they don't have to have static files for every possible theme that's deployed to the portal. JSP provides the flexibility so the CSS can be dynamic based upon the current theme, or available themes, or even future themes.

That's where your 'theme service' idea starts to fall apart...

Mark as an Answer

RE: Why the css.jsp file?

March 4, 2011 10:03 AM

Answer

Rank: New Member

Posts: 8

Join Date: December 2, 2010

But I don't need it work at the portlet level. Isn't a portal wide solution what we're talking about here? Themes exist at the portal level right? Unless I'm missing something, you wouldn't use themes to style a portlet. Themes exist to provide an easy way to style all portlets. The contents of a portlet that are not specified by the theme would be styled with that particular portlet. There still isn't any need for JSP generated CSS for that because you would bundle the CSS and images in that portlet's war, not externally in the theme war. If you had a theme servlet as described above, your portlet could access theme resources, or use it's own depending on whether it makes sense to do that or not. Either way, there is no need to cloud the issue by merging CSS and JSP.

Mark as an Answer

RE: Why the css.jsp file?

March 4, 2011 10:23 PM

Answer

Rank: Liferay Legend

Posts: 4496

Join Date: September 1, 2006

Not true at all...

One of the primary goals of portlet development is that the rendered content should look like it is a consistent part of the portal page.

After all, the portal is responsible for theming stuff outside of the portlet content; the portlet is responsible for everything it renders.

For example, I have a portlet which has a table with action icons to edit and delete the row. In order to get the icon paths, I've got to rely on the JSP implementation of the CSS so I can have the correct path to the image used in the surrounding theme. I want to use the theme's icons so my portlet's rendering is consistent with the overall portal view.

A static reference won't work unless I had multiple copies of the page each for the installed themes in the system.

Mark as an Answer

RE: Why the css.jsp file?

March 8, 2011 7:57 AM

Answer

Rank: New Member

Posts: 8

Join Date: December 2, 2010

I should have thought of this earlier. The answer is to make the proposed "theme servlet" just root to the active theme so resources can be accessed directly without reference to the theme name in the path. This example previously cited from lines 35-44 of \webapps\ROOT\html\portlet\blogs\css\main.jsp would no longer need to be in a JSP file because the CSS file could be written like so:

1
2.portlet-blogs .entry-author {
3 background: url(/liferay_theme_servlet/portlet/edit_guest.png) no-repeat 0 50%;
4 border-right: 1px solid #999;
5 color: #999;
6 float: left;
7 font-weight: bold;
8 margin-right: 10px;
9 padding-left: 25px;
10 padding-right: 10px;
11 }

This would cause the URLs for all theme resources to be static while the content delivered would still be dynamic based on whatever theme you have active (without requiring the CSS files to contain a static reference to the name of the active theme).

That seems like the upgrade we need.

Mark as an Answer

RE: Why the css.jsp file?

March 8, 2011 9:31 AM

Answer

Rank: Liferay Legend

Posts: 4496

Join Date: September 1, 2006

Except that you'd be blocking the use of a fronting HTTP server that can handle serving static resources, forcing everything through the application server...

Add to that problems that you're going to have with caching (cache an image, theme changes, image is not re-fetched) or you'll have to disable caching (increasing the hits on your app server)...

Mark as an Answer

RE: Why the css.jsp file?

March 8, 2011 9:34 AM

Answer

Rank: Liferay Legend

Posts: 4496

Join Date: September 1, 2006

Jeremy Gustrowsky:

That seems like the upgrade we need.

Why is this the upgrade we need? What is the problem w/ serving the CSS from a JSP file? Liferay is used in many different places, and I have yet to see anyone say they have a problem stemming from serving the CSS from a JSP file...

Mark as an Answer

RE: Why the css.jsp file?

March 9, 2011 4:50 AM

Answer

Rank: New Member

Posts: 8

Join Date: December 2, 2010

Perhaps terms like "problem" and "upgrade" are too strong in this context. My original dismay was centered around finding JSP generating CSS. Being new to Liferay, I wanted to know why it was being done this way. From the very good points you (and others) have raised, it appears that using JSP to generate CSS represents a trade-off between efficient dynamic theming, good use of system resources, and good UI architecture and design principles implemented in a Liferay context. I do realize that CSS (at present) is a rigid creature that does not allow for variables and other types of dynamic style modification in real time. Furthermore, and perhaps most importantly, I am not an idealist married to the idea that all CSS has to come from a .css file and there just can't be any other way. It appears there are good reasons for doing it this way, and that was the purpose for asking the question. At minimum this line of inquiry gives insight into the rational behind how Liferay is designed to function. Many thanks for that.

Mark as an Answer

RE: Why the css.jsp file?

March 9, 2011 12:54 PM

Answer

Olaf Kock

LIFERAY STAFF

Rank: Liferay Legend

Posts: 1437

Join Date: September 23, 2008

Jeremy Gustrowsky:

The answer is to make the proposed "theme servlet" just root to the active theme so resources can be accessed directly without reference to the theme name in the path.

Note that the active theme does not necessarily exist. If you introduce a static name to a servlet living in the portal context like here, you'll get a problem...

1
2.portlet-blogs .entry-author {
3 background: url(/liferay_theme_servlet/portlet/edit_guest.png) no-repeat 0 50%;
4... }

...when there are multiple themes used in a portal - e.g. one per community or per organization, or even by page.

Mark as an Answer

RE: Why the css.jsp file?

March 10, 2011 4:41 AM

Answer

Rank: New Member

Posts: 8

Join Date: December 2, 2010

when there are multiple themes used in a portal - e.g. one per community or per organization, or even by page

Interesting. I did not realize multiple themes could be used at once. That leads me to many more questions about how they are managed without causing problems but I will save those questions for another day after I've done some homework. Thanks.

Mark as an Answer

RE: Why the css.jsp file?

April 13, 2011 1:17 PM

Answer

Edward Coyle

Rank: New Member

Posts: 15

Join Date: October 8, 2010

This is a question coming from a graphic/web designer with very little Java experience, that also works on building Liferay themes...

I have to ask. Why do we even have to use Java or server-side variables to define these paths in the CSS file at all? What is the downside to just using relative paths within CSS files, as with most workflows involving CSS? Also, what other types of customization would require this type of variable placement within the CSS files? I've worked on lots of websites, and plenty involving other forms of CMS, and have never had the need to do this type of customization dynamically, so I'm just curious. To me, it seems like it overly complicates something simple.

If we need to have some custom design aspects in Liferay portals, why not keep the and variables on the Java side, as in writing variables into your portlets that return CSS class names, and have various CSS classes handle the design part? I know lots of designers that butcher code, and lots of programmers that butcher look/feel, so providing that separation of the two makes sense to me. emoticon

Mark as an Answer

RE: Why the css.jsp file?

April 13, 2011 1:21 PM

Answer

Jonathan Neal

LIFERAY STAFF

Rank: Junior Member

Posts: 66

Join Date: August 29, 2007

Edward Coyle:

To me, it seems like it overly complicates something simple.

You are exactly right. I don't like it either. I hope it changes. It is this way because it was made this way many years ago, because portals are complicated and the simple-seeming solutions are equally complicated, and because it's easy for Java developers to look at CSS like they look at Java.

Mark as an Answer

RE: Why the css.jsp file?

April 13, 2011 1:42 PM

Answer

Edward Coyle

Rank: New Member

Posts: 15

Join Date: October 8, 2010

Jonathan Neal:

Edward Coyle:

To me, it seems like it overly complicates something simple.

Haha, understandable. CSS is so far away from most programming languages. I can totally understand why it scares Java programmers so much emoticon