| Author |
Message |
|
|
I understand the page controller objects (which contain UI bindings, actionListeners, actionMethod etc) should generally be request-scoped, and since a new request bean will be created and used for every request, we don't have to worry about thread-safety with these. This is true for standard request scope.
I'm wondering how this works with ICEfaces extended request scope.
How can I be sure that my controller object is not re-entered by two requests?
Thanks & Regards,
Eashwaran.
|
 |
|
|
I think I've found an answer to this. My clue was to find an existing ICEfaces component that may have a need for this --- like SelectInputText. I checked the component source for SelectInputText and in the isPartialSubmitKeypress it looks for 'requestMap.get("ice.event.type")' to check the type of the event, i.e. whether is its 'onkeypress' or 'onkeydown'.
I guess I could use the same request param to check if its onmouseover or onmouseout in my case.
Thanks,
Eashwaran.
|
 |
|
|
I was wondering if there is a way for a component to differentiate between mouse events. I plan to create a component that does partial submit for onmouseover and onmouseout events. I would like to differentiate within the component renderer asto which event caused the form submission.
Example of this use is: when a user hovers over the component then it unmasks some masked characters, and when the user moves the mouse outside the component it will mask the value again.
Thanking in advance,
Eashwaran.
|
 |
|
|
The following link http://www.liferay.com/web/ngriffin/blog/-/blogs/best-ide-for-icefaces-portlets-built-with-facelets;jsessionid=6857E376CB786B969E12CF5723A2F0CA?_33_redirect=%2Fweb%2Fngriffin%2Fblog%3Fp_p_id%3D33%26p_p_lifecycle%3D0%26p_p_state%3Dnormal%26p_p_mode%3Dview%26_33_struts_action%3D%252Fblogs%252Fview has information on using file association to get this to work.
I opened the Eclipse 'Content Types' dialog and added .xhtml to the JSP type. Then I went into 'File Associations' and made the 'JSP editor' the default for .xhtml.
Note that you will still need the jsp:root here for the assist to work even after doing the above association.
Code:
<jsp:root jsfc="f:view"
xmlns:jsp="http://java.sun.com/JSP/Page">
....
</jsp:root>
Regards,
Eashwaran.
|
 |
|
|
Hello gholmer,
Are you using dynamic menuPopups? That is, with <ice:menuItems>?
My application does this. I'm not sure if this is due to dynamic menuItems, but when I delete a node in the middle of the tree, the menuPopup for the tree nodes from that point onward is messed up. I do see the popup, but when I move over it, it disappears. The only way to fix this is by refreshing the browser.
When I do a view-source in the browser I see the deleted tree node, and its context menus, but I don't see it in the rendered tree. I'm not sure if these are related.
Regards,
Eashwaran.
|
 |
|
|
Have you tried <ice:menuItems> ? I use that and it works. I can have different context menus for different node/leaf types.
Code:
<ice:menuPopup id="menuPopup" displayOnClick="true">
<ice:menuItems value="#{item.userObject.menuModel}"/>
</ice:menuPopup>
|
 |
|
|
Hello gholmer,
Thanks for posting your code. I couldn't get it running because I don't use a NetBeans environment, and the 'ant' build wants some extra packages from NetBeans. Nevertheless, I could study your code to figure what is happening.
I see that you have changed the actionListener calls to directly go to nav user object rather than Page1; i.e. your earlier Page1.jsp post used Page1.mniAddClicked and the new code uses node.userObject.mniAddClicked. I think this is the key to this mystery: having the node's nav user object itself house the menuItem listeners. This way one single right-click to the leaf will invoke the correct menuItem listener and also select the node.
BTW, I realized that we don't need any binding at all to get this working (except one, pls see below). And also one menuPopup definition inside the content facet can be directly referenced any number of times inside the node. So I've the icon facet panelGroup also pointing to the same menuPopup using the 'menuPopup' attribute.
However I ran into one problem:
When 'menuItem' children are directly defined inside the menuPopup in the JSPX page then popup works fine. But when 'ice:menuItems' is used to define the menu with 'menuItem' model being built in the backing bean, then we run into 'Missing Form' error for 'menuItem' component. Reading the post http://www.icefaces.org/JForum/posts/list/1982.page, I figured that setting the parent of each of these menuItem elements to the form UIForm element resolves this issue. Hence the only binding that I have in my page is the binding of the form housing the tree.
BTW, I figured that the 'binding' part in Page1.jsp is a 'purely netbeans behaviour'. It seems to sprinkle the code with bindings for every component on the page. I'm not sure if it is a good idea to bind each and every component to a backing bean; because in repetitive components like the 'tree', 'panelSeries', 'dataTable' etc the binding element could get overwritten and point to the LAST bound component only. FYI.
Thanks for uploading the code. It really helped me see what I needed to do.
Regards,
Eashwaran.
|
 |
|
|
Hello gholmer,
Thanks for posting your code in http://www.icefaces.org/JForum/posts/list/8429.page#36294.
I got menuPopup working for treeNodes, but I didn't require any absolute CSS positioning. The menu shows right in the panel of the leaf link.
FYI.
Regards,
Eashwaran.
|
 |
