David Sean Taylor wrote: >Good proposal. > >I think that this overall feature should be supported throughout the >project, and not only with iframes, and with different media types. > >I like the idea of randomly accessing content, whether it's a portlet, a >portlet with its control, or a collection of portlets. In order for this >to work, we need to have unique ids support. Paul and I have been >discussing this for a while now, and he just committed the start of the >portlet id implementation. Its not complete. We still need to work out: > >- a conversion utility to take existing psml files and ensure that a >unique id is added to each and every 'entry' and 'portlets' element. > 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. (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. 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. > >- modify psml.xsd to mandate an id entry for 'portlets' and 'entry' > change: > <attribute name="id" type="string" minOccurs="1"/> > to: > <attribute name="id" type="string" use="required"/> > Possible alternative (more work, as said above): to switch to a psml-mapping.xml Castor marshalling. In this way we would have more control on attribute handling. > >- a unique value generator (Turbine's has been deprecated) > This would be needed when adding new portlets to psml files. > >- deprecate all pane and portlet references, and replace them with a new >portlet/portletset reference mechanism, integrating with tools (jlink) > >Think about making the portlet id required. It means that old psml files >will be incompatible until converted. > >I agree with Santiago, that we should all agree on a common naming >convention. I like 'Content' better than 'Clear'...what about >'PortletElement'? > >The default content, an entire portal page is addressed by >/jetspeed/portal. >It gets the default layout/template. > >What about "/template/PortalElement/peid/42" where > peid - represents portal element id (see above) >PEID can represent either a portlet entry or portlet set. > Looks better for me than either the original proposal or my amendment :) > >Then JetspeedTool would have a 'getPortalElement' method etc. >Anyway, that's my vote on the naming. > >My vote is +1 on this, as long as we make sure it supports other media >types and constructs as well as IFrames. > >Im now going to look into continuing what Paul started on using unique >ids across the system. > > >>4.1 Decisions >> >>Do we want this in Jetspeed? >> > >+1 > >> >>Are there improvements to these details that better fit the >>jetspeed code and intentions? >> > >See above. > >> >>Do we want a single portlet control, or updates to them all? >> > >I like the optional "iframe" attribute on all controls. >This gives the most flexibility. > >> >>How are we going to identify a portlet within a portal page? >> > >See above. > >>What code will support forming this id and finding? >> > >We're still working that out. > >> >>How to change the customizers to support portlet control choice? >> > >Do you mean the 'Iframe' option? Not sure if I understand this question. > There were alternatives in Glenn's proposal. If we use a specialized control, then the customizer should allow for selection of controls (good in any case). If we use de Iframe option, then it should be catered for by the current customizer, as both "iframe" and "height" would be standard attributes. > >> >>Should we surface more iframe control to the user, such as height? >> > >Yes. Perhaps a more detailed design of Iframe customization would help. > I think parameters of a portlet are editable by default using the current customizer. So, if the parameter is there, a basic string edit capability will be there. > >> >>Should we make the iframe parameters different (bigger >>height) when the portlet is maximized? >> > >Perhaps a more detailed design of Iframe customization would help. > >David > > > >-- >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]>
