I started using react-i18next a few days ago and I am very satisfied with it. However, I've been seeing this 'cimode' language here and there, in some posts and while debugging, but have no clue what it means. I've searched all over, I believe, and can't find any documentation on it.
In my particular case, I am generating some boilerplate code in a new website and created a demo page to show how to use localization in the website. I am generating toggle language buttons from the languages I set on the whitelist and, to my surprise, I have a 'cimode' button. I know I can filter it out and I will, but I would like to know what it should be used for and maybe to see better documentation for it in https://react.i18next.com/.
From my understanding, CIMODE is used for testing to consistently return the translation key instead of the variant value.
It seems rather hidden on the FAQ.
We are running Ektron 8.50 SP2(Build 8.5.0.356) / eWebEditPro.
The issue we are seeing is when a smart form text field is left blank it is randomly filled with the following...
<Body>
<p title="temporary paragraph, click here to add a new paragraph"> </p
</Body>
Anyone else come across this?
I realize the most obvious 'next step' would be to upgrade. Unfortunately for many reasons this is not an option.
Any advice would be appreciated.
Thanks,
ozmo
You're right, the obvious answer is to upgrade. Ektron moved from eWebEditPro to Aloha as the editor of choice precisely because of issues like this that cropped up as they fought to strike the right balance between cleanliness and usability (prior to this issue, editors would complain that they couldn't get the cursor into the blank space as they wanted... it was a mess).
So my first question is: why can't you upgrade? Is it a business problem or a technology problem?
No other editor is going to be embeddable into the workarea besides, perhaps, their old ActiveX plugin that only works in IE and probably not some of the later versions.
So without an upgrade on the table, your only other options are to:
Edit outside of the workarea. This would require you to create and secure your own admin pages, but it would allow you to set up the form for input however you like and with whatever editor you like, as long as you XML encode any special characters (which is different from HTML encoding; note the 'space' above is and not ).
Create an extension (aka "Content Strategy") which would do the clean-up you want as the item is being saved or published. Documentation for creating a strategy is in the Ektron docs, accessible through http://documentation.ektron.com (redirects to Episerver World, but to the page with links to the docs). You would have to create the strategy, insert your own logic, then add it to the site.
Let me know if there's more info I can provide. But I can't solve for this specific case since I don't have a comparable version of Ektron installed anywhere.
I want to evaluate my content blocks before running my test suite but the closures' property names is in bytecode already. I'm ooking for the cleanest solution (compared with parsing source manually).
Already tried solution outlined in this post (and I'd still wind up doing some RegEx/parsing) but could only get it to work via script execution engine. It failed in IDE and GroovyConsole. Rather than embedding a Groovy script in project's code, I thought I'd try using Geb's native classes.
Is building on the suggestion about extending Geb Navigators here viable for Geb's PageContentSupport class whose contentTemplates contain a LinkedHashMap of exactly what I need? If yes, would someone provide guidance? If no, any suggestions?
It is currently not possible to get hold of all content elements for a given page/module. Feel free to create an issue for this in Geb's bug tracker, but remember that all that Geb can provide is either a list of content element names or a map from these names to closures that create these elements.
Having that information isn't a generic solution to your problem because it's possible for content elements to take parameters and there are situations where your content elements will be available on the page only after some other actions are performed (for example you have to click on button to reveal a section of a page that uses ajax to retrieve it's content). So I'm afraid that simply going over all elements and checking if they don't throw any errors will not cut it.
I'm still struggling to see what would "evaluating" all content elements prior to running the suite buy you. Are you after verifying that your content elements still work to get a faster feedback than running the whole suite? I'm pretty sure that you won't be able to fully automate detection of content definitions that don't work anymore. In my view it will be more effort than it's worth.
How do I resolve ambiguity in Capybara? For some reason I need links with the same values in a page but I can't create a test since I get the error
Failure/Error: click_link("#tag1")
Capybara::Ambiguous:
Ambiguous match, found 2 elements matching link "#tag1"
The reason why I can't avoid this is because of the design. I'm trying to recreate the twitter page with tweets/tags on the right and the tags on the left of the page. Therefore it will be inevitable that identical links page shows up on the same page.
My solution is
first(:link, link).click
instead of
click_link(link)
Such behavior of Capybara is intentional and I believe it shouldn't be fixed as suggested in most of other answers.
Versions of Capybara before 2.0 returned the first element instead of raising exception but later maintainers of Capybara decided that it's a bad idea and it's better to raise it. It was decided that in many situations returning first element leads to returning not the element that the developer wanted to be returned.
The most upvoted answer here recommend to use first or all instead of find but:
all and first don't wait till element with such locator will appear on the page though find does wait
all(...).first and first won't protect you from situation that in future another element with such locator may appear on the page and as the result you may find incorrect element
So it's adviced to choose another, less ambiguous locator: for example select element by id, class or other css/xpath locator so that only one element will match it.
As a note here are some locators that I usually consider useful when resolving ambiguity:
find('ul > li:first-child')
It's more useful than first('ul > li') as it will wait till first li will appear on the page.
click_link('Create Account', match: :first)
It's better than first(:link, 'Create Account').click as it will wait till at least one Create Account link will appear on the page. However I believe it's better to choose unique locator that doesn't appear on the page twice.
fill_in('Password', with: 'secret', exact: true)
exact: true tells Capybara to find only exact matches, i.e. not find "Password Confirmation"
The above solution works great but for those curious you can also use the following syntax.
click_link(link_name, match: :first)
You can find more information here:
http://taimoorchangaizpucitian.wordpress.com/2013/09/06/capybara-click-link-different-cases-and-solutions/
NEW ANSWER:
You can try something like
all('a').select {|elt| elt.text == "#tag1" }.first.click
There may be a way to do this which makes better use of the available Capybara syntax -- something along the lines of all("a[text='#tag1']").first.click but I can't think of the correct syntax off hand and I can't find the appropriate documentation. That said it's a bit of a strange situation to begin with, having two <a> tags with the same id, class, and text. Is there any chance they are children of different divs, since you could then do your find within the appropriate segment of the DOM. (It would help to see a bit of your HTML source).
OLD ANSWER: (where I thought '#tag1' meant the element had an id of "tag1")
Which of the links do you want to click on? If it's the first (or it doesn't matter), you can do
find('#tag1').click
Otherwise you can do
all('#tag1')[1].click
to click the second one.
You can ensure that you find the first one using match:
find('.selector', match: :first).click
But importantly, you probably do not want to do this, as it will lead to brittle tests that are ignoring the duplicate-output code smell, which in turn leads to false positives that keep working when they should have failed, because you removed one matching element but the test happily found the other one.
The better bet is to use within:
within('#sidebar') do
find('.selector).click
end
This ensures that you're finding the element you expect to find, while still leveraging the auto-wait and auto-retry capabilities of Capybara (which you lose if you use find('.selector').click), and it makes it much clearer what the intent is.
To add to the existing body of knowledge here:
For JS tests, Capybara has to keep two threads (one for RSpec, one for Rails) and a second process (the browser) in sync. It does this by waiting (up to the configured maximum wait time) in most matchers and node-finding methods.
Capybara also has methods that don't wait, primarily Node#all. Using them is like telling your specs that you'd like them to fail intermittently.
The accepted answer suggests page.first('selector'). This is undesirable, at least for JS specs, because Node#first uses Node#all.
That said, Node#first will wait if you configure Capybara like so:
# rails_helper.rb
Capybara.wait_on_first_by_default = true
This option was added in Capybara 2.5.0 and is false by default.
As Andrei mentioned, you should instead use
find('selector', match: :first)
or change your selector. Either will work well regardless of config or driver.
To further complicate things, in old versions of Capybara (or with a config option enabled), #find will happily ignore ambiguity and just return the first matching selector. This isn't great either, as it makes your specs less explicit, which I imagine is why no longer the default behavior. I'll leave out the specifics because they've been discussed above already.
More resources:
https://thoughtbot.com/blog/write-reliable-asynchronous-integration-tests-with-capybara
https://makandracards.com/makandra/20829-threads-and-processes-in-a-capybara-selenium-session
Due to this post, you can fix it via "match" option:
Capybara.configure do |config|
config.match = :prefer_exact
end
As considering all the above options, you can try this too
find("a", text: text, match: :prefer_exact).click
If you are using cucumber, you can follow this too
You can pass the text as a parameter from the scenario steps which can be generic step to reuse again
Something like When a user clicks on "text" link
And in step definition When(/^(?:user) clicks on "([^"]*)" (?:link)$/) do |text|
This way, you can reuse the same step by minimizing the lines of code and would be easy to write new cucumber scenarios
To avoid ambiguous error in cucumber.
Solution 1
first("#tag1").click
Solution 2
Cucumber features/filename.feature --guess
I was wondering, it would be great to know how to allow users to format their posts in Ruby on Rails 3. Ideally, i was wondering if there are any gems or solutions to implementing a formatting system similar to stackoverflow, where the user can bold and underline text, and so on (ie provides a little partial above the post input field similar to the one above the input field we use to ask questions).
Any ideas?
Thanks everyone!
If anyone is still interested in this question, there are a bunch of options for formatting comments and for text editor helpers.
To be brief, I've checked out a whole bunch of options - but I found one that I think is awesome: ckeditor. Check it out at https://github.com/galetahub/ckeditor