Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 30549

Summary:	[resources] ValidateEdit spec - should say "must prompt" if there is a UI context
Product:	[Eclipse Project] Platform	Reporter:	Kevin McGuire <Kevin_McGuire>
Component:	Resources	Assignee:	John Arthorne <john.arthorne>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	jed.anderson, jeem
Version:	2.1
Target Milestone:	2.1 RC1
Hardware:	PC
OS:	All
Whiteboard:

Description Kevin McGuire

2003-01-29 16:41:57 EST

The validateEdit spec is unclear whether given a UI context the receiver 
*must* prompt to inform the user of the reason why the file can't be 
modified.  It reads,

"By passing a UI context, the caller indicates that the VCM component may 
contact the user..."

The word "may" suggests its not required.  However, if the caller provides a 
UI context, they reasonably assume that they don't need to prompt.  This 
situation can fail in one of two ways:

1. The user tries an operation and it fails silently.  This happens when a UI 
context is given, the caller doesn't prompt, but the provider doesn't either.

2. The user is told twice the file is read-only.  This happens when a UI 
context is given, but the provider is defensive and prompts, but the provider 
prompts too.

The word "may" should be changed to "must".  Currently the default provider 
never prompts, which according the spec seems ok, but results in problem #1 in 
practice.

Comment 1 DJ Houghton

2003-02-19 13:09:09 EST

Looks like this change has been released.
John, please verify and close.

Comment 2 John Arthorne

2003-02-19 15:18:13 EST

I don't know if this has changed recently, but the current doc seems to be clear:

 * If a shell is passed in as the context, the VCM component
 * may bring up a dialogs to query the user or report difficulties; the shell
should be used to
 * parent any such dialogs; the caller may safely assume that the reasons for
failure will have
 * been made clear to the user.

I think the last part clarifies your question: "the caller may safely assume
that the reasons for failure will have been made clear to the user."  Saying the
hook *must* bring up a dialog is too restrictive.. it might be a system that
eagerly checks out without user involvement, or the user might have set a
preference to never prompt on checkout.  If a context is passed, all interaction
with the user is left to the hook implementor.  If no context is passed, it is
entirely the caller's responsibility.  Does this mean the default hook is not
currently following the spec?

Comment 3 Kevin McGuire

2003-02-19 16:25:17 EST

The new wording is better.

>>Does this mean the default hook is not currently following the spec?

Correct.  There is a bug against it.

Comment 4 John Arthorne

2003-02-19 16:53:46 EST

Fixed.