[oslc-core] Client introspection of creation factory pre-fill

[Samit Mehta]

+1 to the idea of having some "proactive" mechanism to determine if
creation dialog supports pre-fill capability.
+1 to the idea of a resource shape associated with a dialog.

One or both of these will allow consumers of  the creation dialog to
provide a better user experience.

___________________________________________________________________________
Samit Mehta
Lead Architect, ISV Enablement & Ready for IBM Rational software validation
IBM Rational Software - Business Development
(512) 323-9350 - Work
mailto:samit.mehta at us.ibm.com
Ready for IBM Rational software validation
Ready for IBM Rational partner plug-ins


"Oslc-Core" <oslc-core-bounces at open-services.net> wrote on 06/12/2013
10:56:52 AM:

> From: Steve K Speicher/Raleigh/IBM at IBMUS
> To: oslc-core at open-services.net,
> Date: 06/12/2013 11:08 AM
> Subject: Re: [oslc-core] Client introspection of creation factory
pre-fill
> Sent by: "Oslc-Core" <oslc-core-bounces at open-services.net>
>
> For me I would think there would be another way to know if a dialog
> supports pre-fill: using HEAD/OPTIONS on the dialog URL and determining
if
> POST is a supported verb.
> For an extension in the future, I could imaging that if there was a
> resource shape associated with a dialog it would not only describe what
is
> allowed for the pre-fill...it could be used to know that pre-fill itself
> is supported (barring access/auth restrictions)
>
> Thanks,
> Steve Speicher
> IBM Rational Software
> OSLC - Lifecycle integration inspired by the web ->
> http://open-services.net
>
> > From: John Arwe/Poughkeepsie/IBM at IBMUS
> > To: oslc-core at open-services.net
> > Date: 06/10/2013 03:14 PM
> > Subject: [oslc-core] Client introspection of creation factory pre-fill
> > Sent by: "Oslc-Core" <oslc-core-bounces at open-services.net>
> >
> > Core [1] allows delegated creation dialogs to support receipt of an
> input
> > representation for the purpose of pre-filling fields in the dialog.
This
>
> > has recently come up in the context of some Automation WG scenarios
> being
> > discussed as candidates for 3.0.
> >
> > What's "interesting" is that [1] does not obviously allow a client to
> > determine whether or not a creation dialog supports pre-fill.  When
> multiple
> > Automation providers are available, certain implementations consider
> support
> > for pre-fill a hard requirement so they need to be able to detect those

> that
> > do not support pre-fill; ideally, prior to "settling on" a choice of
> > provider and indeed prior to showing a list of candidate providers to a

> human user.
> >
> > Reading between the lines a bit, my guess at the intent is that a
client
> can
> > detect lack of pre-fill support in the spec as it is today by catching
a
>
> > non-201 status code from the attempt to create the pre-filled form.
I.e.
> it
> > can be done reactively, but not proactively.
> >
> > If that is the case, I'm wondering if we could get a straw poll Wed's
> > meeting to see how Core feels about the option of defining a boolean on

> > dialogs (perhaps only used on creation for now, but in principle it's
> > possible to apply the concept to selection as well) allowing an
> > implementation to assert its support for pre-fill.
> >
> >
> > [1] http://open-services.net/bin/view/Main/OslcCoreSpecification?
> > sortcol=table;up=#Resource_Creation_in_a_dd
> > Best Regards, John
> >
> > Voice US 845-435-9470  BluePages
> > Tivoli OSLC Lead - Show me the Scenario
> > _______________________________________________
> > Oslc-Core mailing list
> > Oslc-Core at open-services.net
> > http://open-services.net/mailman/listinfo/oslc-core_open-services.net
>
>
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20130612/e200bd2d/attachment-0003.html>