Maybe it's a dumb question, but in Primefaces's <p:dialog> there's property which called appendTo which described in manual as:
Appends the dialog to the element defined by the given search
expression.
I can't realize what it useful for?
From the PrimeFaces User Guide (currently p. 185):
Do not place dialog inside tables, containers likes divs with relative positioning or with nonvisible
overflow defined, in cases like these functionality might be broken. This is not a limitation
but a result of DOM model. For example dialog inside a layout unit, tabview, accordion are a
couple of examples. Same applies to confirmDialog as well.
You can overcome this by using appendTo="#(body)" and your dialog will be attached as a child of the <body> node.
One of the main dialog option is modal and you could quickly end up with your dialog behind the overlay if you are not using appendTo as shown below:
See also http://forum.primefaces.org/viewtopic.php?f=3&t=16504
Notes:
Before PrimeFaces 5.0, the attribute to set was appendToBody="true". This was changed for 5.0.
If your dialog contains some buttons don't forget to surround them by <h:form> (see Proper Construct for Primefaces Dialog)
The PrimeFaces docs are a bit sparse on this point. appendToBody / appendTo (before 5.0) solves (or tries to solve) a problem where a PrimeFaces component does not get the right z-Index, meaning it does not appear before or behind other elements the way it should. However, this feature is problematic because it can cause other problems like p:commandbutton action doesn't work inside p:dialog
tl;dr:
Do not use appendTo / appendToBody. Instead, Dialogs (along with ConfirmDialog and OverlayPanel) should always be at the root of the component hierarchy, as a direct descendant of <h:body>. This will make them work reliably. In that case using appendTo / appendToBody is unnecessary.
One good way to accomplish this is to have one (or multiple) separate XHTML files for these components ("dialogs.xhtml"), which then gets included in your main XHTML file or template (for example using <ui:include>). Another solution is to use a <ui:define> in combination with a <ui:insert> if you want the dialogs to remain in the XHTML file where they are used.
Read on for details :-)
The problem
Some PrimeFaces components (such as dialogs) should be be displayed on top of other elements.
For example:
If you use <p:dialog ...modal="true">, and make the dialog visible, you get a dialog in the foreground, appearing above the rest of the page, with the rest of the page covered by a transparent layer.
You can see this for example in the PF Showcase for dialogs (button "Modal").
Behind the scenes, i.e. in the page's DOM, two things happen:
a new <div> (the "modal overlay") is created at the end of the <body>. This div gets the CSS styles: z-index: 1000; position: absolute; opacity: .30;. This makes it transparent and covering the whole page, to get the "modal" effect.
the (existing, but invisible) div of the dialog itself is made visible, and gets the styling z-index: 1001; position:fixed;. Note the z-index is one larger than the modal overlay, thus the dialog appears above the overlay.
However, this does not always work. The reason for this is an aspect of CSS called the stacking context. The details are a bit complex, but basically it says that the z-index of a page element is only compared to other elements inside the same parent element. In particular, an element may appear behind another element even though it has a higher z-index, if the element with the high z-index is contained in an element with a lower z-index.
The short (safe) version is: To be certain that z-index works as expected, all concerned elements should be siblings in the DOM.
Now, in this particular situation, the modal overlay must be right at the top of the DOM hierarchy (i.e. inside <body>), otherwise it cannot reliably appear above the rest of the page. However, the div of the dialog itself is somewhere deeper in the DOM (corresponding to the position of the <p:dialog> tag in the source XHTML). Now we have a problem.
In practice, this means that the overlay may appear above the dialog, thus obscuring and blocking it. Similarly, if the dialog is not modal, it may appear behind other elements in the page.
The insidious thing about this problem is that it depends on the structure of the rest of the page (specifically, whether the rest of the page uses CSS that creates a new stacking context). So <p:dialog> may appear to work initially, then suddenly shows incorrectly after a change elsewhere.
How 'appendTo' helps
As explained above, the problem occurs because the HTML rendered for the PrimeFaces component is somewhere deep down in the DOM, while it would need to be a direct child of <body> for the z-index to work correctly.
When appendToBody / appendTo is used, PrimeFaces will include Javascript in the rendered page which simply moves the DOM node of the PrimeFaces component to the end of <body> (using JQuery's appendTo function). That way the component is in the right place in the DOM, and z-index works.
The problem with using 'appendTo'
While the DOM reorganization performed by appendTo solves the problem with CSS and z-index, it introduces another (potential) problem:
The client-side DOM no longer corresponds to the server-side page state maintained by JSF (called the view).
Now, one of the central features of JSF is that it expects the client-side HTML/DOM structure to correspond to the the server-side view - after all, JSF constructed the HTML from that view. If that rule is violated (usually by manipulating the DOM client-side), you get all kinds of weird problems, such as JSF ignoring form fields or values in a submit, or overwriting part of your modifications on AJAX updates.
In this case, the problems caused by moving the DOM node of the PrimeFaces component include:
If the PrimeFaces component is part of a <h:form>, it will not work properly (because it will not be inside the <form> tag client-side because of the moving).
This is actually mentioned in the PrimeFaces docs, along with the workaround: Instead of putting the component into a form, put a form inside the component - then the form will move with the component.
If the area where JSF originally rendered the PrimeFaces component is updated using JSF's AJAX feature, JSF will remove area to update from the DOM, then render the component again, as it does not know it was moved elsewhere.
In old versions of PrimeFaces, this caused the component to appear in the DOM twice (with the same id), which caused problems with later submits. This was fixed for PrimeFaces 4.0 ( Issue 5636: Dialog appendToBody & dynamic doesn't remove the old dom element ), but re-occurred in 5.0 (issue #367).
This shows that this kind of DOM manipulation "behind JSF's back" is rather risky and should be avoided - thus my advice to not use appendTo / appendToBody.
I am not an expert on themes but i would like to know if it is possible to accomplish that:
Once i pull a panel into a facet i am hiding the panel by disabling the output tag and setting a special css class only for the designer client.
Has somebody tried to do that automatically in themes by checking if the panel is in a facet(Maybe ask for the key: property)?
I have tried to change the panel but i dont know how to set a certain style class based on a property of the panel.
To my best knowledge: A theme styles content rendered, not attributes that define if content gets rendered or not.
You have 2 options you could use:
create your own little extension library with controls you want to use everywhere. Add one 'containerPlaceholder' (or whatever you would call it) that doesn't render any own output, but only it's children.
use a snippet you simply paste into your source code.
don't use a panel or div, but add your custom controls to the callbacks. Makes your XPage more readable (that's what I do)
Hope that helps
I have a form which one of it's fields is a code and description, also a button for opening a popup window that contains a list of all of the available codes.
when the user double clickes a row from that table i want to set these values to the code and description. - how can this be done?
Another question, I want to create this popup and table to be initialized dynamically - by that i mean that if i have a few forms in my application, when ever i have a field which has a description i want to be able to open this popup and to see the available list for that field. (every field can be from a diffrent table). is it possible to create something like that? if so, how?
Any help will be appritiated,
Thank's In Advance.
Yes, it is possible. Even more, many component libraries have ready to use popup/dialog components, such as RichFaces with <rich:popupPanel> and PrimeFaces with <p:dialog>.
If you do not want to use a component library for some reason, you would need to create a custom component for this which generates basically an absolutely positioned HTML <div> element with a CSS overlay which get shown/hidden by JS on a particular click/action. The HTML/CSS/JS part should be relatively simple if you are familiar with those languages. The JSF part is somewhat hard if you have never created a custom component before, but it should be possible with a composite component as well, so you could also just create one with pure XHTML. The updating/refreshing can just take place by the usual <f:ajax> means.
One major difference that I have noticed between ExtJS 3.x and 4.x is how the rendering/layout calculation is handled for components that are rendered inside of a containing element that has display:none (NOT an Ext created/monitored containing element). In 3.x, upon showing the containing element, the Ext component it contained would be properly rendered and sized to whatever dimensions i set for it.
However, in 4.x, that same component will not be displayed at all and have a zero height and width when its containing element was shown. After it was visible if I do a call to .setSize() it would then properly be displayed. Problem is, in my application there is just no way to be able to go through all the events that could cause a hidden component to be shown, and add code to make sure its layout is manually forced to be recalculated.
So my question is, is there any way to get back 3.x's behavior in this situation for all components across the board in 4.x?
What you can try to do is set up listeners on your components that delegate to the underlying DOM elements, perhaps that will solve your issue.
However my suggestion is if at all possible is to use the framework to manage the entire page layout using Viewport. You can still suck in the HTML (if you must) and render it inside containers or panels for example. Perfect use case here is Header and Footer which are generated by server side code (jsp, gsp, asp..) and then displayed in the North or South regions of the Viewport using contentEl : 'myDivId' configuration.
I have a widget in my application that I need to display at two places(once in main page body and once through dialog box). Currently its code has been added twice in the page. Now I was thinking, If there was a way I could just include it only once and show the same instance in the dialog box, as in the main page body.
Can you suggest a way for this?
I'm Using:-
JSF 2.0 with Facelets
Primefaces 3.0 M3 Snapshot
JSF 2 has exactly the feature you want: it's called composite components. I bascially allows you to write a bunch of Facelet code into a file and use it just like any other JSF component, pass parameters to it, etc.