[TxMt Plugins] Dialog API improvements

[Chris Thomas]

On Sep 20, 2007, at 11:34 PM, Joachim Mårtensson wrote:

> the above has the benefit of not require a more involved parser.  I  
> think
> we should wait with the show and create keywords until there are  
> enough
> commands to warrant wandering of the 'tm_dialog <option> <--flag>  
> path. I
> do not think that the normal usage pattern of tm_dialog requires  
> anything
> more involved, I would guess that people write a command once and  
> stores
> it in a {rb,py}. Calling it by hand from the Command Line is  
> probably a
> very uncommon behavior (except when debugging). What I am trying to  
> say is
> that while more involved schemas look cool they are more complicated  
> to
> write and in the end there will be very few cheering for our insane  
> coding
> skills anyway.

I prefer to stick with "--switch" for optional arguments, but I think  
you actually simplify the implementation slightly if you use an  
"object-oriented" syntax. The core dispatching code for a noun-verb  
("create|show|close window") would look something like:

@implementation TMUIServer
- (void)dispatchCommandLine:(NSArray *)commandLineItems
{
	// We must have a verb and a noun (TODO: handle --version)
	NSParameterAssert([commandLineItems count] > 2);
	
	NSString *		verb = [commandLineItems objectAtIndex:0];
	NSString *		noun = [commandLineItems objectAtIndex:1];
	
	// Find the command corresponding to the noun (TODO: this could be  
lazier and instantiate objects on demand)
	TMUICommand *	UICommand = [sSubcommandDictionary objectForKey:noun];
	
	// Dispatch the verb to the noun
	NSString *		methodName = [NSString stringWithFormat:@"perform 
%@WithArguments:", [verb capitalizedString]];
	SEL 			methodSelector = NSSelectorFromString(methodName);
	
	if([UICommand respondsToSelector:methodSelector])
	{
		id error = objc_msgSend(UICommand, methodSelector, commandLineItems);
	}
	else
	{
		// raise exception...
	}
}
@end

Parsing the remainder of the arguments would be the subcommand's  
responsibility, probably using a method provided for that purpose in  
the base class. This structure provides the property that any changes  
to a subcommand, even to accept a different set of arguments, are  
limited to that subcommand's source code. It allows new commands to be  
added without modifying any common code.

You can do the same thing with a single subcommand name ("tm_dialog  
create-window file.nib") as a part of the command name by storing a  
"command -> [class, selector]" mapping instead of the simpler "noun ->  
class" mapping. But I think I still prefer the "noun verb" syntax,  
because it enforces two desirable attributes when creating new  
commands: (a) the command is readable in source code and (b) there is  
room for future expansion.

Chris