portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Sean Taylor" <da...@bluesunrise.com>
Subject RE: Jetspeed Proposal: iframe portlet control
Date Wed, 06 Mar 2002 23:45:22 GMT

I believe Glenn proposed something like this:

http://host/jetspeed/portal/template/PortalEntry/peid/7

The template seems like extra, but it's a way to specify that you are
requesting an alternative aggregation than the default screen.
I suppose that we could cut that shorter, and use

http://host/jetspeed/portal/PortalEntry/7

The above examples works for the anonymous user (or the currently logged
on user)

You could also access common group or role resources

http://host/jetspeed/portal/group/Apache/template/PortalEntry/peid/9

Or

http://host/jetspeed/portal/group/Apache/PortalEntry/9

Or to get a specific portlet on a specific page in the Apache group

http://host/jetspeed/portal/group/Apache/page/news/PortalEntry/9

I believe we can skip "template/PortalEntry" with a common action
(SessionValidator), that always soft-redirects to the PortalEntry
screen/layout when it sees the PortalEntry parameter. (I've never tried
soft redirects with a layout...but I assume it works)



> -----Original Message-----
> From: Bill Barnhill [mailto:wbarnhil@twcny.rr.com] 
> Sent: Wednesday, March 06, 2002 6:23 PM
> To: Jetspeed Developers List
> Subject: Re: Jetspeed Proposal: iframe portlet control
> 
> 
> What's needed is a way to uniquely identify the portlet markup (a xml
> fragment) and the file that markup resides in.  Rather than 
> generating our own unique ID service, what about using a URI 
> for the file and xpath for the portlet markup. You could 
> actually write the URL extensions to handle a portlet:// 
> scheme so that the content generated by any portlet could be 
> accessed as easily as the content of any http:// URL.  This 
> could even be extended such that remote portlets could be 
> accessed via RMI.
> 
>  What do you think?
> 
> .
> ----- Original Message -----
> From: "David Sean Taylor" <david@bluesunrise.com>
> To: "'Jetspeed Developers List'" <jetspeed-dev@jakarta.apache.org>
> Sent: Wednesday, March 06, 2002 12:59 PM
> Subject: RE: Jetspeed Proposal: iframe portlet control
> 
> 
> > > <include portal="/shared/finance/template" peid="23">.
> >
> > +1 on that. I need to implement this exact feature next week....
> >
> > > I vote for unique within a psml only.
> >
> > +1 - although if we ever put psml in the database, completely 
> > +normalised
> > (right now its stored as blobs), system wide unique ids would be 
> > better I guess when we do that, which is no easy task, we 
> can revisit 
> > the uniqueness issue
> >
> > > I also vote for integer (long) format, where the root 
> element is by 
> > > convention #1 or #0, and all others are whatever they end 
> up being.
> >
> > Are you saying Integer format, are actual integers in the 
> api. Should 
> > I change the api from
> >
> > String getID()
> >
> > To
> >
> > long getID()
> >
> >
> >
> > > -----Original Message-----
> > > From: Glenn Golden [mailto:ggolden@umich.edu]
> > > Sent: Wednesday, March 06, 2002 12:55 PM
> > > To: 'Jetspeed Developers List'
> > > Subject: RE: Jetspeed Proposal: iframe portlet control
> > >
> > >
> > > Seems to me there's one other open question, that of id scope:
> > >
> > > - unique within a psml
> > > - unique on a jetspeed server.
> > >
> > > While I like the idea of being able to include parts in 
> many psml's, 
> > > which unique on server supports, I think in general 
> unique on server 
> > > is more difficult, would make it harder to move psml 
> files around, 
> > > and is more than what we really need.
> > >
> > > We could have in include mechanism to share parts, whoich 
> would use 
> > > the local uid and portal id together, such as <include 
> > > portal="/shared/finance/template" peid="23">.
> > >
> > > * * *
> > >
> > > I vote for unique within a psml only.
> > >
> > > I also vote for integer (long) format, where the root 
> element is by 
> > > convention #1 or #0, and all others are whatever they end 
> up being.
> > >
> > > The psml file reader can, while reading each psml, keep 
> track of the 
> > > largest id to use when a new one is needed, stored in the root 
> > > element or not.
> > >
> > > - Glenn
> > >
> > > -----Original Message-----
> > > From: David Sean Taylor [mailto:david@bluesunrise.com]
> > > Sent: Wednesday, March 06, 2002 1:32 PM
> > > To: 'Jetspeed Developers List'
> > > Subject: RE: Jetspeed Proposal: iframe portlet control
> > >
> > >
> > > To summarize the plan for portlet ids:
> > >
> > > - change all psml files to have a unique id
> > > - if a psml file doesn't have an id, the toolkit service will add 
> > > the id (but the id doesn't get stored until its customized)
> > > - write a conversion utility
> > > - start converting all $links and references everywhere 
> to use the 
> > > portlet id (this will be a lot of changes....)
> > > - customizer
> > > - all controllers and controls that reference
> > > subelements (menus, panes, tabs)
> > > - actions (minimize, maximize,etc)
> > > - try to come-up with a formalised way to set query 
> params and post 
> > > parameters so that they only go to a specific portlet (based on 
> > > portlet-id). One use-case is to put two HelloVelocity portlets on 
> > > the same page and make sure that only one updates.
> > >
> > > Still remaining question. What is the format of the id (vote):
> > >
> > > - hex
> > > - integer
> > > - dot notation as described by Santiago
> > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > > <mailto:jetspeed-dev-> unsubscribe@jakarta.apache.org>
> > > For
> > > additional commands,
> > > e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>
> > >
> > > --
> > > To unsubscribe, e-mail:
> > > <mailto:jetspeed-dev-> unsubscribe@jakarta.apache.org>
> > > For
> > > additional commands,
> > > e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>
> > >
> > >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:jetspeed-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> <mailto:jetspeed-dev-help@jakarta.apache.org>
> >
> >
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:jetspeed-dev-> unsubscribe@jakarta.apache.org>
> For 
> additional commands, 
> e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>
> 
> 



--
To unsubscribe, e-mail:   <mailto:jetspeed-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>


Mime
View raw message