Hi Michael,

Long rambling questions are often ignored on user lists.
Its a lot easier for us to answer questions that are directly to the point covering one subject. Additionally, it complicates things for users searching the mailing list when the subject title includes "and other matters" ... so we would actually prefer that you sent 3 concise emails with specific targeted questions than one long rambling email cover "other matters".

Church Michael R wrote:

What I want to do is to display a portlet on EVERY page, no matter what part
of the portal site is being displayed. As far as I can work out, the only
way to achieve this is to add the appropriate portlet fragment to every PSML
file on the portal site. This would work, but what a tedious task that would
be!

Is there a better way to achieve this?

I just read your response to your own email.
Could you send us a snippet of your layout, showing others how you did this? I think we should look into a more formalized way of providing this feature for everyone.


Also, I want the contents of my portlet to automatically refresh itself
every 60 seconds or so. How would I achieve this? I thought the rss::RSS
example portlet might do this (to refresh the RSS newsfeed every 3600
seconds, as it's supposed to do), but it appears that it doesn't do that.

You can build this into your portlet using your own timer
The RSS portlets do have a refresh timer on them
                <preference>
                        <name>minrefresh</name>
                        <value>3600</value>         
                </preference>     

The portlet spec has a feature for cache content expiration specified in the portlet.xml Its optional and we haven't implemented it yet (high onthe list for 2.1 release or sooner)

    <expiration-cache>15</expiration-cache>


An alternative I've come up with is to create a servlet instead of a portlet
(my portlet really is very simple, and could be easily converted into a
servlet). Then I could change the header.vm part of my layout decoration to
install a fixed fragment of HTML and Javascript that would display the
results of my servlet on every displayed page of the portal; the Javascript
would use XMLHTTPRequest to fetch a fragment of HTML to display in the HTML
fragment (<div>). My idea is that this fragment of HTML could be placed
above the left-side navigation menu, so that it is always visible whenever a
user enters any page on the portal. The trouble with this approach is that
ALL visitors to the portal will see that HTML fragment. If I could find a
way within header.vm to determine if the user has logged in and has
appropriate viewing permissions, then I could arrange to NOT include this
HTML fragment in appropriate cases.

Any ideas on how I could find out in header.vm whether the current user of
the portal is logged in and has appropriate permissions?

Or does anybody have a better idea altogether?

Im not really following this, but it sounds like you want client-side rendering?

We do have a portlet pipeline for this kind of thing.
The default pipeline in jetspeed uses a 'page pipeline' delivering an entire page. For client-side (AJAX) aggregation, use the portlet pipeline to retrieve the content of each page. In addition, we have an AJAX API for retrieving the entire PSML page, which can then be used by a clientside aggregator. We do have plans to formerly put this into Jetspeed, but I can understand you wanting to do it outside the scope of open source.

Anyway, now Im doing it. Im responding to 3 different threads in one thread


My aim is to have an auto-updating portlet that is always visible to logged
in users on every page that the user visits, and that is not visible to
users that are not logged in at all. This could be achieved as a portlet, or
as a fragment of HTML that appears in the portal header (or footer, for that
matter). Either way, it must not be visible to users that are not logged in,
or who are logged in but who do not have the appropriate permissions.

Suggestions would be most gratefully received!!

Start a new thread on this one

-------

On a totally unrelated issue, I am having real difficulty in understanding
the folder.metadata file. There is documentation available on the Jetspeed 2
website, but I find it difficult to follow. I think an "idiot's guide" to
the file might be helpful for dunces like me, especially in respect of how
to construct the left-side navigation menu. The examples provided in the
distribution are not very helpful in this respect (they raise more questions
in my mind than they answer).

Is there an idiot's guide to folder.metadata files anywhere? Or some
examples with explanatory notes?

start a new thread on this one

-------

BTW, I initially considered using Jetspeed 1.6 to build my portal, mainly
because the only available complete tutorial on Jetspeed was based around
version 1.6. But I thought, what the hey, let's use the most up to date
version of Jetspeed (version 2), it must have better features, and it surely
can't be anything other than an upwards-compatible version built on top of
version 1.6. It seems I was wrong. Unless I am very much mistaken, Jetspeed
2 seems to be a significant re-work from version 1.6, and most of the
tutorial material from version 1.6 does not apply to Jetspeed 2. There is
precious little tutorial material available for Jetspeed 2, it seems, which
makes it difficult for a Jetspeed virgin like me to get started at all.

You are absolutely right.
The 1.6 tutorial is very valuable.


Am I right in what I say above? Ie that Jetspeed 2 is not upwards-compatible
from Jetspeed 1.6?

have a look here for a comparison:
http://portals.apache.org/jetspeed-2/j1-users.html

Portlets need to be ported to the Portlet API
We considered writing a bridge to the 'old' Jetspeed Portlet API, but it seems better to just have people write their portlets the 'standard' way

PSML has changed slightly as have security constraints
So you have to convert all of these artifacts


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to