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 >>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? > 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 >there. > >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 contrario". > > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
