portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barnhill" <wbarn...@twcny.rr.com>
Subject Re: Jetspeed Proposal: iframe portlet control
Date Thu, 07 Mar 2002 02:22:40 GMT
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>


Mime
View raw message