Re: [oslc-core] Delegate UI use cases - Chained dialogs (wizards)

[John Arwe <johnarwe@us.ibm.com>]

In the specific case of OSLC Automation,
we (IMO - 20-20 hindsight speaking) made a mistake in 2.0 when we tightly
coupled AutomationRequest creation with execution.  In other words,
with Automation 2.0, creating an Automation Request carries with it a significant
side effect, namely that you have *already* (via the act of creation) initiated
a single execution of the Automation Plan, leading ultimately to a single
Automation Result.  This is true of dialogs and creation factories.

That coupling makes it harder to implement scheduling scenarios, where the usual pattern is (1) create the template on Sunday then (2) create a scheduling policy, e.g. run it every weekday, or any time someone explicitly requests it.  At point (1) the scheduler wants to create the template *without* triggering execution.

Since I just used the template word, I'll add that (after MUCH discussion and soul-searching during the drafting of OSLC Automation 2.1) that I have come to believe that "template" describes its usage, not "what it is".  From a typing standpoint, if the client *did* want immediate execution nothing in the representation would need to change.  

Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario


<oslc-core@lists.oasis-open.org> wrote on 03/13/2014 09:41:06 AM:

> From: Steve K Speicher/Raleigh/IBM@IBMUS
...
> Trying not to get too far into problem solving mode but was curious why
> this couldn't just be handled within existing dialogs.
> For example, I launch a creation dialog for AutomationRequests...the
> dialog first provides you with a list of plans to select, or it is
> prefilled/selected based on the URL found in the dialog descriptor.
>
> Just curious why this approach doesn't work.  I've seen other
> domains/tools do something similar (not for automation) but when they need
> to first select then create.