I have a div in which I'm putting some items (as spans). If there are too many items, I would like a "more" link to appear, otherwise- no link.
Problem is the div's width is dynamic (it's about 20% of the page - which means I can't tell how wide exactly it is).
Question is - how to determine (preferably on client side, but might be on server side as well) if there are too many items - and instead of displaying the extra items - displaying a "more" link.
For example here there are 2 extra items, which should not be displayed at first, but only after the user will click the "more" link (which still doesn't exist).
I'm not mentioning my server side language because if the problem can be solved only on server side, just a general description will be enough.
Thanks.
First of all, embedded styles in HTML? Eww!! Use CSS files and class attributes.
Secondly, you should use <UL> for lists, as it seems you are trying to build a list.
To answer your question, you can easily do this with jQuery (if set an ID on your DIV):
var maxCount = 3;
if ($('#myDiv').find('SPAN').length > maxCount)
{
//over max, so hide something.
}
But really it should be more like (where myList is an ID of an unordered list):
var maxCount = 3;
if ($('#myList').children().length > maxCount)
{
//over max, so hide something.
}
This is a pretty common feature. Here's a jQuery plug-in called lessMore to do it. You would call it like so:
$('#content').lessMore({
limit: 5,
numbers: false
});
Using an existing plug-in is better for code-reuse and you avoid re-inventing the wheel.
Related
Learning 'capybara' and bumped into issue of finding the hidden elements through capybara.
In HTML, we have an file field which is 'display: none' by default. HTML element is:
<input class="some_class" id="some_id" name="some_name" type="file">
Now, while I was writing the test cases in capybara using cucumber, I could not find this element in my capybara script. My capybara script is finding the element just like this :
find(:xpath, "//input[#name='some_name']")
Read about the hidden elements and go to know that setting
Capybara.ignore_hidden_elements = false
should solve my problem. But I read somewhere else that above setting is by default. So, tried other option of passing it explicitly. Like:
find(:xpath, "//input[#name='some_name']", :visible => false)
That did not work too. Is there anything else I should try? Will be happy to share more details in case anyone is interested.
The visible option has a few potential values
true or :visible => finds only visible elements
false or :all => finds visible and non-visible elements
:hidden => only find non-visible elements
Therefore if your attempt of find(:xpath, "//input[#name='some_name']", :visible => false) isn't returning an element, there is no element matching that XPath in the page and you need to check that the contents of the page is what you think it is (page.html, page.save_screenshot, etc)
Beyond that your example has a few issues. Firstly, you're falling into the XPath // trap. If (and it should be a big if) you're going to be using XPath queries a lot for finding your elements, get used to starting your queries with .// rather than just // - if you don't you are defeating all of Capybara's scoping on the page (within, chained find, etc). Using CSS selectors doesn't have that issue so makes more sense for most queries where you're not using one of Capybara's built-in selector types.
find("input[name='some_name']", visible: false)
Knowing we are looking for a file input we can go one better by using Capybara's built-in file_field selector and doing
find(:file_field, 'some_name', visible: false)
which is easier to read and explains exactly what you're looking for. Next, since you're finding a file field I assume you'll want to actually add a file to it. This can be problematic since non-visible elements can't generally be interacted with. However since file fields are so often hidden, to allow for styling, there is an option to help with that.
attach_file('some_name', file_path, make_visible: true)
The make_visible: true option will temporarily change the elements CSS to make it visible (you can set it to a hash of CSS values to set rather than true if the default CSS doesn't work on your page), attach the file to it, and then revert the CSS changes.
As a final point, setting Capybara.ignore_hidden_elements = false is a terrible idea if you're testing an app (if just doing automation it's fine) since it leads to tests that aren't actually testing what a user can see/do.
I am trying to build out a harness for a page so that we can write tests against it. What I would like to be able to do is use a CSS selector to find the given element or elements instead of manually modifying the SearchProperties or FilterProperties.For a web test the CSS Selector seems far more intuitive then the SearchProperties do. Is there some mechanism for doing this that I am simply not seeing?
Try this...
https://github.com/rpearsondev/CodedUI.jQueryExtensions/
It adds extension methods to the BrowserWindow object...
var example1 = browser.JQuerySelect<HtmlHyperlink>('a.class1');
var example2 = browser.JQuerySelect<HtmlListItem>('li.class2');
However, I will let you know I'm having issues with it complaining about casting errors regularly.
Try browserWindow.executeJavascript if you return a control you found via css/xpath it returns the relevant uiControl object
const string javascript = "document.querySelector('{0}');";
var bw = BrowserWindow.Launch(new Uri("http://rawstack.azurewebsites.net"));
string selector = "[ng-model='filterOptions.filterText']";
var control = bw.ExecuteScript(string.Format(javascript,selector));
HtmlEdit filter= control as HtmlEdit;
filter.Text = "Alien";
As sjdirect noted, the jQuery extensions are probably the way to go if you want to use those type of selectors.
However, it seems that you may be interested in some abstraction that doesn't require directly setting search / filter properties on the UITestControl objects.
There are good abstractions that do not use the same selectors as jQuery, but provide a readable, consistent approach for finding elements in the page and interacting with them.
I would recommend also looking into Code First and CodedUI Fluent (I wrote the fluent extensions) or even CodedUI Enhanced (CUITe).
These provide query support for that looks like (from CUITe):
// Launch the web browser and navigate to the homepage
BrowserWindowUnderTest browserWindow = BrowserWindowUnderTest.Launch("https://website.com");
// Enter the first name
browserWindow.Find<HtmlEdit>(By.Id("FirstName")).Text = "John";
// Enter the last name
browserWindow.Find<HtmlPassword>(By.Id("LastName")).Text ="Doe";
// Click the Save button
browserWindow.Find<HtmlInputButton>(By.Id("Save")).Click();
I have a HTML document where the body contains dozens of divs, all listed sequentially. (It's a layout of small screenshots.)
The appearance and layout of each div is handled by CSS.
I wish to selectively hide some divs, depending on some state values. A javascript function "hideSomeDivs()" has been create to do this. (The function iterates over all divs, setting each element's style.display property to "none" as required.)
The problem: calling hideSomeDivs() function from will be too late: the page is already loaded and the visual changes will not be displayed. The original layout is maintained.
Q. how/where can I call this function such that the affected divs will be hidden, and all layout adjusted accordingly? Thanks.
Further information:
apart from javascript interactivity, the page is static (i.e. there's no server-side processing available).
also, I'm trying to avoid any "pop" where elements are shown/hidden after the page is loaded and drawn to the window.
also, I need for the layout to be re-evaluated and re-drawn. e.g. if I hide divs 1 to 4, but show div 5, then div 5 should appear at the top of the page.
Think about it the other way round - hide all your divs by default, and then use the javascript to show them as needed.
Of course you could just eliminate the need for the javascript if you have a server side language (i.e. PHP, ASP.NET) that is constructing the page, then you can just set their hidden state correctly to begin with.
In your HTML code put in a style code that hides the div by default. This will be evaluated much earlier than the Javascript.
Do you possibly want to maybe call the "hideSomeDivs()" function on the onload event of the body element.
Is there a way to dynamically change the hyperlink associated with an ECB menu in WSS 3.0? For instance, I have a list with 2 fields. One field is hidden and is a link, the other is the title field which has the ECB menu. The title field currently links to the item's view page - but we want it to link to the link-field's url. Is that possible?
UPDATE - 5/29/09 9AM
I have this so far. See this TechNet post.
<script type="text/javascript">
var url = 'GoTo.aspx?ListTitle='+ctx.ListTitle;
url += '&ListName='+ctx.listName;
url += '&ListTemplate='+ctx.listTemplate;
url += '&listBaseType='+ctx.listBaseType;
url += '&view='+ctx.view;
url += '&';
var a = document.getElementsByTagName('a');
for(i=0;i<=a.length -1;i++)
{
a[i].href=a[i].href.replace('DispForm.aspx?',url);
}
</script>
This gives me a link like so (formatted so it's easier to see):
GoTo.aspx
?ListTitle=MyList
&ListName={082BB11C-1941-4906-AAE9-5F2EBFBF052B}
&ListTemplate=100
&listBaseType=0
&view={9ABE2B07-2B47-4390-9969-258F00E0812C}
&ID=1
My issue now is that the row in the grid gives each item the ID property above but if I change the view or do any filtering you can see that the ID is really just the row number. Can I get the actual item's GUID here?
If I can get the item's ID I can send it with the list ID to an application page that will get the right URL from field in the list and forward the user on to the right site.
I think the easiest solution and one I use regularly to modify default sharepoint functionality without having to install server side code is to inject some javascript onto the page to make the necessary modifications.
The Content Editor webpart is ideal for this if you don't want to edit the page source itself. Together with the IE Developer Toolbar or Firebug to inspect the elements you want to edit you should be able to achieve what you need with just a couple of lines of javascript.
Let me know if you need any further detail on getting this work.
The title/link to edit menu is a computed field - basically a combination of the title and item id. If you look at the definition of the field (off the top of my head I think it's in fields.xml) you should be able to create a modified version in your schema.xml that uses the url field in its RenderPattern.
Following up on Tom's answer, you can use the SharePoint Solution Generator in VseWss 1.3 to generate a Visual Studio solution that can re-create your list. You will faint when you see the huge amount of XML that the views use in the schema.xml file but you will see the render pattern that Tom referred to and you should be able to get a general idea of how to modify it to suit your needs.
Gotta love SharePoint. Where small customizations means "take what I give you or rewrite it from scratch"
At the top of many pages in our web application we have error messages and notifications, 'Save' and other buttons, and then our h1 tag with the content title. When making a web application accessible, is it ever acceptable to have content above the top-level structure tag like we do here?
As a screen reader user I don't like content above the main heading. Normally I navigate by headings so would miss the error message. A better solution is to output an h1 heading above the error message, then leave the rest of your headings in tact giving you two h1 headings.
Yes (you can put stuff above them). The H simply means Heading. It's a question of what the heading relates to I guess.
My only caveat is, H2 shouldn't really be above H1, and H3 Shouldn't be above H2. But I don't think it's an actual rule.Websites have menus, warning, notifications. It's acceptable to put them above the rest of your content. I don't see how it would affect accessibility as long as your content is ordered logically. Look at the page CSS turned off. Does it look logical? That's the most important part of accessibility.
Although some people do go that extra mile and have the menu as the last item in the markup and use CSS to bring it back to the top. Personally, I find that solution counter productive. The menu is still important, it belongs at the top of the page.
Yes, just consider it is in that order that the user will get the information. So, if you just did an operation it sounds like a good idea to get any message related to it as the first thing. If it is a notification that appears on any page unrelated to what you are doing, I wouldn't put it above, as it might be a little weird.
Also you can use a text browser that doesn't use styles, it should look like a document with appropriate headers.
Heading tags are used to indicate the hierarchy of the content below it. You should only have one h1 tag and it should be the first content to appear on your page (this is usually the name of the site). Also, you shouldn't skip heading tags when drilling down through different tiers of content.
In your case, you can still use CSS to position items above the h1 tag as long as it is in the correct order in the html.
I assume the elements above the heading are used by JavaScript. In that case, it's preferable if they are created by JavaScript, not included in the source of the page.
To return to your original question, it is probably best that they be at the foot of the page. However, if they are hidden using the CSS "display: none;" or "visibility: hidden;" properties then they will not be seen by most (perhaps all?) screenreaders or by many other assistive technologies, and so should not be an issue. I've written a fairly detailed explanation of why accessibility technology ignores such elements.
Of course if somebody disables CSS things are going to look pretty messy. If there is content on the page that can be used even when CSS and/or JavaScript are disabled, then putting those elements at the bottom of the page will at least make things less cluttered.