Re: [Soaplab-users] ACD question
Brought to you by:
marsenger
Menu
▾
▴
Re: [Soaplab-users] ACD question
|
From: Marc L. <Mar...@DE...> - 2006-06-27 14:09:06
|
I thought I finally got it. But it seems I am lost again. Or is it only due to some inconsistency in the system ? Tried to use that trick again, as described below. But this time with a default value set to 'true'. Guess what. It does not work at all. Just the opposite behaviour. Consider the acd: boolean: show_header [ additional: "Y" default: "Y" comment: "defaults" comment: "method --noheader" ] The behaviour I expected was: If the user sets show_header to 'true', the --noheader is not put on the command line. In all other cases (e.g. show_header =3D> false) the = passed value is different from the default and thus, --noheader is put on the command line. It happened to be completely the way around. On the other hand, if this was put in the acd (like in the old post below) it behaves as expected. boolean: no_header [ additional: "Y" default: "N" comment: "defaults" comment: "method --noheader" ] Meaning: if no_header is set to 'true', --noheader is added to the command line, if no_header is ommitted or set to 'false', the option is not added to the command line because 'false' is the default value. Why did it not work in the other way (the first example) ? What is the system behind it ???? Am I missing something ? Cheers, Marc > -----Original Message----- > From: soa...@li...=20 > [mailto:soa...@li...] On Behalf=20 > Of Marc Logghe > Sent: Thursday, February 23, 2006 6:06 PM > To: soa...@li... > Subject: RE: [Soaplab-users] ACD question >=20 > Feels a little strange, answering my own post ;-) >=20 > Finally I used this trick: >=20 > boolean convert_to_uppercase [ > additional: "Y" > prompt: "Convert to uppercase" > default: "false" > comment: "defaults" > comment: "method -u" > ] >=20 > The trick is taking advange of an applab feature and works as=20 > such: if a user passes a value that matches the default value=20 > (here set to false) the option is not passed to the command=20 > line. With any other value different from false (e.g true :-)=20 > applab will pass the option '-u' to the command line. >=20 > You can use that trick also for other parameter types but you=20 > have to take care: you should not lie about the default value !! > Because: Suppose you have a blast service and a paramater=20 > expect_cutoff that defaults to 1E-2 (at least, according to=20 > the acd file). However, the blastall default e-value is 10.0. > Meaning, in the acd you actually lied about the real default=20 > e-value that blastall is using. As a consequence, when a user=20 > really passes the value 1E-2 for the expect_cutoff parameter,=20 > it matches the default value and therefor the option is not=20 > passed to the blastall command line. As a result, blastall is=20 > run with the real e-value of 10.0 !=20 >=20 > Hope it will help somebody, some day ... >=20 > Cheers, > Marc >=20 >=20 >=20 > > -----Original Message----- > > From: soa...@li... > > [mailto:soa...@li...] On=20 > Behalf Of Marc=20 > > Logghe > > Sent: Thursday, February 23, 2006 4:15 PM > > To: soa...@li... > > Subject: [Soaplab-users] ACD question > >=20 > > Hi, > > Suppose you have a command line that takes an option -u (let say it=20 > > means uppercase). If '-u' is omitted, it produces lowercase. > > I started off like this: > >=20 > > boolean convert_to_uppercase [ > > additional: "Y" > > prompt: "Convert to uppercase" > > comment: "method -u" > > ] > >=20 > > A soaplab user would see the option 'convert_to_uppercase'.=20 > > Internally this is mapped by soaplab to '-u' without a value. > > Problem is, no matter what value is given (true or false)=20 > this option=20 > > would be put on the command line and this is not what the user=20 > > expects. > > Is there a way to make this conditinal ? > > Something like: > > comment: "method @($$ =3D=3D true ? '-u' : '') > >=20 > > I have a terrible feeling I am overlooking something ... > > But any suggestions are welcome. > > Thanks, > > Marc > >=20 > >=20 > > ------------------------------------------------------- > > This SF.Net email is sponsored by xPML, a groundbreaking scripting=20 > > language that extends applications into web and mobile=20 > media. Attend=20 > > the live webcast and join the prime developer group=20 > breaking into this=20 > > new coding territory! > > = http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=110944&bid$1720&dat=121642 > > _______________________________________________ > > Soaplab-users mailing list > > Soa...@li... > > https://lists.sourceforge.net/lists/listinfo/soaplab-users > >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking=20 > scripting language that extends applications into web and=20 > mobile media. Attend the live webcast and join the prime=20 > developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=110944&bid$1720&dat=121642 > _______________________________________________ > Soaplab-users mailing list > Soa...@li... > https://lists.sourceforge.net/lists/listinfo/soaplab-users >=20 |
