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 16:48:54 GMT
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: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>


Mime
View raw message