[JAVASERVERFACES_SPEC_PUBLIC-333] Portlet Bridge issue: Namespace using Consumer Id when portlet response Created: 05/Mar/08  Updated: 01/Aug/14  Resolved: 24/Jan/14

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Portlet
Affects Version/s: 2.0
Fix Version/s: 2.2

Type: Bug Priority: Major
Reporter: mfreedma Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: 4 days
Time Spent: Not Specified
Original Estimate: 4 days
Environment:

Operating System: All
Platform: All


Issuezilla Id: 333
Status Whiteboard:

EGTop5 effort_hard cat2 frame size_large importance_medium draft


 Description   

Background: As portlets are components of some consuming application page they
must worry about rendering unique consumer ids/names so as not to collide with
other content writers (on the same page). At a minimum portlets are required to
namespace their global client ids using a consumer supplied ID that is unique
for that portlet. In addition, though ultimately not the portlets
responsibility, it is recommended that the portlet additionally namespace all
(form) field names/ids as this can reduce a consumer's burden that can't allow
each portlet to run in an independent form.

Need: Need to make it easy/generic/universal for a UIViewRoot to implement
NamingContainer where when running in a portlet request will encode in the
generated id a name that is in part derived from the unique id passed by the
consumer (by calling ExternalContext.encodeNamespace). So as not to perturb
Faces pages running in a servlet environment this NamingContainer will only
augment the id if running in a portlet request.

Discussion items:

1. Should javax.faces.component.UIViewRoot implement NamingContainer and
support above?
2. Should we make it easy for the bridge to wrap any UIViewRoot to provide
this behavior if not already supported? Note: the primary issue here is making
UIViewRoot wrappable, as it currently isn't. The secondary issue relates to
allowing the bridge to inject itself into the UIViewRoot creation process so it
can wrap – easily done when ViewHandler.createView is done but not when the
component is create directly.
3. In all cases the Bridge needs a way to determine that the Portlet
NamingContainer is implemented by the UIViewRoot. This is needed not only so
the bridge knows whether to wrap or not but also so it can set a header/property
in the response indicating to the consumer that such name spacing has occurred.
Currently the bridge recognizes this if the UIViewRoot class is annotated with
javax.portlet.faces.annotation.PortletNamingContainer. Can we use this?



 Comments   
Comment by rogerk [ 22/Aug/08 ]

Status Whiteboard

Comment by Ed Burns [ 12/Sep/08 ]

effort_hard

Comment by Ed Burns [ 12/Sep/08 ]

change target_milestone to 2.0

Comment by Ed Burns [ 28/Jul/09 ]

I've asked Neil Griffin to advise if he thinks this is fixed or not. I don't think it is.

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 14/Dec/09 ]

Move these to unscheduled because we need to target them correctly. 2.next isn't
specific enough.

Comment by rogerk [ 05/Mar/10 ]

cat2

Comment by Ed Burns [ 22/Mar/10 ]

frame

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by Ed Burns [ 24/Jan/14 ]

This appears to be a duplicate of JAVASERVERFACES-3031.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out

Generated at Wed May 27 15:18:00 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.