oslc-core message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [oslc-core] Delegate UI use cases - Chained dialogs (wizards)
- From: Ian Green1 <ian.green@uk.ibm.com>
- To: Martin P Pain <martinpain@uk.ibm.com>
- Date: Thu, 13 Mar 2014 10:19:54 +0000
Hi Martin
thanks for explaining why the current
dialogues don't meet your requirement. your requirement could be met by
making the existing dialogues more reusable (eg buttons and their labellings
being more configurable or the responsibility of the consumer).
best wishes,
-ian
ian.green@uk.ibm.com (Ian Green1/UK/IBM@IBMGB)
IBM Rational
Martin P Pain/UK/IBM wrote on 10/03/2014 14:16:45:
> From: Martin P Pain/UK/IBM
> To: Ian Green1/UK/IBM@IBMGB, oslc-core@lists.oasis-open.org
> Date: 10/03/2014 14:16
> Subject: Re: [oslc-core] Delegate UI use cases
- Chained dialogs (wizards)
>
> Hi Ian,
>
> That you, thank is a good question.
> I have updated the wiki, but here is a copy of
my answer for the
> mailing list archives:
>
> * I would expect to see a "next" button (and
probably a
> "previous" button - although "previous" wouldn't
undo any creation
> that was done), but in 2.0 the provider sets the button text so this
> would say "ok" or "select" or "create",
and there would be no
> "previous" button.
>
> * 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).
>
> That is all I can think of right now.
>
> (There's also the possibility that the consumer wants to limit the
> selection dialog to single-selection mode, while the provide might
> operate in multi-selection mode by default, but that's a separate
> use case that I don't care enough about to raise here.)
>
> Martin Pain
> Software Developer - Green Hat
> Rational Test Virtualization Server, Rational Test Control Panel
> Open Services for Lifecycle Collaboration - Automation WG joint chair
>
> E-mail: martinpain@uk.ibm.com
> Find me on: [image removed] and within IBM on: [image removed]
>
> [image removed]
>
> IBM United Kingdom Limited
> Registered in England and Wales with number 741598
> Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6
3AU
>
> From: Ian Green1/UK/IBM
> To: Martin P Pain/UK/IBM@IBMGB,
> Cc: Arnaud Le Hors <lehors@us.ibm.com>,
oslc-core@lists.oasis-open.org
> Date: 10/03/2014 13:51
> Subject: Re: [oslc-core] Delegate UI use cases
- Chained dialogs
> (wizards) and returning resource representations
>
> Hi Martin
> re chaining -
>
> I don't understand what it is that can't be done (or can only be
> done with eg some bad UX) using oslc 2.0 delegated uis.
>
> best wishes,
> -ian
>
> ian.green@uk.ibm.com (Ian Green1/UK/IBM@IBMGB)
> IBM Rational
>
> <oslc-core@lists.oasis-open.org> wrote on 05/03/2014 11:01:27:
>
> > From: Martin P Pain/UK/IBM@IBMGB
> > To: Arnaud Le Hors <lehors@us.ibm.com>
> > Cc: oslc-core@lists.oasis-open.org
> > Date: 05/03/2014 11:01
> > 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).
> >
> > * (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
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]