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 17:24:41 GMT

Santiago Gala wrote on Wednesday, March 06, 2002 8:49 AM:

> It should be only unique per psml resource. Thus we can make this 
> conversion utility choose whichever convention we wish. 
> Including a deep 
> traversal with a counter incremented for each entry found, or 
> tree-like 
> namings, like I pointed with "positional id".
> Random thought (take it with a cup of salt):
> A simple id generation algorithm: take the parent id, and 
> append "." + a 
> max-sibling number from parent. Each portletset would store a number 
> that is the number of portlet ever contained inside (when a 
> portlet is 
> removed, the number is *not* decremented, so it is not equal to the 
> sibling count). To guarantee it, when a portletset receives a portlet 
> with null id, it will generate one using this scheme and increment 
> max-siblings. When it receives a portlet with non-null id, it 
> will just 
> increment max-siblings.
> The root portletset would get default.1 always (default 
> stands for the 
> psml name). The siblings would get default.1.[1..n], and so on.
> This has interesting properties:
> - If we save the psml, the ids get saved and later restored.
> - If we don't, the original ids will be (re)generated on reload
> - For unedited psml the ids reflect the page structure
> - For edited psml the ids no longer reflect it, but they are unique
> - if an entry gets deleted and a new one added, it will get a higher 
> number. The deleted entry will retain its id until garbage collected.
> - if a portlets or a portletentry is moved up in the psml 
> hierarchy, it 
> will retain the old id. The same if a portlets or an entry is 
> moved down.

This is a good migration path. 
With your plan, a PSML-conversion utility is not necessary, although we
can still provide one.
The ids are generated 'on-the-fly', and unless someone customizes, the
ids will never be saved back to PSML.
Regardless, I will still modify all distributed PSML files to follow
your id-scheme if everyone agrees on it this id-scheme....

> (I'm not completely sure it guarantees uniqueness, but I would bet)
> On the other side, the length of ids can be a problem, and 
> the fact that 
> we need string manipulations to create them.

Why is this a problem?

> To make this possible, we would have to migrate psml 
> management to the 
> mapping Castor generation, and use our own classes. This 
> would give us 
> more control on the classes, but it is a major work.

Im not sure if this is necessary. See my commits today.
I believe we can add the id in the PortalToolkitService if not already

The only remaining question I have is: Does anyone think its necessary
to have unique ids across the portal server?

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

View raw message