search

waldenner / robotframework

Automatically exported from code.google.com/p/robotframework
Apache License 2.0
0 stars 0 forks source link

It's now possible to use imported variables in variable table #561

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
1, exact the attached file
2, run "pybot suite1" or "pybot suite1/test.html"

will get error message:
Error in file 'c:\users\suite1\test.html' in table 'Variable' in element on
row 1: Setting variable '${TEST_TEST VAR}' failed: Non-existing variable
'${TEST VAR}'

I think it should be passed for the ${TEST VAR} is defined in resource file
which imported by test.html.

My env: Robot Framework 2.1.2 (Python 2.5.2 on win32)

Original issue reported on code.google.com by fei...@gmail.com on 25 May 2010 at 5:36

Attachments:

GoogleCodeExporter commented 9 years ago 
The problem is caused by RF processing the variable table before imports, which 
is
done to make it possible to use variables in the variable to in imports 
themselves. I
agree that this is an annoying problem, and I hope that as part of other other
variables related changes we can get this fixed too.

Original comment by pekka.klarck on 29 May 2010 at 8:52

GoogleCodeExporter commented 9 years ago 
Is this the same issue like in my problem? 
I have a resource file where I'm creating a library using a JDBC connection 
parameter :     jdbc:jtds:sqlserver://${DB_HOST}:${DB_PORT}/MainDB
and later in the same resource file I'm defining these two variables, but when 
I call  the SQL connect, it fails with the error:

The syntax of the connection URL 
'jdbc:jtds:sqlserver://${DB_HOST}:${DB_PORT}/MainDB' is invalid.

This looks like the Library has been created before the variables are resolved. 

This was working nicely with 2.1.3

cheers,
Kai

Original comment by kai.hack...@gmail.com on 8 Jul 2010 at 3:44

GoogleCodeExporter commented 9 years ago 
The original problem described here occurs with all RF versions. If Kai your 
use case worked with 2.1.3 your problem thus probably isn't related to it. I 
tried reproducing your problem according to your description but failed. Please 
submit a new issue, preferably with a simple example demonstrating the problem.

Original comment by pekka.klarck on 8 Jul 2010 at 6:47

GoogleCodeExporter commented 9 years ago

Original comment by janne.t....@gmail.com on 19 May 2011 at 1:20

GoogleCodeExporter commented 9 years ago 
Issue 858 has been merged into this issue.

Original comment by pekka.klarck on 8 Jun 2011 at 6:57

GoogleCodeExporter commented 9 years ago 
Initially descoped from 2.7 due to lack of time

Original comment by robotframework@gmail.com on 2 Dec 2011 at 8:42

GoogleCodeExporter commented 9 years ago 
Issue 1181 has been merged into this issue.

Original comment by pekka.klarck on 24 Jan 2013 at 1:24

GoogleCodeExporter commented 9 years ago 
I think that the best way to fix this issue is resolving variables created in 
variable table only when needed. That would neatly fix the issue of variables 
used in variable table coming from imported resources or variable files. 
Additionally, variables that are not used could contain variables that are not 
even available (originally issue 1181).

This fix has one interesting open question, though: What to do if the variable 
is used again and the variable inside that variable has changed? Should we keep 
using the same resolved value or should the value change? In my opinion the 
latter is better idea because otherwise the value would depend on when the 
variable is actually used first time. The problem with that behavior is that it 
is potentially backwards-incompatible.

Original comment by pekka.klarck on 24 Jan 2013 at 1:32

GoogleCodeExporter commented 9 years ago 
Issue 1342 has been merged into this issue.

Original comment by pekka.klarck on 24 Jan 2013 at 1:37

GoogleCodeExporter commented 9 years ago 
This is causing problems also at NSN (the main sponsor of the project) so I 
initially target this issue to RF 2.8 that is scheduled for May.

Until this is fixed, there is the following generic workaround:

1) Move all the variables that need variables from imported resources or 
variable files into a separate resource.
2) Take that resource into use after other imports.

Original comment by pekka.klarck on 24 Jan 2013 at 1:45

GoogleCodeExporter commented 9 years ago 
Issue 1377 has been merged into this issue.

Original comment by pekka.klarck on 26 Feb 2013 at 11:59

GoogleCodeExporter commented 9 years ago

Original comment by jussi.ao...@gmail.com on 6 Mar 2013 at 1:55

GoogleCodeExporter commented 9 years ago

Original comment by mikko.ko...@gmail.com on 13 Mar 2013 at 10:29

GoogleCodeExporter commented 9 years ago 
As discussed with peke and others:
We are going to make variables solved on demand while resolving imports - only 
after all imports are resolved are rest of the variables resolved.

Original comment by mikko.ko...@gmail.com on 13 Mar 2013 at 10:30

GoogleCodeExporter commented 9 years ago 
Fixed after r745d6b08b33d

Original comment by mikko.ko...@gmail.com on 14 Mar 2013 at 11:16

GoogleCodeExporter commented 9 years ago 
This issue was updated by revision 14ffec23d596.

Added some more tests. For example, using variables from variable files in
delayed manner and using already delayed value in variable table. The current
implementation already handled all these cases.

Original comment by robotframework@gmail.com on 10 May 2013 at 11:34

GoogleCodeExporter commented 9 years ago 
This issue was updated by revision 6bf5f7e3415a.

Changed delayed vars to use special class instead of a attribute. This is both
cleaner and also safer -- old implementation would have failed if a normal
variable had the special attribute.

Also renamed force_value_resolve -> resolve_delayed.

Original comment by robotframework@gmail.com on 10 May 2013 at 11:34

GoogleCodeExporter commented 9 years ago 
Issue 1437 has been merged into this issue.

Original comment by pekka.klarck on 21 May 2013 at 10:11

GoogleCodeExporter commented 9 years ago 
This change has broken handling errors when non-existing variable is used in 
variable table. Earlier it was reported as a non-fatal error, now the whole 
test execution stops. Needs to be fixed.

Original comment by robotframework@gmail.com on 22 May 2013 at 2:13

GoogleCodeExporter commented 9 years ago 
This issue was updated by revision 7ad690543152.

The problem with non-existing variables is now fixed. I'm really surprised 
there were no tests for this earlier.

Also changed the type of this issue from enhancement to defect. I don't think 
the earlier behavior was a feature.

Original comment by pekka.klarck on 24 May 2013 at 9:51

GoogleCodeExporter commented 9 years ago

Original comment by anssi.sy...@eficode.com on 31 May 2013 at 12:35

GoogleCodeExporter commented 9 years ago

Original comment by anssi.sy...@eficode.com on 31 May 2013 at 1:11

GoogleCodeExporter commented 9 years ago 
This was implemented in a backwards compatible way.

Original comment by tatu.ka...@eficode.com on 31 May 2013 at 1:53