Sorry for the goof up. Please download the jar again from the link above.

Thanks,
Anubhava

Thank you very much for your promptness and help.
We got the new jar but before we could confirm that the blanks work ok we got another strange error.
Our calls using getEval or waitForCondition started failing.
When we looked at the log of selenium control window we spotted ‘null’s appearing where they shouldn’t…

Example:
the dsl call:
window.document.evaluate( “…..”\, window.document\, null\, XPathResult.NUMBER_TYPE\, null ).numberValue

was interpreted (sent to selenium) as:
window.document.evaluate( “…..”, window.document, , nullXPathResult.NUMBER_TYPE, )null.numberValue

instead of (normal):
window.document.evaluate( “…..”, window.document, null, XPathResult.NUMBER_TYPE, null).numberValue

which ofcourse gave origin to a selenium syntax error (and ‘broke’ almost all of our test narratives..)

Please help,
thanks in advance.

Well these special symbols (blank, null) were intended to be used independently and not in full expressions i.e
| someMethod | blank |
instead of your usage:
| getEval | “blank” == “” |

But since you asked I have made a change in the code to support your requirements. Please download the latest jar file from this link: http://sourceforge.net/projects/genericfixture/files/genericfixture/genericfixture_v1/genericfixture.jar/download

And run your scripts as is and it should work fine.

Cheers,
Anubhava

We seem to have another problem with the use of blank. This time when used with javascript calls (e.g. getEval of Selenium RC).
Example:

The test below FAILS:

!| DSL Adapter |
| compare | % | to empty string | getEval | “{1}”==”" |
!| Generic Fixture | ${sel} |
| compare | blank | to empty string | | true |

While the test below succeeds:
(a previously filled-in text input has its content deleted)

!| Generic Fixture | ${sel} |
| user types | blank | into field with id | description |
!| Generic Fixture | ${sel} |
| get value from field | description | | blank |

So it seems to be related with the JS type or the getEval call itself..

Thanks in advance,
Aristotelis.

Your assessment is right because Generic Fixture was translating these symbols (null, blank etc) before calling DSL and that’s why DSL was not matching for you. I have made a small change in the code.

New genericfixture.jar has been uploaded to the sourceforge repository. Please download the latest jar file for your test. It should fix the problem for you.

cheers,
Anubhava

Thanks for your explanation.

We have a problem in using the blank.
We confirm that everytime we use it to pass a blank string the DSL mapping fails (“could not be found matching given parameters” error).

Could this be because of the code of Generic Fixture?

Can you pass blank (or otherwise an empty string) in a DSL call?

Example:
!| Generic Fixture | ${sel} |
| user types | blank | into field | firstname |

Error given:
java.lang.NoSuchMethodException: Method [com.thoughtworks.selenium.DefaultSelenium.userTypes()] could not be found matching given parameters

Thanks again,
Aristotelis.

What do you mean by empty variable? Is your variable of java.lang.String type and you want to pass a blank (“”) string? If that is the case you can simply use keyword blank in your script. (Please make sure it is blank in lowercase).

Otherwise a variable can be of any object type and a null can be passed in its place (please make sure it is null in lowercase).

However just by omitting a value altogether as in your example is not going to work, that is FitNesse behaviour.

Thanks,
Anubhava

Thanks for the answer! It would take us ages to pinpoint that issue! Once again, though, we look for your guidance:

We have created some rather long DSL calls and we have been getting errors of the type:

java.lang.NoSuchMethodException: Method [eu.europa.blahblah.gfplugin.FixtureContext.thisIsAFriendlyNameThatShouldBeReplacedByTheFunctionName:()] could not be found matching given parameters

obviously, the DSL mapping and replacements did not take place.

We think we have narrowed down the problem down to a surprising fact: the DSL mapping fails when a variable is passed emtpy. E.g.:

| Generic Fixture | ourdb= |
| friendly name with parameter | | and parameter || doing sth|
gives an error while the following does not:
| Generic Fixture | ourdb= |
| friendly name with parameter |a| and parameter | a | doing sth|

Is this normal? Are we doing sth wrong?

Thanks in advance,
Aristotelis.

Yes I have also noticed that behavior and trust me it is purely Fitnesse Wiki syntax thing. What happens is sometimes a space character gets appended to the last pipe character (|) of a row. And then FitNesse Wiki makes next row in the table a plain text thus breaking your test table.

I’m really not sure if there is a way to overcome this on FitNesse but I do suggest you to use either Excel or install a FitNesse plugin to do WYSIWYG editing of large FitNesse tables to avoid this annoying behavior.

Cheers,
Anubhava

We have been noticing occasionally a strange behaviour that has been difficult to handle and we do not know why it happens.

We have a fitnesse page with our DSL and when we view it, it looks ok (all tables are represented correctly).

This page is included in all our tests.

Yet if we open the collapsible section of the DSL page within the test page in which it has been included, some content ‘looses its tables’.
E.g. we see the DSL Adapter within a cell of a table but the row that follows is not in a table…

It has been very difficult to understand why this happens and any occasional solution that has taken place we have not been able to understand why.
We try to move lines around, re-type the lines and other actions but as I said we are lost in this.

Have you ever seen that before? Is that a Fitnesses or Generic Fixture bug?
Is there any problem in handling large pages?

Any help would be greatly appreciated..

Thanks again,
Aristotelis.