Popup improvment

[nicolasl]

Hello,

I have create an article about How to create a stateful Richfaces popup.

Thanks Jay Balunas for your feedback.

I start the article by highlighting the following issues :

• The popup component is stored in the components tree although it is not displayed. On some use cases, the complete popup sub tree can be stored in the tree.
• Because popups are usually displayed using javascript, there are not sync with the components tree and vice versa.
• So popups are display off  when user reloads the page, that generates inconsistent state.
• A lot of popups on the same page, that significates a lot of rich:modalPanel components, increases file size and decreases readability.
• Popups don't stack easily (A calls B or B calls A mean different zindex for A and B).

I suggest the following improvments :

• A new attribute "displayType" with the values : "client", "server", "ajax". "server" and "ajax" values allow stateful popup.
• rich:modalPanel that embed a rich:modalContent children which stacks.

For example :

<rich:modalPanel displayType="ajax">

<rich:modalContent>

</rich:modalContent>

<rich:modalContent>

       </rich:modalContent>

</rich:modalPanel>

What is your opinion ?

Nicolas

[jbalunas]

Thanks Nicolas fo posting over here.  It is a great way to get improvements, and support the project.

We'll review, and discuss at the team meeting either this week ( main topic is M3 post-mortem ) or next.

-Jay

[nicolasl]

Thanks Jay for your answer.

[ilya_shaikovsky]

Once again - thanks for nice and usefull write-up!

Let me gave you my  thoughts in general and for points you mentioned.

At first before discussing there are good news -  we already planning to add ajax mode in future - see RF-8210. But in general I do not see huge problem currently because of it's absence. Here are some different implementations points:

1) If you need many different panels on the page and having problems which you described (many panels defined breaks performance, some panels for example for table rows could be inconsistent with some server state after refresh) we always suggest almost the same things which you performed:

a) have single panel on the page

aa) if need to have more - iterate from some model set conditionally (e.g. forEach)

b) make all calls to modal panels using ajax controls

c) render the panel from ajax controls with current state

d) and show it then in oncomplete only.

if panel  should not have any content inside preloaded in simplest case (as it could not be called at all for example) in order to make page more lightweight. So something like that could be used:

<rich:popup>

     <c:if ...should we encode include at all? does it has any state to show?>

     <ui:include src="#{popupController.currentModalContentURI}">

          ... set of ui:param's to adjust the included content variables.

     </ui:include>

     </c:if>

</rich:popup>

shared modal panel sample there http://livedemo.exadel.com/richfaces-demo/richfaces/dataTable.jsf?tab=editDataTable

In that case - you getting full control over modal panel content(using attributes bindings to controller) and over set of panels(using iterations by descriptors as you done) before every showing-up so it became "statefull".

2) if you need to define some panel to be shown as a result of some server side action

two different ways could be used:

a) to setup oncomplete on control which action execution should cause modal appearance

b) to use showWhenRendered on shared modal panel. Any control which should cause the panel to appear after action - should set it to true.

So seems your dynamic iteration of modals from some list of descriptor - really the solution we always propose to customers for now. And I'm not sure how to apply that at component level as any child structures like you described with <rich:modalContent> - will not be really useful in dynamic cases (them will still be created dynamically in iteration rather than describing directly on the page using tags.) So as for me structures like

<c:forEach>

<rich:popup>

     <ui:include src="#{popupController.currentModalContentURI}">

          ... set of ui:param's to adjust the included content variables.

     </ui:include>

</rich:popup>

</forEach>

and

<rich:popup>

<c:forEach>

<modalContent>

<ui:include src="#{popupController.currentModalContentURI}">

          ... set of ui:param's to adjust the included content variables.

     </ui:include>

</forEach>

</modalContent>

</rich:popup>

are looking similar for me.

So I still happy to see such cool template for future usages by the guys who need such dynamic constructions. But I vote for the point that such constructions - should still be responsibility of concrete developer for concrete application use-cases and we need just to provide more useful solutions and best practices in our guidelines, demos for complex cases creation.

P.S. forgot about stacking and zindexes... I agree that problem could appear but for now I understood that I personally found such problem report first time http://livedemo.exadel.com/richfaces-demo/richfaces/dataTable.jsf?tab=editDataTable - status panel here came always on top without any indexes definitions. And that seems works fine out -of-the-box because the modal panel re-attached to body and shown will be always upper than previously opened one because it added to body later(even with the same zindex). Probably the problem appears when the modal is not getting repositioned.

https://jira.jboss.org/browse/RF-8210https://jira.jboss.org/browse/RF-8210

[nicolasl]

Thanks Ilya for your answers and for your P.S. tips.

I'm glad to have the same solution for popup .

I totally agree with you, your first solution is the same as the last one. They achieve each the same results. My opinion is that a popup should be part of the UI logic. It's why I suggest modalContent to aggregate modals inside one component.

But what about a <modalContents> ?

<rich:popup>

<modalContents value="#{popupController.popups}"/>

</rich:popup>

[ilya_shaikovsky]

So developer will need to create some kind of special model in anyway as you see(either implement some our predefined model, or use his own objects) So I'm not against for sure but just not sure that it's reasonable to spend additional design time when you could achieve that with the same code and just custom facelets.

So I still vote for providing more information on that at knowledge-base and  concentrate on features which can't be achieved without specific components at all. At least for now

P.S. will link your solution blog entry from our wiki recipes page.

P.P.S. thanks again for your valuable input!

[nicolasl]

I understand.

Thanks Ilya and Jay for this valuable exchange.