Forum .LRN Q&A: RFC: Portlet shading

We're looking at adding javascript/css based shading of portlets to SloanSpace. The idea is to provide a way to shade and unshade portlets without requiring a round trip to the server.

Our initial implementation works great but raises some architectural issues.

Most importantly, the current shading system performs the "am I shaded?" check down in the portlets themselves. Hence in the portlet .adp files you'll typically see this construct:

<if @shaded_p@ ne "t">
   *** portlet content goes here***
</if>

This presents a problem for client-side shading. Namely, if shaded_p is true, the portlet's content is never shipped to the client, so can't be unshaded without a roundtrip. To make this work on the client, we must always set shaded_p to true.

Now, we'd still like to keep track of the shading state with client-side shading, we just can't use shaded_p, at least as currently coded. We have a few options. The first is to add a new portal parameter "cshaded_p" to track the client-side shading state. Adding this would require touching a lot of SQL, and doesn't quite feel right since we already have a parameter for tracking shade state.

A second option would be to rearchitect the portal system slightly to make shaded_p more flexible. Suppose, for example, that we moved the shaded_p check out of the portlets and moved it up to the theme level, and left it up to the theme to decide whether and how to handle the shading.

A third option would be to track shading state via cookies. This has the benefit of requiring very little refactoring(it can be done almost entirely in the theme .adp file), but like the first solution, has the odor of solving the same problem in two places that could potentially interact to bad effect.

My gut says the second option is the way to go. How would this affect your .LRN installation, if it all?

Also, which of the options (or others) would you support? To sum them up:

1. Add a new parameter and track client-side shading separately from the old-style server-side shading. Requires lots of new SQL, upgrade scripts. Adds a second, parallel shading system.

2. Move control of the shading to the theme level and let the theme decide how to handle it. Portlets lose control over what they can hide or not hide (should they have that control?).

3. Control client side shading via cookies. Minimal changes to existing code. Adds a second, parallel shading system.

I think you should add client sided shading and use the shaded_p parameter to control the javascript/css default parameter for each portlet.

E.g. if you have a JS variable "my_portlet_shaded_p", this controls the shading state on the client side. The shaded_p variable controls to what the my_portlet_shaded_p JS variable should be set whenever the server sends data to the client.

Obviously you would remove the < if @shaded_p@ ne "t"> part :).

Andrew, the basic idea is to do as much as possible using the Javascript interface. This is what I meant with "my_portlet_shaded_p" variable which you need, as shaded_p is the name of the variable for each portlet displayed on a page. So, to differentiate in Javascript you have to give each shaded_p TCL variable a unique name.

Then you could use this variable to toggle shading on and off using Javascript. The TCL shaded_p variable comes from the portlet and sets the default value for my_porlet_shaded_p.

This is more a portal system issue than a theme issue, so it is not taken to the theme level.

One issue though: How is the value in my_portlet_shaded_p stored back on the server for the user, so next time he accesses the page he will see the portlet shaded (or not).

The content of the portlet is always transfered from the server to the browser and the browser decides using JS depending on the my_portlet_shaded_p (e.g. forums_shaded_p) parameter whether to display the content or not.

Have you guys tried xml-http (ala gmail)? I think it can be used here, we have used it to great effect on dynamic form templates.