everyone.
What I want to do - to create an empty/pristine iframe on testcafe page.
Problem:
Testcafe/hammerhead injects custom script, that overrides prototypes and creates many global variables. I need to prevent it somehow. So I need to create iframe on testcafe page, but without all this custom injected stuff.
Is there any API method or "hack" for this?
I use the latest testcafe version.
TestCafe cannot operate with an iframe without embedding service scripts.
I agree that making a global variable is not the best practice in JavaScript.
However, TestCafe's global variable is marked as non-enumerable (see here). It means that the client's script cannot find this global variable because it cannot access it without knowing this variable's name.
In my opinion, the prototype overriding is not a big problem because a lot of JavaScript frameworks (Angular, JQuery, etc.) do the same.
Related
I am doing an automation where i am writing xpath for some elements again and again how to maintain a centralized repository to access from java code.
There are multiple ways to create a common Object Repository for locators.For Eg:
Read from the excel sheet and at the beginning of execution get all locators into hashmap.
Create a class and keep locators as class level variables.
Read from properties file like a key value pair.
This totally depends upon you framework .
Use PAGE OBJECT MODEL.
See this for reference: CLICK
Quoting from link above, here is one of its benefits:
The Second benefit is the object repository is independent of test cases, so we can use the same object repository for a different purpose with different tools. For example, we can integrate POM with TestNG/JUnit for functional Testing and at the same time with JBehave/Cucumber for acceptance testing.
So for re usability, how can I reuse some particular amount of code from one feature file to other feature file.
I don't want to keep functions outside in js files.
As of now, this is not possible with karate.
IMHO, this is not even valid enhancement request. If you really want to reuse the code, it would be better idea to keep outside of feature file in js function and calling them from different feature files as and when needed.
Peter Thomas, author of Karate, mentioned here that reuse of feature is possible and one cannot reuse the particular scenario from feature file.
I don't want to keep functions outside in js files.
You don't have to. Please read the documentation. There are multiple ways for code-reuse:
the call keyword for re-usable features
Background / hooks
calling Java
Normally all global variables and functions in a JS script in a browser are attributes to Window, if I'm right.
With modules that shouldn't be the case. What determines that global vars and funcs do not become attributes to Window? I haven't found a module keyword.
I've been reading quite a lot about this, but it seems to be so self-evident that I could not find an explanation.
I am using Apache Tomcat with Velocity and VelocityViewServlet. I have created a custom tool with refference to ViewContext. It all works well.
The question is: what is best way to locate/load template and procces it with suplied parameters?
I have already absolute path to the file obtained via
((ViewContext)context).getRequest().getSession().getServletContext().getRealPath("/")
Do I have to instantiate VelocityEngine? I suppose there is no global maintained by Velocity (VelocityViewServlet)
Which (and how) of Velocity loaders is best to use?
Several points here:
The VelocityViewServlet will instantiate itself a VelocityEngine. It's not global, it's one engine per ServletContext.
The VelocityViewSerlet will locate itself the template that corresponds to the request URI using its default loader (WebappLoader), so you don't have to do it yourself either.
The Velocity context your template will be evaluated with, will already be populated with all standard tools (for tools 2.0), among which $params which allows you to inspect HTTP parameters.
I don't understand "a custom tool with refference to ViewContext": instead of using the ViewContext, you should add to your custom tool all the appropriate setters you need among the properties listed here (for instance, if you need access to the request, then you'll declare a "public setRequest(HttpServletRequest request)" method). Remember that from a bottom-up perspective, your tool must be only reachable via a key that you choose for it in your tools configuration file, and should not be aware of Velocity.
I advise you to use VelocityTools 2.0, which is a more mature library than the 1.x.
In a Rails 3.1 app, one controller needs to have all its views compile whatever Sass stylesheets they might need per request using a set of custom variables. Ideally, the compilation must happen via the asset pipeline so that content-based asset names (ones that include an MD5 hash of the content) are generated. It is important for the solution to use pure Sass capabilities as opposed to resorting to, for example, ERB processing of Sass stylesheets.
From the research I've done here and elsewhere, the following seems like a possible approach:
Set up variable access
Create some type of variable accessor bridge using custom Sass functions, e.g., as described by Konstantin Haase here (gist). This seems pretty easy to do.
Configure all variable access via a Sass partial, e.g., in _base.sass which is the Compass way. The partial can use the custom functions defined above. Also easy.
Capture all asset references
Decorate the asset_path method of the view object. I have this working well.
Resolve references using a custom subclass of Sprockets::Environment. This is also working well.
Force asset recompilation, regardless of file modification times
I have not found a good solution for this yet.
I've seen examples of kicking off Sass processing manually by instantiating a new Sass::Engine and passing custom data that will be available in Sass::Script::Functions::EvaluationContext. The problem with this approach is that I'd have to manage file naming and paths myself and I'd always run the risk of possible deviation from what Sprockets does.
I wasn't able to find any examples of forcing Sprockets processing on a per-request basis, regardless of file mod times, that also allows for custom variable passing.
I'd appreciate comments on the general approach as well as any specific pointers/suggestions on how to best handle (3).
Sim.
It is possible. Look here SASS: Set variable at compile time
I wrote a solution to address it, I'll post soon and push it here, in case you or someone else still need it.
SASS is designed to be pre-compiled to CSS. Having Sprockets do this for every request for a view on a per request basis is not going to perform very well. Every request is going to have to wait for the compilation to be done, and it is not fast (from a serving-pages point of view).
The MD5 generation is within Sprockets, so if you are changing custom variables you are going to have to force a compilation on every single request to make sure that changes are seen because the view is (probably) not going to know.
It sounds as though this is not really in the sweet-spot of the asset-pipeline, and you should look at doing something more optimised for truly dynamic CSS.
Sorry. :-)