Details
Bug
Major
Description
New component Ice:portlet makes impossible to find any component inside with the following method:
public static UIComponent findComponent(String clientId, UIComponent base) in D2DViewHandler
Due to the algorithm of this method that tries to split clientId and find all naming containers preceding the component,
and the face that ice:portlet has the ClientId that match Portlet namespace but not the FacesId, findComponent cannot
find first naming container. I faced this issue in inputFile component, when UploadService tries to find InputFile component.
public static UIComponent findComponent(String clientId, UIComponent base) in D2DViewHandler
Due to the algorithm of this method that tries to split clientId and find all naming containers preceding the component,
and the face that ice:portlet has the ClientId that match Portlet namespace but not the FacesId, findComponent cannot
find first naming container. I faced this issue in inputFile component, when UploadService tries to find InputFile component.
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Okay...fixing 1) above does fix 2) if you fix it correctly 
. I've made the change to the Portlet component and tested ice:inputFile inside of an ice:portlet component running with Liferay and it works. It also works in a vanilla web application if you leave the ice:portlet component in the page.
3) was my misunderstanding of how the findComponent method was intended to work. You of course need to specify the full client ID of the component if you want it to drill down into the various naming containers.
Resolving as fixed.
Show
Deryk Sinotte
added a comment - Okay...fixing 1) above does fix 2) if you fix it correctly . I've made the change to the Portlet component and tested ice:inputFile inside of an ice:portlet component running with Liferay and it works. It also works in a vanilla web application if you leave the ice:portlet component in the page.
3) was my misunderstanding of how the findComponent method was intended to work. You of course need to specify the full client ID of the component if you want it to drill down into the various naming containers.
Resolving as fixed.
This is turning into an interesting one. I've done various tests to gather information and here is what I've concluded so far:
1) I've reviewed <ice:portlet> and it appears that I should be setting the id in a better way as the clientID and the componentID were not in sync. This should be fixed independent of the other issues noted below.
2) The inputFile component does fail when sitting inside an <ice:portlet> component. Fixing problem #1 does not solve this so there is more to it than just the id of the portlet component.
3) If you use the following method of D2DViewHandler.findComponent(String clientId, UIComponent base) in a backing bean, the method will work if the base UIComponent is NOT the ViewRoot As an example actionListener method in a backing bean:
public void find(ActionEvent event)
{ String id = "myComponentID"; //Using this as a base works and returns the component with id "myComponentID"; UIComponent base = event.getComponent(); //Using this as a base does not and returns null UIComponent base = FacesContext.getCurrentInstance().getViewRoot(); UIComponent result = D2DViewHandler.findComponent(id, base); }This kicker is that this behaviour is not constrained to portlets. Running the same test case as a web application exhibits the same incorrect behaviour.
So I think we should probably characterize this particular problem more specifically as inputFile not working in the a portlet component and then perhaps open up one or two more specific cases for the other issues.