Is there a condition-based iteration with SWP (beyond ui:foreach)?

[Jack Hodges]

I would like to perform a while or do-while iteration with SWP. That is, condition based rather than item based as in ui:foreach. I see nothing in the manual about it so I'll look in the libraries but thought I ask in parallel. I do not know if a ui:if and a ui:foreach can produce the same results. Any pointers to examples or documentation appreciated.

Jack

[Ralph TQ [Gmail]]

Jack,

There is a tops:for magic property that you can use in a ui:forEach to provide iteration. tops:for is documented in the TBC help resources for “TopBraid SPARQL property functions”:

tops:for

This property can be used to implement loops over a range of integer values.

 

• Syntax: ?index tops:for ( [startIndex] [endIndex] )
• Description: The function iterates over all xsd:integer values >= startIndex and <= endIndex and assigns all those values to the variable on the left side
• Example: In the following query, the variable index will be bound to the xsd:integer values 2, 3, and 4.
  

  ?index tops:for (2 4)

Ralph

On Aug 6, 2019, at 12:17 PM, Jack Hodges <jhodg...@gmail.com> wrote:

I would like to perform a while or do-while iteration with SWP. That is, condition based rather than item based as in ui:foreach. I see nothing in the manual about it so I'll look in the libraries but thought I ask in parallel. I do not know if a ui:if and a ui:foreach can produce the same results. Any pointers to examples or documentation appreciated.

Jack

--
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/849cd590-7cfa-4068-b93f-9516ab7c2fcf%40googlegroups.com.

[Holger Knublauch]

All queries in SWP, such as the result set of a ui:forEach, are computed at once, i.e. there is no way to dynamically change the loop based on things happening inside of the loop. There is no ui:while either - I guess we just never had use cases for that. An alternative to while is to do a recursive loop similar to functional programming, e.g. define ui:MyElement which has a prototype with a ui:if... and then calling <ui:MyElement /> again until the if is false. This approach however can run into stack overflows, i.e. only works for certain traversal depths.

Holger

On 7/08/2019 02:17, Jack Hodges wrote:

I would like to perform a while or do-while iteration with SWP. That is, condition based rather than item based as in ui:foreach. I see nothing in the manual about it so I'll look in the libraries but thought I ask in parallel. I do not know if a ui:if and a ui:foreach can produce the same results. Any pointers to examples or documentation appreciated.

Jack

[Michael Phelan]

>An alternative to while is to do a recursive loop similar to functional programming

I have successfully defined a ui:Operations subclass that recurses based on count and maximum count Arguments defined in SPIN constraints. The ui:Operations subclass is called from the ui:prototype of a ui:Services subclass.

Are there examples of:

1. returning a value from a ui:Operations subclass

2. assigning a variable the value of the result of a ui:Operations subclass

3. updating an Argument in Pass By Reference style

On Tuesday, August 6, 2019 at 7:56:30 PM UTC-4, Holger Knublauch wrote:

All queries in SWP, such as the result set of a ui:forEach, are computed at once, i.e. there is no way to dynamically change the loop based on things happening inside of the loop. There is no ui:while either - I guess we just never had use cases for that. An alternative to while is to do a recursive loop similar to functional programming, e.g. define ui:MyElement which has a prototype with a ui:if... and then calling <ui:MyElement /> again until the if is false. This approach however can run into stack overflows, i.e. only works for certain traversal depths.

Holger

On 7/08/2019 02:17, Jack Hodges wrote:

I would like to perform a while or do-while iteration with SWP. That is, condition based rather than item based as in ui:foreach. I see nothing in the manual about it so I'll look in the libraries but thought I ask in parallel. I do not know if a ui:if and a ui:foreach can produce the same results. Any pointers to examples or documentation appreciated.

Jack

--
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to topbrai...@googlegroups.com.

[Richard Cyganiak]

On 29 Nov 2019, at 22:13, Michael Phelan <mph...@gmail.com> wrote:

Are there examples of:

1. returning a value from a ui:Operations subclass

ui:Operations subclasses cannot return a value other than the DOM nodes generated by its prototype.

2. assigning a variable the value of the result of a ui:Operations subclass

See above.

3. updating an Argument in Pass By Reference style

Arguments in SWP are passed by value.

If you need to pass information between SWP elements in a way that doesn't match the usual control flow, you have a number of options:

1. Use global variables: https://uispin.org/ui.html#setGlobalVar

2. Store information in a temporary graph: https://uispin.org/ui.html#tempGraph

3. Make the SWP element a ui:Function, which is like a spin:Function with the body being an SWP script (ui:prototype instead of spin:body) and the result of the function returned via ui:return. See the comment on ui:Function in TBC for details.

4. Make the SWP element a normal element (not a ui:Operation), return the result as a text DOM node, and in the calling code assign the DOM result to a variable via ui:bind/ui:stringify: https://uispin.org/ui.html#bind

If all you need to pass around is a scalar value or string, then I would recommend option 1. If a more complex temporary data structure is needed, I would recommend option 2. Option 3 can work fine, but I avoid ui:Function when possible, because it mixes SWP elements and SPARQL functions in such a weird way (it's an SWP element, but you can't call it like an SWP element, but need to call it like a SPARQL function). Option 4 is too obscure for my taste. 

Hope that helps,

Richard