Mon, 10/03/2011 - 18:42
You are right, this is the intended behaviour of Presto Basic Apps.
When a subscribing app receives a subscribed event it will check the event payload to see if it carries any named properties which match the name of its own app properties and update any which match, having done that, if any property updates have been made, it will refresh the view data by re-invoking the service operation associated with the app.
(Note - I've included the text and screenshots together in the attached PDF and have also included each screenshot independently)
I have written an app to test certain behavior in Presto and while I am seeing exactly the behavior I was hoping for, I'd like to verify that this is, indeed how Presto is designed to behave (i.e. this won't change in a future release).
I am creating an application in mashboard that is composed of three “micro-apps”. Pub1 is a form that has a single drop down field whose value will be wired to another app. Pub2 is a app created as a mashup – a brain-dead simple mashup that takes in an input parameter and produces an xml document with that single value in it; the view is just an HTML table of this single value. Sub1 is an app that takes in two parameters and simply displays those values in a property view. I've wired up my mashboard so that Sub1 subscribes to the submit event of Pub1, taking the drop down value of the form and setting the first parameter of Sub 1. Sub1 also subscribes to the click event from Pub2, taking the value of parameter 2 from the value produced by Pub2. TwoPubOneSub-1.png shows the app and I've added some annotations to try to explain the wiring.
As you can see in the image, value1 has an initial default value, as does value2.
When I click on the submit button, value 1 is updated as you would expect and value 2 has it's default value (at this point it's not clear whether value 2 was reset to the default value or was left unchanged). See TwoPubOneSub-2.png.
Now comes the real test. I click on the row in Pub 2 (called “DummyToProvideDocWithSingleValue runMashup”) and value 2 in Sub1 (called “SimpleTestingMashupApp”) is updated LEAVING THE PREVIOUS value of “value1” unchanged. See TwoPubOneSub-3.png.
That is, when an event causes wiring to be applied, only the value(s) defined in that wiring are changed – all other parameters are left unchanged. I LIKE this behavior and can see many uses for it. Can someone from Presto please verify that this is the expected and intended behavior?