Great Minds Think Alike, Catrina. I asked these same questions about a month ago . There is a project underway (Willie - can you comment on progress / status?). Here are some observations:
In the case of OK/Cancel or Delete/Cancel, you really want these things to happen before you actually do anything. You can simulate this now with an argument to your SM script that takes its values from a class with just two instances - one called OK and one called Cancel. But what you get in your popup (you can do this right now!) is a pull-down menu, with two options: OK and Cancel. Then you can use a Branch to decide what to do based on the answers. My request was to be able to re-arrange that, so that the arg pop-up can have a different form - e.g., two buttons - so that you can have what you describe. Holger made a design for how to integrate this in with other Forms stuff. I think Willie is doing some work on it; perhaps he will comment. The return status on ReturnXXX is really for completion messages - once it is complete, what was the status? So, if you OK a deletion, you might want a popup to tell you so. These completion messages will just have some sort of 'dismiss' button on them. Dean Catrina wrote: > Dean, > > Great, that sounds good. I found our scripts failed on the server if > the text field was not set. Your proposal definitely sounds usable. > Will this popup box have any buttons? Such as an 'Ok', etc.? > > Then, will there be any other way to interact with user to perform > something like a confirm or cancel option? > > For example, if the user runs a delete script, would it be possible to > send a message back to the user stating that we'll be deleting node X > and give them the option to continue with the delete or cancel? > > Thanks, > Catrina > > On Sep 4, 12:02 pm, Dean Allemang <[email protected]> wrote: > >> Catrina wrote: >> >>> The ReturnXXX modules documentation show that these modules are used >>> for exit points from functions. >>> >>> The following snippet is from the description documentation that I >>> copied here for reference. >>> >>> URL: >>> sml:ReturnText >>> >>> Description: >>> Represents the exit point of a function that returns text (mimetype: >>> text). The function can be referenced from the outside (e.g., as a web >>> service) by its URI or local name. >>> >>> Properties: >>> sml:mimeType (xsd:string) - The (optional) mime type of the result >>> stream. >>> sml:text (xsd:string) - The text that shall be returned. >>> >>> When a SPARQLMotion script is executed from Ensemble, where is the >>> sml:text value returned? Will the user be able to see this value from >>> Ensemble? >>> >>> Thanks, >>> Catrina >>> >> I made this feature request just a couple weeks ago. It will be in the >> next release. >> >> It might be interesting to run the proposal past you, to see if you >> agree with it. Here it is: >> >> If there is a return value, then it will show up as an alert (pop-up >> window) in Ensemble. If the return value is all whitespace, (eg., just >> blanks), then no popup will be generated. The reason we do it this way, >> is that in the server, it is required that there be /some/ value for >> this (otherwise the server gets an error), so we use the blank value to >> indicate that there should be no popup. >> >> Do you think that will be usable? >> >> Dean- Hide quoted text - >> >> - Show quoted text - >> > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TopBraid Composer Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/topbraid-composer-users?hl=en -~----------~----~----~----~------~----~------~--~---
