I want to use the SLDS picklist found here.
I'm using several other SLDS elements in my page and they work fine, I have included the necessary SLDS css.
The picklist doesn't actually work in the example they provide so I'm wondering if there is additional configuration required? The documentation does not mention any.
Can anyone tell me what the problem is?
As of my understanding after reading the SLDS documentation the SLDS is just a CSS "framework". For the picklist to work (open) you need to include some Javascript and more specifically the picklist is "opened" by adding a class slds-is-open to the element (picklist). Apply the class to the div stated below.
<div class="slds-picklist slds-dropdown-trigger slds-dropdown-trigger--click slds-is-open" aria-expanded="true">
I can't really make a demo out of this since the SLDS is so complicated to install but hopefully this can help you.
Well those dropdowns require some kind of javascript or jquery so there should be a file you have to include. CSS just styles the content it doesen't make it work XD
if you not comfortable with JS you can use this JS library
or add slds-is-open class on click event
If you are working with desktop application only (no SalesForce1), a simple way to make it work without adding code is removing the trigger--click
Just let the div like this:
<div class="slds-dropdown-trigger slds-is-open"> *//your list//* </div>
And it will work when you put your mouse over the icon.
It will have a weird behavior in SalesForce1 because you can't put your finger "over" without "clicking" the screen, keep that in mind.
PS: slds-dropdown-trigger is deprecated at the moment in SLDS documentation, keep that in mind too.
I have created many snippets in the Chrome devtool's "Elements > Snippets" panel.
I have a snippet with utility functions like loadJquery, loadUnderscore, etc. I would like to call these functions from another snippet. Is this possible?
Came here cause I struggle with the same question.
I think the correct answer would be yes, if you run each one of them individually and in dependency order.
For example, I have a snippet with a pickDeep() functionality that I got from here. And then I created some other snippets which use that function. So what I do is just run the one with the pickDeep() declaration first, and then any other snippet which use it.
It's the exact same thing as you had typed and run everything on the console directly. So it does not matter where the declaration comes from, as long as it has been declared some way in the current session.
Of course is not the desirable way, but I want to point out there is a workaround.
No, snippets have no knowledge of other snippets nor is there a way to query them up. Snippets are isolated scripts that work independently of each other.
I am trying to follow these examples:
http://aspnetboilerplate.com/Pages/Documents/Authorization
Everything works fine in backend, but in JavaScript frontend, abp.auth.gantedPermissions is empty.
I'm probably missing something but I have no clue what it could be.
abp.auth.gantedPermissions is misspelled. It should be abp.auth.grantedPermissions.
If you just misspelled it when writing the question, you can try the following:
Add AbpZeroCoreModule as a dependency of your Core module. The reason this fixes the issue is that, if the AbpZeroCoreModule is not referenced, the NullPermissionChecker is used and as the name implies, it doesn't provide any permissions at all.
I'm extensively using debug level logging like that:
Log::instance()->add($this->debugLogLevel, "\nTransaction is started");
What I don't like is that it interferes with real code. Is there any way to define custom highlighting for these pieces of code (like for example for comments)?
As far as I'm aware there is no such option.
http://youtrack.jetbrains.com/issue/IDEABKL-1561
A W3C-validated HTML 5 web page contains this working, simple button inside a login form.
<input data-disable-with="Signing in, please wait…"
name="commit" type="submit" value="Sign in" />
I'm writing a largely pointless test :-) in a Rails 3.2.17 application that's just to get the hang of Capybara and I've already got completely stuck Googling, reading documentation and reading source code to the test framework, with no joy - attempting to find this button by its name (i.e. "commit") fails.
click_button("commit")
find_button("commit")
Both result in Capybara::ElementNotFound: Unable to find button "commit". If I use the visible button text of Sign in then the element is found, i.e. these:
click_button("Sign in")
find_button("Sign in")
...both work fine, so it would appear that the XML parser isn't having any trouble finding the element.
Documentation for click_button says that the locator works on "id, text or value", with "text" being meaningless for an input element like this (the visible text is taken from the value attribute), but relevant perhaps for button elements. So, we might expect that to fail, though if we view the code via the documentation, find that it calls down to find in the same way as find_button. Yet find_button is documented differently; it says it locates by "id, name or value". So sadly, we know from this that the documentation is broken because it says two different things for what turns out to be an identical call at the back end.
Either way, the element isn't found by name, and that means the lower level find call isn't searching name attributes as far as I can see. This means Capybara (2.2.1, on Nokogiri 1.6.1) is rather broken in that respect. How come nobody has noticed? I've Googled for ages and it doesn't seem to come up. I seem to be rather missing the point :-)
Why don't I just search for the English text in the button, you might ask? Because of internationalisation. This old, Rails 1 -> 2 -> 3 upgraded app has some I18n parts and other static text parts. I don't want to be forced to put I18n into any view that Capybara tests, just so I can have the test use I18n.t() to ensure a match despite different languages or locale file updates. Likewise, it would clearly be very stupid in 2014 to write hard-coded English strings into my tests.
That's why we have names and IDs and such... The unique (in theory!) identifiers that are machine-read, not human-read.
I could hack up something that CSS-selected by "type=submit" but seriously, why isn't Capybara searching the name attribute when its documentation says it does, and why does the documentation disagree on what attributes are searched on two methods that call down to exactly the same back-end implementation with exactly the same parameters?
TIA :)
It turns out the docs are misleading for both calls, as neither look at the attributes listed. It's also clearly very confusing what exactly a "button" means, since a couple of people herein seemed to think it literally only meant an HTML button element but that's not the case.
If you view the source for the documentation of, say, click_button:
https://github.com/jnicklas/capybara/blob/a94dfbc4d07dcfe53bbea334f7f47f584737a0c0/lib/capybara/node/actions.rb#L36
...you will see that this just calls (as I've mentioned elsewhere) to find with a type of :button, which in turn passes through to Capybara's Query engine which, in turn, ends up just using the standard internal selection mechanism to find things. It's quite elegant; in the same way that an external client can add their own custom selectors to making finding things more convenient:
http://rubydoc.info/github/jnicklas/capybara/master/Capybara#add_selector-class_method
...so Capybara adds its own selectors internally, including, importantly, :button:
https://github.com/jnicklas/capybara/blob/a94dfbc4d07dcfe53bbea334f7f47f584737a0c0/lib/capybara/selector.rb#L133
It's not done by any special case magic, just some predefined custom selectors. Thus, if you've been wondering what custom selectors are available from the get-go in Capybara, that's the file to read (it's probably buried in the docs too but I've not found the list myself yet).
Here, we see that the button code is actually calling XPath::HTML.button, which is a different chunk of code in a different repository, with this documentation:
http://rdoc.info/github/jnicklas/xpath/XPath/HTML#button-instance_method
...which is at the time of writing slightly out of date with respect to the code, since the code shows quite a lot more stuff being recognised, including input types of reset and button (i.e. <input type="button"...> rather than <button...>...</button>, though the latter is also included of course).
https://github.com/jnicklas/xpath/blob/59badfa50d645ac64c70fc6a0c2f7fe826999a1f/lib/xpath/html.rb#L22
We can also see in this code that the finder method really only finds by id, value and title - i.e. not by "text" and not by name either.
So assuming XPath is behaving as intended, though it's not clear from docs, we can see that Capybara isn't documenting itself correctly but probably ought to make the link down to XPath APIs for more information, to avoid the current duplication of information and the problems this can cause for both maintainers and API clients.
In the mean time, I've filed this issue:
https://github.com/jnicklas/capybara/issues/1267
You can also use css selectors which are default capybara locators. People say they are faster.
find('[name=commit]').click
Capybara do not look at name attribute in it's finders :(
You can use xpath selector if you want
find(:xpath, "//input[contains(#name, 'commit')]").click()
If anyone wants it is possible to add (quite easily) find by name selector. In order to do so:
Add following code to test/test_helper.rb (for minitest)
Capybara.add_selector(:name) do
xpath { |name| XPath.descendant[XPath.attr(:name).contains(name)] }
end
Use it
Now in your tests you can use following selector:
find(:name, 'part_of_the_name_attribute')
It will find every element which name attribute contains searched value.
Example
find(:name, 'user')
This will find elements (element could be of any type):
<select name='user_name'>
<input name='name_of_user'>
<textarea name='some_user_info'>
You can use this selector to find a button on a page with RSpec and Capybara:
expect(page).to have_selector(:link_or_button, "Button text")
Check your gem depencies. RSpec 3 or higher works with gem 'rspec-rails', '~> 3.7.1' then capybara version must be gem 'capybara', '~>2.18.0' and poltergeist should be gem 'poltergeist', '~>1.17.0'.