I am developing a primefaces 5.2 application and using tomcat. I have a file upload component. For the file upload component to work, I changed the enctype. Later I decided to split the form into two. That's where my problems started. When I have two forms such as this
<h:form id="mainForm">
</h:form>
<h:form id="uploadForm" enctype="multipart/form-data">
</h:form>
does not work. Even the first form requests are not submitted anymore. If I take out the enctype from the second form, everything works.
I have looked at the data going across the network for the second form with and without the form-data. It looks like data is the same using Firebug.
Since it does not give me any error messages, I am kind of stuck. Where should I look? Thanks.
What's interesting is I add the enctype of form-data to the first form and remove from the second, things still work.
The problem is the fact that I have not added the primefaces filter. Now that I have added the filter to web.xml. My problem becomes why does it not work in IE 10 consistently. It works the first time, but does not work on subsequent refreshes.
I have not been able to figure it out yet. It seems if I change compatibility mode, the app starts working but after every page refresh (non-ajax), it goes back to a weird behaviour where first click does not work but second one does...Almost as if some javascript problem...
That's related to an IE problem/single sign on filter. Read more about it another question.
Related
I'm new to JSF and I'd like your suggestions on how to implement what I need the best way possible. Also first post in StackOverflow, so please excuse me if I'm not clear about something.
I've a p:tabView with a dynamic amount of tabs, generated with c:foreach in the following way, with a view scoped backing bean.
<p:tabView id="tabViewId">
<c:forEach items="#{controller.list}" var="aTab">
<p:tab title="#{aTab.label}">
<ui:include src="#{aTab.firstUrl}"/>
</p:tab>
</c:forEach>
</p:tabView>
This works and I'm happy with it. Now the thing is each of my tabs have two possible views, and when a certain event is fired (a p:commandLink is clicked in one of the views) I'd like to change what is shown in the tab to the other view that tab has; in other words, I'd like to change the src view that is loaded inside the tab with ui:include. I've tried to return my desired view path in the method associated to this commandLink in the controller, but as expected it redirects to a new page instead of loading it inside the tab.
I'd like to keep the same controller instance when switching the tab contents (my controller is view scoped), and avoid binding.
I've came with two options.
First would be trying something similar to this (obtained from primefaces tabView different tab content with dynamic tabs), getting the view paths from my "aTab" instead of hardcoding them, and then trying to update the tab or the whole tabView on my commandLink after changing the boolean that switches between the two pages in the controller:
<ui:include
src="#{curSearch.closeable ? '/sections/search/searchInstanceTab.xhtml' : '/sections/search/firstSearchTab.xhtml'}">
</ui:include>
The second one would be including both pages in every tab, but rendering only one using the boolean in the controller. This sounds much worse to me than the first option (it's suggested as an answer in the question I linked before).
Thanks in advance, please feel free to suggest any easier/better way.
::: EDIT :::
Finally did choose to have each tab in a separate xhtml file (being loaded with the c:foreach loop) and in each xhtml/tab all the possible views (also in separate xhtmls) ui:include'd with a rendered clause, hardcoded.
Pretty smooth solution and works great, which possibly would allow to have dynamic contents inside each tab, with another c:foreach loop inside them and a list of pairs in the backing bean which would contain the xhtml names and booleans for rendering (that'd become a bit crazy).
The first option, the view build time conditional one, can lead to problems in some cases. E.g. you won't be able to rely on f:param in the conditional expression.
This sounds much worse to me than the first option
It's not much worse. Creating a bunch of components is not that pricey.
It's not a black and white thing, but my general advice would be to not optimize unless you actually have a performance problem and profiling confirmed that this is the bottleneck (unlikely). Stick to the easiest path, which is using rendered.
For Mojarra you can configure logging like this:
<logger category="javax.enterprise.resource.webcontainer.jsf.timing">
<level name="DEBUG"/>
</logger>
And then you'll see exactly how much time building the view (the Restore View JSF lifecycle phase) takes compared to your logic and rendering (the other phases):
19:47:57,026 DEBUG [timing] (default task-3) [TIMING] - [7ms] :
Execution time for phase (including any PhaseListeners) ->
RESTORE_VIEW 1
...
19:47:57,198 DEBUG [timing] (default task-3)
[TIMING] - [172ms] : Execution time for phase (including any
PhaseListeners) -> RENDER_RESPONSE 6
I have a problem I can't quite get a handle on.
First the context: I am developing a web application using Primefaces 3.5 (yes, unfortunately I am stuck with this old version for now), running on JBoss 7.
There is a form with id "form" encompassing all following xhtml code.
I have a component in my view which is provided by usage of the binding attribute:
<p:dashboard id="dashboard" binding="#{myBackingBean.dashboard}" />
Then sometimes I would like to perform an ajax update on this component, this is done by using the RemoteCommand component of primefaces:
<p:remoteCommand
actionListener="#{myBackingBean.someActionListener()}"
process="#this" id="myRmtCmd" oncomplete="myJsFunction();"
update=":form:dashboard" name="myRemoteCommand" />
The RemoteCommand is triggered by a clicking on a Link:
Some Text
This works pretty well so far. However after deploying this code to production I sometimes get a FacesException:
javax.faces.FacesException: Cannot find component with identifier ":form:dashboard"
referenced from "form:myRmtCmd".
This is where my problem lies because I cannot reliably reproduce this exception. My question is this: What could lead to this exception being thrown? It seems to work 95 % of the time but being the perfectionist I am (and many of you reading this are as well, I'm sure ;) ) I would like this code to work 100 % of the time. What am I missing?
Before answering please consider these constraints:
yes, i have to use the binding attribute for providing the dashboard as I need a great deal of control over what gets added to the component
to avoid using IDs I also tried updating the dashboard by its css class via one of primefaces' advanced selectors: #(.ui-dashboard) - this also does not work!
yes, it would be possible to use a commandbutton/link instead of wiring up the remotecommand component to a simple html link but in this case the link is rendered by a JSF renderer component and I made some bad experiences with dynamically adding buttons etc (due to JSF Spec Issue 790)
Cheers,
p.s.
I also had this weird behavior.
There are probably more than one component bindded to #{myBackingBean.dashboard}, so the first one sets the id and there will be no one called "dashboard".
I have a situation where I have a p:imageSwitch and a ui:repeat to show a few images and some image data.
They are placed in a p:panel like this:
<p:imageSwitch id="mediaSwitcher" effect="fade" widgetVar="switcher" slideshowAuto="false">
<ui:repeat value="#{mediaListBean.items}" var="item">
SHOW IMAGE
SHOW IMAGE DATA
</ui:repeat>
</p:imageSwitch>
The thing is that sometimes, not all the time, the image switcher will show no images even if there should be images in the items list.
When this happens a simple F5 is enough for it to show correctly.
So my thought is that the frontend doesnt wait for the backend to get all the data from the backend and instead it just thinks that it is empty and shows no list. Then the second time the data is already in my bean and can be loaded directly.
Is there a good way to make the frontend wait for the server? I have tried to do an update on the image switcher when the page has loaded but that doesnt help :(
So I figured it out. The problem was actually in the database. I did an insert that has a column with "validFrom" that had second precision. And when I inserted something and tried to view it the same second it would not show up. So all I had to do was add a >= to my sql query instead of just >.
Really silly error by me.
I ran into a very interesting issue. Here is my scenario:
My Goal
Use a SelectManyCheckbox with a nested tooltip.
Use SelectManyCheckbox onHide event to fire an Ajax (ActionListener) call
and update the
SelectManyCheckbox label and nested tooltip text.
My Approach
Use a remoteCommand and tie it to the SelectManyCheckbox onHide event
XHTML
<p:selectCheckboxMenu id="sourceFilter"
onHide="sourceFilterCommand();"
value="#{viewRevenueBean.sourceSelectManyMenu.selectedValues}"
label="#{viewRevenueBean.sourceSelectManyMenu.label}"
filter="true" filterMatchMode="contains"
validator="#{viewRevenueBean.sourceSelectManyMenu.validate}"
widgetVar="srcFilterDropDown">
<f:selectItems id="sourceItems"
value="#{viewRevenueBean.sourceSelectManyMenu.availableItems}"
var="source" itemLabel="#{source.label}" itemValue="#{source.value}" />
<f:convertNumber type="number" />
<p:tooltip id="srcToolTip"
for="sourceFilter"
value="#{viewRevenueBean.sourceSelectManyMenu.tooltipText}"
showEffect="fade"
hideEffect="fade"/>
<p:remoteCommand name="sourceFilterCommand" update="sourceFilter"
actionListener=#{viewRevenueBean.sourceSelectManyMenu.defaultEventHandler}"/>
</p:selectCheckboxMenu>
My Results
Ajax (Action Listener) gets fired and SelectManyCheckbox label and nested tooltip are updated (expected behavior).
In Firebug, I noticed that each onHide event Ajax call is multiplying the preceding number of server side requests by two (unexpected behavior).
e.g
1st onHide event = 1 Request
2nd onHide event = 2 Requests
3rd onHide event = 4 Requests
4th onHide event = 8 Requests
5th onHide event = 16 Requests
etc.....
This is obviously not desired and leads to a big slow down after just
a couple onHide events.
Experiments I tried
I created a p:command button which accomplished the desired Ajax call and correct element updates (without the multiplied request
issue) . I then proceeded to steal it's Ajax JavaScript call via
Firebug and placed it in my own JavaScript function, which I then
used as my onHide callback. Again, I experience the same unwanted
result, the label and tooltip are updated, but the requests start to
multiply.
I tried placing the remoteCommand in different locations
(outside the menu, inside it's own form etc). It doesn't make a
difference. The problem is still encountered.
I tried simplifying the SelectManyCheckbox scenario (remove
tooltip, coverter, tweak various attributes etc) to eliminate other
possibilities. No difference.
I tried a p:ajax instead of p:remoteCommand using onchange.
The Ajax requests work fine but obviously it's not what I am after.
I need to trigger it onHide.
Instead of a SelectCheckboxMenu , i tried using a
SelectManyCheckbox (no label) with onchange and keeping everything
else the same. The remoteCommand works fine, the Ajax call gets
called once and everything is nice and dandy. [/list] [list] * I
tried the PrimeFaces 3.5-SNAPSHOT as well. No difference. Issue is
still manifested.
Haven't found any clues on the forum or the net thus far in regards
to this issue. Does this sound like a bug or programmer clumsiness
:roll: ? Of course any insight and/or suggestions are highly
appreciated.
I have run into similar problems when using p:remoteCommand. I can't say for sure that the root cause is the same in your case, but maybe this can help somewhat.
In my case the problem was caused by multiplied registering of jquery bindings; the p:remoteCommand seem not to use $(somesource).off("some_event").on("some_event", some_function). That means - as far as I have understood - that if you update the component containing the p:remoteCommand, it's action will be registered over and over again, each time it's being updated. That in turn will mean that if you call on the name of the p:remoteCommand, it will fire the same amount of times as it's been registered.
You said you'd tried to move it outside and still got the same problem, so maybe it's not this problem after all. In my case I tested this assumption using a p:commandLink instead and had that call the backing bean. The goal for me was to make sure that any previous registration of a binding was removed, so through registering the binding like mentioned above:
$(somesource).off("some_event").on("some_event", some_function), and let some_function click the link, you can at least check if it solves the problem.
When I click a command button, and then hit the browser back button to the form and click it again, it submits a second time without throwing the proper exception...
Even stranger, the form id itself is DIFFERENT when I come back, which implies it has regenerated a "valid" form id at some point.
Here's the relevant code: Any ideas?
<h:form id="accountActivationForm">
<s:token/>
<a4j:commandButton id="cancelActivateAccountButton"
action="#{controller[cancelAction]}"
image="/images/button-Cancel-gray.gif"
reRender="#{reRenderList}"
oncomplete="#{onCancelComplete}" />
<a4j:commandButton id="activateAccountButton"
action="#{controller[agreeAction]}"
image="/images/button-i-agree-continue.gif"
styleClass="activate-account-button"
reRender="#{reRenderList}"
oncomplete="#{onActivationComplete}"/>
</h:form>
Clarifications:
I inherited this, so I'm trying to change it as little as possible. (It's used in a couple places.)
Each action returns a view, not null. I have confirmed this by stepping through line-by-line.
The reRenderList is empty in my current test-case.
onActivationComplete is also empty.
I'm going to be going template-by-template to see if someone made it with nested forms, because my coworkers have had unrelated problems due to that, so it couldn't hurt to eliminate that as a possible problem.
The s:token is supposed to avoid double/multiple submits by impatiently clicking the submit button multiple times in the same request or by refreshing the non-redirected result in the webbrowser or by resubmitting the cached page in the browser history.
That it works when the client navigates back and forth by browser history just means that the pages with the forms are not cached in client's browser history and are requested as brand new from the server side again. That would indeed return a new token. Check it yourself with a HTTP tracker like the one in Firebug.