Chuck Johnson wrote:
> So, I'm not crazy! ;-)
>
> To me, it makes sense that the "Portlet Name" really represents the "type"
> of the Portlet. A particular Portlet defined with it's parameters has a
> particular set of behaviors that represent that Portlet type.
>
>
>
>>This issue is twofold:
>>- the first issue is Portlet-Action interaction:
>> Currently Jetspeed does not implement at the 'engine' level a portlet
>> parameter recognition that allows to uniformly identify the requested
>> portlet. Each code that wishes to identify a portlet uses a parameter
>> convention on its own (usually 'portlet').
>>
>> This is easy to change (and is on my small tasks list): now
>>that Jetspeed
>> has its own RunData interface, I'll add a new method to the
>>JetspeedRunData
>>
>>
>> public String getPortlet()
>> public void setPortlet(String portletName)
>>
>> and update the sesion validator to detect if any portlet is required by
>> the portlet parameter and put it into the RunData.
>> This will provide uniform requested portlet info for all the
>>Jetspeed code
>> (customizer, portlet, control, etc...) so that we won't need to bother
>> about parameter parsing and will allow the JetspeedLink
>>utility class to
>> automatically create portlet-specific URL to include in forms.
>>
>>
>>
>
> If I place more than one of a given Portlet Type in the same Portlet Set,
> these should be considered different Portlet instances of the same Portlet
> Type. It seems that the "engine" needs the ability to identify a particular
> Portlet instance, perhaps by an InstanceID, in order to provide the ability
> to route actions to a particular Portlet instance.
>
>
yes, but it's related to the second issue
>
>>- the second issue is much trickier:
>>
>> historically the PortletFactory assigned to the Portlet the name of its
>> parent registry entry (and in fact did not keep a 'Parent'
>>reference field),
>> thus whenever you use portlet.getName() you actually retrieve
>>the parent
>> name.
>> This means that if you include 2 portlets with the same parent
>>in a PSML
>> page you get some weird behaviors because the system thinks
>>they have the
>> same name.
>> I've already prepared the work to fix this since I've added a
>>new PSML field
>> in entry for storing the local portlet name but I've not yet
>>modified the
>> PortletFactory and PortalToolkit to take advantage of this. Why ?
>>
>> Because, throughout Jetspeed there are some portlet.getName()
>>calls which some
>> times mean <get local instance portlet name> but some times
>><get portlet
>> parent registry name>, thus activating this feature would
>>require to audit all
>> the portlet.getName() calls and determine whether they belong
>>to the first or
>> second category.
>>
>
> Perhaps if "name" was left alone to represent the "type" of the Portlet, the
> PortletFactory could assign a dynamic, unique ID to each Portlet instance in
> the factory. Portlet specific URLs could include this unique ID. Another
> approach would be to simply allow the specification of the ID in the PSML
> file. In other words, keep it as a separate concept from the Portlet Name
> and avoid the potential conflicts in the code.
>
>
We would still have to go other all the getName() calls to check whether they
should be kept or changed to getId(). Whatever the method (using getName() and
getParent() or getName() and getId()), there's the same amount of work required
to implement it...
>
> Obviously, all bets are off with this configuration, but here is what
> happened in case it's faulty behavior:
>
> I have 2 entries in default.psml for the same HelloVelocity portlet.
>
> When I render the page, I see the 2 instances.
>
> I make a change to the text in Portlet 1 (on the left) and it updates the
> .psml file (the first entry in the psml file)
>
> I make a change to the text using Portlet 2 (on the right) and it updates
> the .psml file (again, the first entry in the psml file)
>
> Now, making a change to Portlet 1 will no longer properly update the psml
> file. In fact, it will always produce the value that was first set in
> Portlet 2 in the psml file.
>
> No other changes to either Portlet will take effect in the psml file.
Which platform/container/etc... ?
>
> This is probably just bizarre behavior based on the fact that the current
> implementation is confused by the 2 Portlets of the same type.
>
It's not that the engine is confused, it's just that the search algorithm
for PSML entries will always use the first entry found in a given name.
--
Raphael Luta - [EMAIL PROTECTED]
Vivendi Universal Networks - Paris
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
