I'm using the jeditable plugin for Datatables. I have a page set up with a table that passes the submitted add form to a .java class to process, and has the fnShowError parameter set to display a failure message.
The operations the add handler does take a while, and sometimes the add will succeed but I will get the fnSHowError message anyways, likely because of a timeout. Is there a way to specify a timeout length for the add function?
Related
I have created a scenario where I iterate through multiple modules with an array of data. This works fine.
After this completes, I want to run a module once before the scenario completes.
How do I add a module that won't get called in the loop?
There are few ways to achieve this,
Use Router to Create a new Route that will be triggered after the
first route is complete
Trigger new Scenario via Webhooks after you are done with the
scenario
If you are working with array, then using Array Aggregator or other
Aggregators will allow you to first complete the iteration and then
trigger the module you want to use
I am not sure exactly what you want to do after the iteration is complete, but setting the scenarios as displayed in the screenshot below should help you get started on this,
Using Router
For this you can create a router, the upper hand of the router is always executed first, so the iterator and other operations will be done there. After which, the next hand/route will be executed which will be the module you want to trigger at last.
However, If you want to pass some values from the first hand/route to the last one then you will need to set a variable and fetch it on the second route. See details here : https://www.integromat.com/en/help/converger
Using Aggregator Module
You can either use Array, Text or Numeric Aggregator to aggregate all the iteration operations and then trigger the module that you want to use at last.
As far as my knowledge goes, there is no Integromat default modules that can be configured before the scenario ends. We can leverage the Integromat API in future that is currently in development to do so.
I found a filter to be the most easy way of doing this. Essentially chekcing if this bundle position is equal to the total number of bundles!
If you're interested in doing something on the last iteration only, you can use a filter to check if the current bundle is equal to the total number of bundles
last bundle filter
They won't let me paste pics sigh
I have an application that uses a combination of ContentService.Saved & ContentService.Saving to extend Umbraco to manage content.
I have two websites in one Umbraco installation I am using those methods to keep content up to date in different parts of the tree.
So far I have got everything working the way I wanted to.
Now I want to add a feature that: depending on which Umbraco User is logged in, will either publish the content or simply send it for approval.
So I have changed some lines of code from:
cs.SaveAndPublishWithStatus(savedNode, 0, false)
To this:
cs.SendToPublication(savedNode);
Now the problem that I am finding is that unlike the SaveAndPublishWithStatus() method, the cs.SendToPublication(); doesn't have the option of passing false so that a save event is not raised. So I get into an infinite loop.
When I attach the debugger and manually stop the infinite loop the first time it calls cs.SendToPublication(savedNode); I get exactly the behavior I want.
Any ideas about how I can get round this problem? Is there a different method that I should be using?
You are correct in saying that it currently isn't possible to set raiseEvents to false when sending an item to publication - that's a problem.
I've added that overload in v. 7.6 (http://issues.umbraco.org/issue/U4-9490).
However considering that you need this now, an interim solution could be that you make sure your code is only run once when triggered by the .Saved / .Saving events.
One way to do this would be to check the last saved date (UpdateDate) in your code. If the content was saved within the last second of the current save operation, you know that this is a save event triggered by the save happening in SendToPublication action. Then you also know that the item has already been sent to publication and that this doesn't need to be done again - thereby preventing the endless loop from happening.
I have a filter that modifies the request headers, and a filter that logs the request. Because the logging filter is applied liberally, I have a testNG listener which appends this implicitly (overriding onStart). The header filter needs to be explicitly called, so that any unattended side effects of this can be carefully handled.
I want the logging filter to log the real request - but after the request is logged, it gets modified (because onStart adds the logging filter, followed by the test which adds the header modifier filter).
Is there a way to force the logging filter to be the last filter run, without having to have each test that uses it to retrieve the filter list and append this at the beginning?
Currently there's no such option in REST Assured.
Looks like 'ordered' filters have been added as of version 3.0.2
https://github.com/rest-assured/rest-assured/wiki/Usage#ordered-filters
during the migration from RichFaces 3 to 4, we are facing an unexpected behaviour of rich:tree element. We registered a selectionChangeListener which is supposed to include a facelet with h:inputText fields next to the tree depending on the new selection. The facelet is supposed to show detailed information on the selected node.
This works correctly when the first selection is made. However, when we select another node of the same type, the same facelet is included (which is correct in this case as the node type is the same), but the values of the previous node are displayed in the facelet, even though the object holding the value of the component is instantiated correctly.
Inspecting the log files revealed that the TreeSelectionChangeEvent is processed during the Apply Request Phase (2). During that phase, the object holding the textfield's value is updated correctly, but is changed back to the old value during Update Model Phase (4).
General question on this issue is: Is it correct that this event is processed during Apply Request Phase even though the immediate attribute of the tree is set to false? (I would have expected the event to be processed during Invoke Application Phase (5)) And, if this is correct behaviour, how could we circumvent the problem that the old value is restored?
Thanks for your suggestions in advance.
as much as I understood, during the Apply Request Phase, the listener-event is executed and you update fields which are also represented as h:inputFields in the currently rendered view?
During Update Model Phase, the data out of the original h:inputText overwrites the already made changes?
Without being able to test it out locally: With switchType="ajax" the rich:tree-component gives two attributes
execute and
render.
You want the facelet-part to re-render, but not the input values to be executed (because that's what the listener already did).
Assuming you use rich:tree in ajax switch-type, have you tried to set execute="#this" and render="<theFaceletComponent>"?
If the component id wasn't found, use :#{rich:clientId('<theFaceletComponent>')} for an absolute identifier.
Hope, that helps ...
I was checking out the code for this template from the OmniFaces Showcase app, when I encountered the following condition used in a p:selectOneMenu:
disabled="#{facesContext.postback and not facesContext.renderResponse}"
From using the app, it seemed that the selectOneMenu is never disabled, so what does this code really do?
I know that facesContext.postback is true whenever the page is resultant from POST requests generated by JSF components (commandButton/commandLink, etc), but what would be the usual expected state of facesContext.renderResponse when evaluated in the View?
UPDATE: oops, just now I saw the comment: They're disabled in other phases than render response, because they otherwise complain that the model value cannot be set even though there's no form.
So, I'm guessing the condition is evaluated several times during Faces lifecycle, and the component is disabled until the last state (renderResponse) is reached, when facesContext.renderResponse evaluates to true, the whole expression evaluates to false and the component is then enabled. Is that about right?
Those <p:selectOneMenu> components are actually abused to have a nice <div><ul><li> dropdown menu with a minimum of code ;) Their values represent the current menu group and page which are by design read-only (they have no setter method). The navigation takes place by JavaScript window.location which is handled during change event. They are not part of any form and do not participate in any form submit.
The disabled attribute is theoretically not mandatory, but when a non-ajax JSF form elsewhere in the very same page is submitted synchronously, then PrimeFaces SelectOneMenuRenderer will still try to decode() it in its entirety even though it is not enclosed in any form at all. It would ultimately cause the following exception when the model value is to be updated because there's no setter for that value:
javax.el.PropertyNotWritableException: /WEB-INF/templates/showcase.xhtml #28,80 value="#{parent.children[0].viewId}": The class 'org.omnifaces.showcase.Page' does not have a writable property 'viewId'.
at com.sun.faces.facelets.el.TagValueExpression.setValue(TagValueExpression.java:136)
at javax.faces.component.UIInput.updateModel(UIInput.java:818)
at javax.faces.component.UIInput.processUpdates(UIInput.java:735)
at javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:1242)
at org.primefaces.component.panel.Panel.processUpdates(Panel.java:304)
at javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:1242)
at javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:1242)
at javax.faces.component.UIViewRoot.processUpdates(UIViewRoot.java:1231)
at com.sun.faces.lifecycle.UpdateModelValuesPhase.execute(UpdateModelValuesPhase.java:78)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593)
When the disabled attribute evaluates true during postback, then the SelectOneMenuRenderer will skip the decode() during apply request values phase and thus also skip the update of model value. However, if it evaluates true as well during render response phase, then it becomes unselectable (and thus unusable). So, it should not evaluate true during render response phase. The expression
disabled="#{facesContext.postback and not facesContext.renderResponse}"
achieves exactly that. All with all, it's basically kind of a workaround for the odd behavior of SelectOneMenuRenderer (for which I've not really investigated the underlying cause yet).
To test it yourself, pull the project, remove the disabled attribute and invoke a synchronous submit in for example the <o:onloadScript> showcase page.
This evaluates to the getter state for reading whether renderResponse() has been invoked. This method is used to instruct the JSF lifecycle to skip subsequent phases and go straight to emitting the response (e.g. in the case of a validation failure.)