ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simeon H.K. Fitch" <sim...@fitch.net>
Subject Re: Prompt task
Date Fri, 01 Dec 2000 04:14:09 GMT
On Thu, Nov 30, 2000 at 12:54:22PM +0100, Stefan Bodewig wrote:
> Hi,
> 
> I've been thinking about a prompt or ask like task, something like
> 
> <prompt alternatives="y,n" expect="y" default="y" property="abort">
> JUnit not found. If you continue, you'll be unable to run tests.
> Abort?</prompt>
> 
> which would produce
> 
> JUnit not found. If you continue, you'll be unable to run tests.
> Abort? [Y/n]
> 
<snip>
> 
> My first idea would be to have a "DialogEngine" at the project
> level. By default there was an engine that writes to System.out and
> reads from System.in (logging system would not be appropriate as you
> wouldn't want the prompt to end up in the log file instead the
> console).
> 
> Each front end could provide an engine of its own, from my first
> impression an interface like
> 
> public String askUser(String prompt, String[] alternatives, String default);
> 

Without making things too complicated, I think it would be a good idea
to take a more generalized architectural approach, as I can see this
type of functionality growing down the road.

First, consider an interface called UserRequest, that encapsulates the
content of the request, as well as the validation of the input:

interface UserRequest {

	/** The prompt to display to the user. */
	String getPrompt();

	/** The default option, or null if no default. */
	String getDefaultOption();

	/** Determine if the string the user entered is a valid
	 *  response. */
	boolean isValid(String response);
}

A request for data would involve instantiating some implementer of
this interface (e.g. BooleanRequest, StringRequest, OptionRequest,
PasswordRequest), and passing it to the Project instance that has had
the following additional methods:

public class Project {
	...

	/** Set the handler for any UserRequest objects. For example,
	 *  CommandLineRequestHandler. */
	public void setRequestHandler(RequestHandler handler);

	/** Submit a request to be handled. Returns validated user
	 *  response, (or null on condition x??).
	public String submitUserRequest(UserRequest request);

	...
}

Then there would be an interface called RequestHandler that both the
command-line version of Ant and Antidote would implement and register
depending on how Ant is being run:

interface RequestHandler {

	/** Submit the given request to the user, and return the user's
	 *  validated response, (or null on condition x??). */
	String getResponse(UserRequest request);
}
	
A command line version of this would look something like this (in
pseudo code).

public class CommandLineRequestHandler implements RequestHandler {
	public String getResponse(UserRequest request) {
		String response	 = null;
		do {
			System.out.println(request.getPrompt());

			response = System.in.readLine(); // whatever...

			if(response.length() == 0) {
				response = request.getDefault();
			}
		} while(!response.isValid(response));

		return response;
	}
}


Also imagine implementing an "AutoRequestHandler" that would behave
like "Expect" whereby the response to questions are looked up in some
property file.

I think an approach like this starts us off on the right foot for
future additions, and meets both the needs of Antidote and commandline
versions in the near term.

sim

-- 
Mustard Seed Software
mailto:simeon@fitch.net

Mime
View raw message