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