Search results for "Return"

Now that our Action contains a script, we want it to return its result. For this to happen we have to make sure the flow execution does not stop at the Action element. Drag a connection from the “Next” socket of the Action element to the “Prev” socket of the Return element to create an execution flow, indicated by the green color of the connection. Our function is now capable of returning something after the Action has been dealt with, but at this point in time, it will return an empty result, because we have not yet connected data to the Return element. In the same way the first connection was handled, create a connection between the elements “DataTarget” and “DataSource” sockets to create a data flow. When a node is being evaluated by the engine, it will try to consider connected data flows and make them available within its scripting context in the example of an Action or Return element.

The Return element allows a flow to return results. By default the element will return the data provided by the data input relationship. Supplying a custom script allows the transformation or post-processing of the data before returning it.

When a flow is called, execution will begin at it’s starting element. In case of no entry point being set or no elements being contained, the flow will simply return a null result. Otherwise the Flow Engine will evaluate the starting element and then proceed with the evaluation of the element connected to the initial element as next element. This continues until there is no more next element available, an error has been thrown or the evaluated element is a Return element, in which case the result of the element’s evaluation will be returned. Although this sums up the general execution flow of a Flow, there are notable exceptions to this in the form of specialized elements. For example a Decision element will branch into two execution paths and choose one based on the connected conditional elements. Likewise, a Loop element will enter a different execution path for each element and finally proceeds with the original next element.

A schema method can return any value (including null, which results in an empty response object). Non-empty return values will be transformed to JSON objects and returned in the response. If the method runs without errors, the response status code is 200 OK and the response body contains the JSON result of the method.

Step 1: Create the basic login page/form as per usual. A regular HTML <form> with custom submission handling to log in.

If the user is not configured for two-factor authentication, they are logged in.

If the status is 202 is returned, two-factor authentication is required. The returned headers from the login POST contain the required data to use on the next page (and are passed as request parameters in the example code):

The return value is determined by using return in the main scope of the script.

Passive indexing is the term for reading a dynamic value from a property (e.g. Function Property or Boolean Property) at application level, and writing it into the database at the end of each transaction, so the value is visible to Cypher. This is important for BooleanProperty, because its getProperty() method returns false instead of null even if there is no actual value in the database. Hence a Cypher query for this property with the value false would not return any results. Structr resolves this by reading all passively indexed properties of an entity, and writing them into the database at the end of a transaction.

The Filter element allows easy filtering of collections. On evaluation each element of the connected collection will be checked against the connected logic elements and only if those return true, the specific element is allowed to remain in the collection. Once evaluated the Filter element will return the filtered collection on it’s data output socket.

The scripting context must return a single object or a collection of objects. If a single primitive or a collection of primitives (or a mixed collection) is returned, the result must be wrapped in an object by using the to_graph_object() builtin function. The primitives will be made available under the key value.

The cypher repeater uses the return value of a given cypher query as its data source. Depending on the return value the object accessible via the dataKey (proj in this case) may be wrapped in an object.

The find() function is another Structr built-in function, just like capitalize() we used in the page’s title and heading above. The find() function takes as argument the name of a type and returns a collection of all instances of this type.

The result returned by the find() function is not sorted, so in order to get a sorted project list, we need to add the system function sort() which requires two parameters: A a collection and the name of a property to sort by. Modify the function query of the repeater element as follows:

For the sake of this demonstration, a simple flow with an Action and a Return element is created. Both of these can be found under the Action Nodes category of the context menu. The first viable start element added to the flow will automatically be marked as such. A start node or flow entry point is indicated by the green coloring of the node header. The start node can be changed by bringing up the context menu on an element, if it is viable a menu item called “Set as start node” will display.

The Condition element evaluates given script to create a logic data result. The script must return a boolean value.

The Aggregate element is used to aggregate data within loops in the Flow Engine. It works similar like reduce functions in other languages. In it’s scripting context the keywords data and currentData become available. Data represents the initial value for the aggregation and currentData contains the dataset of the current loop iteration. The script must then process and return the aggregation result and in the next iteration data will contain the result of the previous aggregation.

For HTML elements, Structr offers two additional ways to control the visibility during page rendering: showConditions and hideConditions. Both can contain a StructrScript or Javascript expression and - if they are filled - are evaluated before rendering. Depending on the return value of the script, the current element and its substructure will be displayed or hidden. Both fields are auto-script environments, i.e. the text in those fields is interpreted as a script without the need for the template expression markers ${...}.