View HTML of plain capybara element without using the driver - ruby-on-rails

Please note the difference between my question and others like this one is that I am looking for a way to do this without using driver methods.
Is there a way to view all the HTML of a given Capybara Element without driver support?
Currently, a plain Capybara element allows you to access the attributes, if you know about them:
# <span class="one" id="two" data="three">
el = find(".klass")
el['class'] #=> "one"
el['id'] #=> "two"
It seems like surely there should be a way to just view the entire set of attributes, but I can't find a way without driver support. Is there a way to get something like this?
el.html #=> <span class=\"one\" id=\"two\" data=\"three\">

No, there is not. Here are the methods you get. The closest you get is the native method, which you do not wish to use. You can see how it is done by drivers by looking at their code - you need the driver. You can verify this yourself by running my_cabybara_element.methods.sort, there just isn't anything there for this.

Related

Ranorex Spy - The recognition elements on the page (prioritizing attributes)

I have question related to the Ranorex Spy.
Is it possible to recognize (by default) elements of the page by attribute other than id, e.g. data-id
I know that I can modify this later manually for each element (but it is time consuming)
Currently:
\input[#id='..."]
Expected (automatically, by Ranorex Spy):
\input[#data-id='..."]
I personnally did not bother using this (because we use many frameworks and whats desired in one framework is not necessarily whats desired in another one) but I think you can achieve priorisation of XPath rules using the RanoreXPath Weight Rules.
Following is a Ranorex article describing how to do this: http://www.ranorex.com/support/user-guide-20/ranorexpath-weight-rule-library.html
Good luck!

In Appium 1.0+, now that finding elements by tag is deprecated, how do I find an element by tag name when operating on the DOM of the webview?

Once I switch my context to the DOM of the webview, I want to be able to search those elements by tag, but I get the error that searching by tag is deprecated and to search by class instead. This won't work to find DOM elements by tag. Is there still a way to do it? Thanks!
As per Appium documentation for migrating to 1.0:
We've removed the following locator strategies:
-name
-tag name
... tag name has been replaced by class name. So to find an element by its
UI type, use the class name locator strategy for your client.
Why searching by tag name?
Although Selenium still supports this type of query, Appium decided not to do anymore. Actually when interacting with the device, searching by tag name is very inefficient.
Why would you want to do that? Think about it, if your page has a bit of content, you will end up having many p, div, span tags. Your search will return many elements and then you will have to go thorugh the list and locate the one you are interested in. If your page is very little, then you will probably end up with one tag of the type you are looking for, however why not applying a class and solve the problem?
Classes are not for CSS style
Remember that HTML attribute class was not introduced by W3C for applying CSS style. It is used to provide an element with more informationa bout its purpose in the DOM. When you apply a class to an element, you should do that basing on the role that element holds! Thus locating an element by class is sure better.
So forget searching by tag name. You should change your strategy and apply class names to your tags in your hybrid app. If you do not want to do so, then do not switch to the new version of Appium but this will keep you far from future innovations!
Migrating from a tagname based element location to a class name
orientd one is good practice. That's why you should change too.
maybe this can help
element.getAttribute("class")

Making tagsoup markup cleansing optional

Tagsoup is interfering with input and formatting it incorrectly. For instance when we have the following markup
Text outside anchor
It is formatted as follows
Text outside anchor
This is a simple example but we have other issues as well. So we made tagsoup cleanup/formatting optional by adding an extra attribute to textarea control.
Here is the diff(https://github.com/binnyg/orbeon-forms/commit/044c29e32ce36e5b391abfc782ee44f0354bddd3).
Textarea would now look like this
<textarea skip-cleanmarkup="true" mediatype="text/html" />
Two questions
Is this the right approach?
If I provide a patch can it make it to orbeon codebase?
Thanks
BinnyG
Erik, Alex, et al
I think there are two questions here:
The first Concern is a question of Tag Soup and the clean up that happens OOTB: Empty tags are converted to singleton tags which when consumed/sent to the client browser as markup gets "fixed" by browsers like firefox but because of the loss of precision they do the wrong thing.
Turning off this clean up helps in this case but for this issue alone is not really the right answer because we it takes away a security feature and a well-formed markup feature... so there may need to be some adjustment to the handling of at least certain empty tags (other than turning them in to invalid singleton tags.)
All this brings us to the second concern which is do we always want those features in play? Our use-case says no. We want the user to be able to spit out whatever markup they want, invalid or not. We're not putting the form in an app that needs to protect the user from cross script coding, we're building a tool that lets users edit web pages -- hence we have turned off the clean-up.
But turning off cleanup wholesale? Well it's important that we can do it if that's what our usecase calls for but the implementation we have is all or nothing. It would be nice to be able to define strategies for cleanup. Make that function plug-able. For example:
* In the XML Config of the system define a "map" of config names to class names which implement the a given strategy. In the XForm Def the author would specify the name from the map.
If TagSoup transforms:
Text outside anchor
Into:
Text outside anchor
Wouldn't that be bug in TagSoup? If that was the case, then I'd say that it is better to fix this issue rather than disable TagSoup. But, it isn't a bug in TagSoup; here is what seems to be happening. Say the browsers sends the following to the client:
<a shape="rect"></a>After<br clear="none">
This goes through TagSoup, the result goes through the XSLT clean-up code, and the following is sent to the browser:
<a shape="rect"/>After<br clear="none"/>
The issue is on the browser, which transforms this into:
<a shape="rect">After</a><br clear="none"/>
The problem is that we serialize this as XML with Dom4jUtils.domToString(cleanedDocument), while it would be more prudent to serialize it as HTML. Here we could use the Saxon serializer. It is also used from HTMLSerializer. Maybe you can try changing this code to use it instead of using Dom4jUtils.domToString(). You'll let us know what you find when a get a chance to do that.
Binesh and I agree, if there is a bug it would be a good idea to address the issue closer to the root. But I think the specific issue he is only part of the matter.
We're thinking it would be best to have some kind of name-to-strategy mapping so that RTEs can call in the server-side processing that is right for them or the default if it's not specified.

Rails Dynamic tag generation from context

Let's say I want to trend all comments posted on a site and create dynamic tags. For example, If there are x number of comments that contain the word iPad I would like to create automatically create a tag called "iPad" and put it in a tag cloud.
Is this possible? I checked out the acts_as_taggable gem but it requires one to specify a tag, I guess I am looking for a way to generate tags from content.
Well something like the yahoo term extraction service might do the trick and there is a plugin for it http://expressica.com/auto_tags/.
Though it is not for commercial use.
Sure, this is possible.
Just parse the content of each comment as it's passed in and attach the tags you're interested in.
This can either work on a whitelist - where you specify all the tags you're interested in and attach those if relevant.
Or it could work on a blacklist - where you specify all the words to ignore, e.g. "the", "on". This approach is probably a lot more time consuming, but would allow for more dynamic results.
I would probably work on a white list, then have an ability to add new tags to the whitelist and have it go back and retroactively add the tags where applicable.

Fill a rails form with a hashmap

I have a difficult situation.
I let the the user create a form through a Rich Text Editor and then I save this.
So for example, I save this literally into my DB:
http://pastebin.com/DNdeetJp (how can you post HTML here? It gets interpreted, so now I use pastebin...)
On another page I wrap this in a form_tag and it gets presented as it should be.
What I want to do is save this as a template and save the answers as a hashmap to my DB.
This works well, but the problem is I want to recreate what checkbox/radiobutton/... is selected when the user goes back to the page. So I want to fill the form with the answers from the hashmap.
Is there a way to use a 'dummy' model or something else to accomplish this?
Thanks!
Since you're pasting in raw HTML which is not properly configured as a template, it is more difficult to enable the proper options based on whatever might be stored in your DB.
The reliable approach to making this work is to use Hpricot or Nokogiri to manipulate the bit of HTML you have and substitute values accordingly. This isn't too hard so long as you can define the elements in that form using a proper selector. For example, create a div with a unique id and operate on all input elements within it, comparing the name attribute with your properties. There may even be a library for this somewhere.
The second approach is to use JavaScript to enable the options in much the same fashion. This seems like a bit of a hack since the form itself will not have a proper default state.

Resources