|
|
A correction to my last post:
I found that INVOKE_APPLICATION phase doesn't always get called, especially from menuPopup and menuBar (in some cases). My guess is that this could be due to some 'immediate' processing of action events of these components (though I don't specify immediate='true' for these!).
While researching similar posts I found that http://www.icefaces.org/JForum/posts/list/5377.page used APPLY_REQUEST_VALUES phase to detect user input action. That seems to be the right phase for detecting if the user initated some interaction with the server, and is probably the best place to clear saved messages, and this works better.
Regards,
Eashwaran.
|
 |
|
|
Hello knob-creek,
I had the same problem with menuPopup. If I've menuItem elements defined inside the menuPopup right in the JSPX page itself then there wasn't any issue. But if I were to use menuItems instead, and get the model using value="#{item.menuModel}" then the dreaded 'Missing Form' error showed up.
Your explanation regarding the 'parent' attachment helped me a bit. I didn't have the menuPopup binding available, so I bound the form element itself. Then I set the parent for each menuItem in my code with setParent call. That seems to get rid of the Missing form error.
Code:
private List initMenuModel() {
HttpServletRequest request = Misc.getRequest();
List model = new ArrayList();
if (nodeType == SERVER) {
// Server
MenuItem editServer = new MenuItem();
editServer.setValue("Edit");
editServer.setParent(navTreeBean.getForm());
addListener(editServer, "EditServer");
..
..
}
I'm not sure if this is the right thing to do though. Please advise.
Regards,
Eashwaran.
|
 |
|
|
Wouldn't this result in 'form' element nesting?
I guess you are suggesting that with enctype set to multi-part/form-data you can nest 'form' elements? Is this right?
Regards,
Eashwaran.
|
 |
|
|
gholmer wrote:
Would you please start a new thread? The original question on this thread is how to fix the positioning of a popup menu relative to a tree node.
I thought these were kinda related issues because the panelGroup that displays the menuPopup needs to be a separate component for EACH LEAF.
I'm not sure how you are doing this magic though :-).
As per your suggestion I've moved last couple of messages into http://www.icefaces.org/JForum/posts/list/0/8429.page. It would be nice if you can post the code for action listeners (nodeClicked and mniAddClicked) to show how mniAddClicked references the 'specific' item object, that will help me understand this better.
Regards,
Eashwaran.
|
 |
|
|
I've run into a stumbling block here!
Trying to using 'binding' attribute to obtain the menuPopup compnent from inside the treeNode does not work when the 'item' variable is used to reference the binding.
Code:
<ice:form id="nt">
<ice:panelGroup styleClass="netxMainNav">
<ice:tree id="tree"
value="#{navTreeBean.model}"
var="item"
hideRootNode="true"
hideNavigation="false"
imageDir="./xmlhttp/css/xp/css-images/">
<ice:treeNode>
<f:facet name="icon">
<ice:panelGroup style="display: inline;">
<ice:commandButton image="#{item.userObject.icon}"
rendered="#{item.userObject.serverNode}"
actionListener="#{item.userObject.nodeClicked}"/>
</ice:panelGroup>
</f:facet>
<ice:menuPopup displayOnClick="true" binding="#{item.userObject.menuPopup}">
<ice:menuItems values="#{item.userObject.menuModel}"/>
</ice:menuPopup>
<f:facet name="content">
<ice:panelGroup style="display: inline;">
<ice:panelGroup style="display: inline;" menuPopup="#{item.userObject.menuPopup.id}">
<ice:commandLink styleClass="navTreeLink"
value="#{item.userObject.text}" style="#{item.userObject.style}"
actionListener="#{item.userObject.nodeClicked}"/>
<ice:graphicImage url="#{item.userObject.connStatusImage}"
rendered="#{item.userObject.serverNode}"/>
</ice:panelGroup>
</ice:panelGroup>
</f:facet>
</ice:treeNode>
</ice:tree>
</ice:panelGroup>
</ice:form>
The above does not work!!!
The above causes target unreachable error, item is null!!
Code:
Caused by: javax.faces.el.PropertyNotFoundException: /main/navigation.jspx @28,82 binding="#{item.userObject.menuPopup}": Target Unreachable, identifier 'item' resolved to null
Regards,
Eashwaran.
|
 |
|
|
I think I may have figured an answer to my question regarding 'How can menu popup listener know about specific nav user object of the clicked node?'. Answer: make the nav user object itself to contain the popup menu binding and the panelGroup binding.
Yes, this will create a menuPopup component for EACH LEAF, but I think that is what it would take to do the 'node selection' and 'menu popup' in one-click (i.e. only right click). Also, I reckon this will help in the positioning of the menuPopup.
I've not yet tried this idea, but am planning to do this today. Will post an update regarding this later during the day.
Regards,
Eashwaran.
|
 |
|
|
Check out http://www.icefaces.org/JForum/posts/list/6812.page. This shows it for check box, but should apply for radios too.
Eashwaran.
|
 |
|
|