+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:[email protected] Ready for IBM Rational software validation Ready for IBM Rational partner plug-ins "Oslc-Core" <[email protected]> wrote on 06/12/2013 10:56:52 AM: > From: Steve K Speicher/Raleigh/IBM@IBMUS > To: [email protected], > Date: 06/12/2013 11:08 AM > Subject: Re: [oslc-core] Client introspection of creation factory pre-fill > Sent by: "Oslc-Core" <[email protected]> > > 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@IBMUS > > To: [email protected] > > Date: 06/10/2013 03:14 PM > > Subject: [oslc-core] Client introspection of creation factory pre-fill > > Sent by: "Oslc-Core" <[email protected]> > > > > 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 > > [email protected] > > http://open-services.net/mailman/listinfo/oslc-core_open-services.net > > > _______________________________________________ > Oslc-Core mailing list > [email protected] > http://open-services.net/mailman/listinfo/oslc-core_open-services.net >
