RE: [cdt-dev] User defined CLI command in CommandFactory?

[Andy Jin <ajin@xxxxxxx>]

I don't have a concrete example of how the result will be parsed but I
guess it's no different from the other createCLI* commands in the
CommandFactory that the RequestMonitor.handle*() methods
(handleSuccess(), handleFailure()...) should do the job?

The user of this method should know how to handle them.

The checking of null probably should not be done in the factory but in
the MICommand class, either throws a NPE or make sure getOperation()
returns an empty string if it's null. It's not a problem before because
all the create* methods in the CommandFactory have well-defined
operations. Now we open it up for users to define the operation so we
need to check for null.

It's a good idea to create a generic MI command too, although
technically not required because the generic CLICommand extends the
MIComand already.

I will create a bug.

Thanks,
Andy

-----Original Message-----
From: Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>
Reply-to: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
To: 'CDT General developers list.' <cdt-dev@xxxxxxxxxxx>
Subject: RE: [cdt-dev] User defined CLI command in CommandFactory?
Date: Thu, 11 Mar 2010 13:03:28 -0500

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Andy Jin
> Sent: Thursday, March 11, 2010 12:21 PM
> To: CDT General developers list.
> Subject: RE: [cdt-dev] User defined CLI command in CommandFactory?
> 
> How about:
> 
> public ICommand<MIInfo> createCLICommand(IDMContext ctx, 
> String command)
> {
> 	if (command == null) {
> 		command = new String();
> 	}
> 	return new CLICommand(ctx, command);
> }
> 
> The checking of null is a self-protected so the 
> MICommand.getOperation()
> won't return null.
> 
> We shouldn't need to do output parse because the user of this method
> knows how to parse the output using its specific domain knowledge.

But this parsing would be done where?  I'm under the impression
it will have to be called directly from the RequestMonitor that
returns the MIInfo output.  But that may still be ok.

Could you open a bug and post a patch with an example of command 
that would use it?

Shouldn't we do the same for a generic MI command?

Marc

> -----Original Message-----
> From: Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>
> Reply-to: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
> To: 'CDT General developers list.' <cdt-dev@xxxxxxxxxxx>
> Subject: RE: [cdt-dev] User defined CLI command in CommandFactory?
> Date: Thu, 11 Mar 2010 12:07:41 -0500
> 
> That could be a good idea, but such a CLI command would
> be limited by not being able to get any output parsed, I think.
> 
> What would be the return type of the proposed  
> createCLICommand(IDMContext ctx, String command)
> 
> 
> > -----Original Message-----
> > From: cdt-dev-bounces@xxxxxxxxxxx 
> > [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Andy Jin
> > Sent: Thursday, March 11, 2010 10:32 AM
> > To: cdt-dev@xxxxxxxxxxx
> > Subject: [cdt-dev] User defined CLI command in CommandFactory?
> > 
> > In "org.eclipse.cdt.dsf.mi.service.command.CommandFactory" class, it
> > pre-defines CLI commands and MI commands, but it does not 
> allow a user
> > defined CLI command to be factored from it. Is it a reason 
> > why we don't
> > provide such a method like below?
> > 
> > createCLICommand(IDMContext ctx, String command)
> > 
> > In JTag final launch sequence I have to run specific CLI 
> commands but
> > have to create CLICommand objects for them. Would be better 
> if I could
> > use the factory class to do it.
> > 
> > Thanks,
> > Andy
> > 
> > _______________________________________________
> > cdt-dev mailing list
> > cdt-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> > _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> 
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> _______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev