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

[Martin P Pain <martinpain@uk.ibm.com>]

I presume you have already seen my initial
answer to Ian on this topic [1]

However, that does not directly address
your example. Two more thoughts on that:

1. Does the consumer know that the provider
will include a selection of AutoPlans in the AutoRequest creation dialog?
Does the spec allow the provider to rely on pre-fill to select the
AutoPlan? (This might just be addressed by "best practice" guidance,
or adding a MUST for the providers, depending on how strict we want to
be - I know my original reading of the spec lead me to believe this was
valid, but I haven't been back to check).

2. What if the consumer wants to customise
that flow? In the main consumer (so far) of our product, after the AutoPlan
selection dialog, it allows you to either choose to create an AutoRequest,
or find & select an existing AutoResult. In this case it has to piece
the dialogs together on the consumer side, which means the second point
in my email to Ian comes in to play: "If the provider already provides
AutomationPlan selection on the AutomationRequest creation dialog, either
the consumer app needs to know this and not include the AutomationPlan
selection dialog in the wizard flow, or the AutomationPlan selection on
the creation dialog needs to be suppressed (probably the former)."
(Pre-fill could be used to address this, but it raises the question: does
pre-fill just give a default AutoPlan selection, or does it say that's
the only one the user should be allowed to use on that particular
instance of the dialog? Otherwise the user could face an AutoPlan selection
dialog twice - once provided by the consumer, and a second time as part
of the provider's AutoRequest creation dialog, just with the same value
they had selected the first time pre-selected)


Martin

[1] https://lists.oasis-open.org/archives/oslc-core/201403/msg00006.html



From:      
 Steve K Speicher <sspeiche@us.ibm.com>
To:      
 oslc-core@lists.oasis-open.org,

Date:      
 13/03/2014 13:41
Subject:    
   Re: [oslc-core]
Delegate UI use cases - Chained dialogs (wizards)
Sent by:    
   <oslc-core@lists.oasis-open.org>

---

> From: Martin P Pain <martinpain@uk.ibm.com>
> To: Arnaud Le Hors/Cupertino/IBM@IBMUS
> Cc: oslc-core@lists.oasis-open.org
> Date: 03/05/2014 06:01 AM
> Subject: [oslc-core] Delegate UI use cases - Chained dialogs (wizards)
and 
> returning resource representations
> Sent by: <oslc-core@lists.oasis-open.org>
> 
> I've submitted two delegated UI use cases to the wiki page [1]: 
> 
> * (mp) Chaining of dialogs (creating wizards from dialogs). Scenario:
In 

> OSLC Automation, a user might want to use a selection dialog to select
an 
> AutomationPlan, then be presented with an AutomationRequest creation
dialog 
> for that plan (or AutomationResult selection dialog, if appropriate).
(One 
> solution would be to encourage providers to include selection of those
prior
> resources in their later selection dialogs, but allowing composition
on 
the 
> client side allows more flexibility). 
> 

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.

Thanks,
Steve Speicher
IBM Rational Software
OSLC - Lifecycle integration inspired by the web -> 
http://open-services.net


> * (mp) Should we allow creation dialogs to return an entire resource
> representation through the postMessage result (oslc:result)? e.g.
this 
could
> be used by OSLC Automation 2.1 deferred-execution creation dialog
- 
> currently in draft. (If so, we might also want to consider moving
this 
> result value to be JSON-LD). 
> 
> 
> [1] https://wiki.oasis-open.org/oslc-core/DelegatedUIUseCases
> 
> Martin 
> 
> 
> <oslc-core@lists.oasis-open.org> wrote on 04/03/2014 22:31:16:
> 
> > From: Arnaud Le Hors <lehors@us.ibm.com> 
> > To: oslc-core@lists.oasis-open.org, 
> > Date: 04/03/2014 22:31 
> > Subject: [oslc-core] Agenda for 6 March 2014 
> > Sent by: <oslc-core@lists.oasis-open.org> 
> > 
> > Hi, 
> > 
> > The agenda for Thursday's call is now available: 
> > https://wiki.oasis-open.org/oslc-core/Meetings/Telecon2014.03.06
> > 
> > Please, note the new call-in info. 
> > 
> > Steve Speicher created a new document to capture the use cases
and 
> > requirements for delegated UI. Please, add your own use cases
and 
> > requirements as well as those for the Development and evolution
of 
> > vocabularies which we already started. 
> > 
> > We'll discuss these this week. 
> > 
> > Best regards.
> > --
> > Arnaud  Le Hors - Software Standards Architect - IBM Software
Group
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with
number 
741598. 
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
PO6 
3AU


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU