portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <sg...@hisitech.com>
Subject Re: Jetspeed Proposal: iframe portlet control
Date Wed, 06 Mar 2002 17:42:33 GMT
David Sean Taylor wrote:

>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 
>>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?
Performance, as ids could get long (depending on depth of nesting).

String.equals() is way slower than int ==, unless Strings are 
intern()ed, and this has problems also.

Also, for DB storage we would need to assume a maximal length.

We should study the issues of this on the clustering of portal VMs. I 
think it will require session affinity or session replication to work. 
But we need it anyhow.

>>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?
A psml name + a unique psml id is a resource unique id. It should be 
unique WRT a given session (separate sessions from the same user will 
have the same ids, including anonymous sessions as one user).
A session id + the above is a portal server unique id.

As long as everything is not stored or referenced beyond the session 
scope, we should be safe.

This is mostly intuition. You (should) know I'm not a very formal 
thinker, rather highly intuitive. I would welcome any issue or proof "a 

>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>

View raw message