You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-user@portals.apache.org by Emanuele Scaglia <em...@realtech.it> on 2002/04/03 10:55:38 UTC
Re: can we "lock" user navigation inside a portlet?
Hi Terry,
I'm trying to do exactly what you explained, I'd be interested in your code if you can release it.
Thank you in advance
Emanuele Scaglia
portlet by role/group
Posted by Josselin Lebret <jo...@sycomore.fr>.
Is it possible to set portlets for a new user according to his role or his
group ?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: can we "lock" user navigation inside a portlet?
Posted by ZHU Jia <ji...@ains.at>.
Hello,
> I have a working implementation of a WebPageProxyPortlet. The code is
> still immature but with the gracious blessings of the the company I
did
> this for, RyTE Consulting, Inc., I wish to refine and contribute it to
> Jetspeed.
I would really greatly appreciate such a solution, this is exactly what
I need!
In our project, we need to build an interface of our existing web
application to a portal (Jetspeed). We defined our own navigation in our
app, mostly servlet based and with much interaction (HTML form based).
Of course it would be great to have the user navigate in the portlet
area instead of let them jump out of the portal as soon as they submit
anything to our application. I haven't looked at the IFramePortlet yet,
but generally I'm reluctant to rely on any *new* HTML features.
So your solution will be the perfect one for our situation, I'm really
looking forward to see it in action!
Many thanks in advance"
regards
ZHU Jia
--
A computer makes as many mistakes in two seconds as 20 men working 20
years make.
- Murphy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: can we "lock" user navigation inside a portlet?
Posted by "David G. Powers" <je...@pssp.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wednesday 03 April 2002 09:21 am, Ozgur Balsoy wrote:
> We have also worked on the WebPagePortlet for navigation.
Cool stuff. Looks like you used a similar technique.
I use a derivative of the HTMLRewriter to inject a proxy servlet in <FORM>
actions and <A>nchor & <AREA> hrefs. The original URL gets placed in a
hidden field (forms) or the querystring (A & AREA).
Are there any "special circumstances" that you had to overcome when
creating yours? I'd appreciate a heads up on any "gotchas" you've
identified.
Thanks,
DP
- --
David G. Powers
PowerSource
-----BEGIN PGP SIGNATURE-----
Comment: Verify the authenticity of this message with the public key available at http://pssp.com/dgp_pk.asc
iD8DBQE8q0iVjmjAPDT0/nERAuNVAKDpjudtubFEInWlrybZpXe+Lc39CACg0Qha
r2zBF4HS6VqLRuV/l82Pj0k=
=LapC
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: can we "lock" user navigation inside a portlet?
Posted by Ozgur Balsoy <ba...@grids.ucs.indiana.edu>.
We have also worked on the WebPagePortlet for navigation. Your version
looks more complete and for general use, and we'd be happy to use it.
Our version, we call it OKCWebPagePortlet, right now handles GET
requests and preserve color and font faces. I need to add form posts and
session preservation. If any one is interested in the current version,
please go to
http://judi.ucs.indiana.edu/okcportal/
This site is an experimental site. So it may not be online all the
times. Login as guest/guest and try ERDC, ARL, CEN and CEA panes. CEN
and CEA panes run JavaScripts.
The issues to address are:
- navigation. Keep users within the same portal display with a different
HTML page.
- multiple WebPagePortlets. There can be more than one WebPagePortlet on
the display and each should keep their current views while users
navigate on the other.
- errors in HTML structure. The downloaded HTML might be faulty and when
integrated with the portal, it may damage the portal layout.
- images. HTML links can be rewritten to preserve navigation, but how
about images? Are they going to be downloaded from the content provider
directly or through WebPage[Proxy]Portlet? If directly, what about
sessions and security? If not, what about portal overload for lots of
images passing through the portal?
- JavaScripts. Expecially rollover image usage or image names which are
relative cause problems and raise the problems as mentioned in images.
[i.e. image[0].src="hello.gif" ] How to/Should we detect this code?
- headers. Will we bother to keep headers? If removed, scripts are also
gone resulting behavior changes. If not, expected results from different
portlets, i.e. refresh META tags, different TITLE tags.
- frames. Ignore all or choose a subframe?
- dedicate it to a certain content host? If we have the control over the
content, or provide guidelines to write the appropriate HTML for portal
usage, then we might need to detect if the URL leaves the dedicated
host.
These are issues we had to work on. We had to choose one way or another
to step forward. We are still in the development stage. We also try to
integrate Jakarta SLIDE project as the content hosts.
The document I am trying to write up is available at /okcportal/okc.doc
at the above URL. It's just a few pages at the moment.
Hope these help.
Ozgur
-----Original Message-----
From: David G. Powers [mailto:jetspeed-user@pssp.com]
Sent: Wednesday, April 03, 2002 11:09 AM
To: Jetspeed Users List
Subject: Re: can we "lock" user navigation inside a portlet?
I submitted this on the dev list last week. I'm in the middle of an
implementation which will keep my attention for the rest of this week
but.... Next week I will draft and submit a "real" proposal. Please
comment early and often (via mailto:jetspeed-user@jakarta.apache.org) so
I
can incorporate your suggestions into the proposal.
DP
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: can we "lock" user navigation inside a portlet?
Posted by "David G. Powers" <je...@pssp.com>.
I submitted this on the dev list last week. I'm in the middle of an
implementation which will keep my attention for the rest of this week
but.... Next week I will draft and submit a "real" proposal. Please
comment early and often (via mailto:jetspeed-user@jakarta.apache.org) so I
can incorporate your suggestions into the proposal.
DP
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I have a working implementation of a WebPageProxyPortlet. The code is
still immature but with the gracious blessings of the the company I did
this for, RyTE Consulting, Inc., I wish to refine and contribute it to
Jetspeed.
I would like to solicit comments from the Jetspeed community to incorporate
into a proposal. If you have an interest or need for a WebPageProxyPortlet
please read on.
I will appreciate any and all comments the bring me toward the goal of a
general solution that works in most (if not all) circumstances. I realize
that I am not the first to embark on this type of portlet and would
especially appreciate feedback from those of you that have either already
done this or are working on it.
Please respond to the list to keep this a truly collaborative effort.
Thanks,
DP
=============================================================
What does the WebPageProxyPortlet do?
=============================================================
Allow the user to view a URL within the confines of a Portlet container
(like the WebPagePortlet) . Navigation within the content of that Portlet
container will remain within the "same" container. I used quotes around
"same" because the entire page is actually reloaded. The content presented
in a particular portlet will vary by Session.
=============================================================
Why does Jetspeed need a WebPageProxyPortlet if IFRAME works so well?
=============================================================
The IFRAME Portlet is very good; however, there are circumstances where it
is not appropriate. Some of these situations are:
- - The users network must have a route to the server providing the content
- - The users browser must support the IFRAME tag (most recent browsers do)
- - The user can "View Source" to see the URLs of the content provider.
- - ???
=============================================================
Requisite Capabilities
=============================================================
- - HTTP GET
- - HTTP Basic Authentication to access "secured"
- - HTTP POST to submit x-www-form-urlencoded data
- - HTTP Cookies - send, receive, and update cookies (a.k.a. Sessions)
- - Javascript/HTML rewriter to eliminate namespace clashes when multiple
WebPageProxyPortlets reside on the same Portal page.
- - preserve (or override) formatting and styles used by content provider
- - Constrain navigation to a maximum depth.
- - ??? Please add to this list!!!!!
- --
David G. Powers
PowerSource
-----BEGIN PGP SIGNATURE-----
Comment: Verify the authenticity of this message with the public key
available at http://pssp.com/dgp_pk.asc
iD8DBQE8o2dijmjAPDT0/nERAoZ+AKDDlhnxDfkteqk3UUdJnwCcTNutwACdFbDn
YNGzVYq72rJJyJbIUAhUsck=
=ZJQB
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>