Which is correct way to pick elements from HTML : pick up all ids on a page together or picking each ID individually?
Let me explain the scenario.
I have a HTML page with information associated to specific IDs, but IDs sometimes change according to the section they are being displayed into.
Now which approach is better, either to pick the all the ID's from the page and then adding checks to get the value or picking up of separate ID individually.
I also need to work with many IDs (20 out of 100) on the page at same time.
Please suggests.
Thanks
If an element is static, in that it will not change throughout the course of your test then there is no problem selecting it at the beginning. However i definetly feel that attempting to select all your elements at the beginnning is a bad idea. What happens if an element is not available until you have completed some action, NoSuchElementException. Or what about if you select an element and when you go to use it the element cant be found, StaleElementException.
So you definetly need to find a balance and select your elements at the aprropriate time. I saw some other suggestion above to use xpath as it will never change, again thats not true.It is also recommended in the documentation to first attempt to select by id and then name. Im sure there are alot of reasons for this but one that immediatley comes to mind is readibility, speed is also a factor.
Related
I am having a dilema. I need to fetch data for some products by Id, these products which are selected can vary from a couple to thousands.
I see and tested that GET is not possible due to exceeding the HeaderSizeLimit of 8192.
I had discussions with colleagues and changed to POST and the ids are in the body. Everything works but have a lot of discussions about this. Have you encountered something like this? What was your approach?
First question for me is, do you really pass all those ids in a single request? How is this list of IDs generated in the first place? Could the server know this list in advance?
For example, if the list of IDs is obtained by doing a search query on the same server, perhaps that search query can already emit the list of entities.
I find that in most cases this can be avoided, but there's some exceptions.
If you find that you can't avoid this, I would suggest you use the new http QUERY method instead of of POST, but POST should be fine too as a fallback.
An XPage is used to display the number of points a person has collected, and the number of points remaining (see below).
I have a repeat control which gets a collection of documents meeting a specific criteria. The last column in the control contains 5 digit/form/comboboxes, which are displayed or hidden, according to the number of fields on each document that contain data.
The layout contains gift cards worth a certain amount of points, and the person can select how many of each gift card they want. eg.
Company Available in Values of Points Required Quantity Requested
The Quantity Requested column contains the digit/form/comboboxes. As the person selects values in the checkbox, I want the number of points remaining to be recalculated.
The onChange event of the digit/form/comboboxes calls a function in an Output Script which calls an RPC, which in turn calls an SSJS function. The SSJS function cycles through the documents displayed in the repeat control, gathering the points required information. I then wanted it to also grab the Quantity Requested. I understand from a previous posting that because of the way the digit/form/combox is rendered, I can only get the value using CSJS with dijit.byId and perhaps putting the value in a hidden field and retrieving it from there.
I can't seem to wrap my head around how I will do this when the repeat control will make it possible for there to be many combobox1 and combobox2, etc.
The XPage is not bound to a form, because all the items are just calculated on the fly and then discarded.
What is the best way to do this?
The JSON RPC service can't interact with any changes made in the browser, see https://www.intec.co.uk/json-rpc-service-component-tree-manipulation-openlog/. This could be the cause of your problems.
You may be able to get around it by triggering a partial refresh (POST) before calling the JSON RPC. In theory that might work, because the component tree (server-side map of the XPage) would get updated by the partialRefreshPost and the updates picked up by the JSON RPC. It's possible though that the Restore View picks up a version of the XPage other than the one for the browser, I don't know. I've never investigated that.
It's been a while since I've worked with server java script, I have been doing it the managed bean way with ActionListeners. If you have the data in the UI, then can you avoid server side processing and do it client side?
You can also use the DOM XSP Object like XSP.setSubmittedValue to have a key value pair sent with your post request to the server side, you can only have one... it can be JSON or any other value you set it to from the client side javascript.
I figured out how to do this. If anyone wants the code, let me know and I'll provide it.
Yesterday I went to add pagination to a chat service. I've implemented pagination a hundred times before using either page/per_page or start/end arguments, and I've always been aware that there is the potential for the order or offsets to change between page loads, but in the case of this chat service, that is much more likely to happen. My first approach was to use the updated_at column and have subsequent requests just pass something like "updated_after" but in this case, we often import multiple rooms at once that could easily have the same updated_at (down to the millisecond) for the same user.
One solution I found was to use an update count, or index that gets incremented (table wide) each time a row is updated. I've implemented it using a postgres SEQUENCE column that I set it to nextval('room_update_count') each time the room is updated (this could be a trigger but I wanted more control). Then I can just sort on that column and use a simple update_index < $next to get the following page.
However, I haven't been able to find any references to any technique like this. It seems to work perfectly but I'm skeptical that I'm not seeing some issue with it. I feel like I can't be the first person to come up with this idea, and that if I could just think of the correct name for it I would find other examples of it.
Is this a known technique? What are other ways to solve the pagination offset issue?
I have a list of 35,000 names of companies. I need to perform an internet search and return the first result . I would like to automate the process. I was orginally thinking about using IE automation in excel. However, I am not sure if there is a better approach. I need to google search the company's name and return the URL of the first result. If the results could be in excel, that would be great as the list is in excel. Any thoughts?
You can automate IE to perform the search. Normally, a delay is set up to keep checking if the page is loaded. I suggested recently that a better alternative is to keep trying to reference the first H3 element in the page, and read it's contained A-tags' href attribute. If this succeeds then Stop navigating the page, or navigate to the next page.
There is a slight catch with this approach though, as the H3 is often a sponsored-link. It is possible to determine this though, and so find a link further down.
The whole process will still take an age though.
Alternatively, there is the Google Search API but you'll have to pay for more then 100 searches per day.
Feel free to edit the title if you know how to formulate the question better. (Tagging is a problem as well.) The problem may be too difficult in this general form, so let us consider a concrete example.
You get a screenful of stackoverflow questions by requesting /questions ?sort=newest page. Next page link leads to /questions?page=2 &sort=newest. I suppose that at server side, the request is translated into an SQL query with LIMIT clause. Problem with this approach is, that if new question were added while user browses first page, his second page will start with some questions he already saw. (If he has 10 question per page, and 10 new questions happened to be added, he’ll get exactly the same content second time!)
Is there an elegant way to solve this common problem? I realize that it is not that big a problem, at least not for stackoverflow, but still.
The best idea I have (apart from storing request history per client) is to use /questions?answer_id=NNN format. Server returns a page that starts with the requested answer, and puts the id of the first answer on the next page into next page link. There must be a way to write SQL for that, right?
Is it how it usually done? Or there is a better way?
This can't be done an easy way. For instance, the "Unanswered" list here at stackoverflow is sorted by number of votes. So if you'd save the last ID of the page you're viewing (in a cookie, request, session, whereever) and someone upvotes a post while you're browsing page 2, page 3 isn't complete since the recently upvoted post could have been moved to page 1 or 2.
Only way to do it is to load the complete list in someones session. Please don't...
As already mentioned, let's hope people are used to this by now.
Most web sites I've seen don't solve this problem - they show you a page including some content you've already seen.
You might consider that a feature - when you click "next" and see some content you're seen before, it's a signal that you want to go back to the front again because there's some new content.
Tag each question with its time entered into the database, carry the time the frontpage was last loaded as a cookie or part of the URL, and limit the search to items n through n+displaynum as you go forward.
But I wouldn't bother. This behavior is uniform enough that most users expect it, and it serves as a flag for when new data is becoming available. You can even open a new tab/window that starts back at the top of the list to see what has come up.
I believe the SQL (for MySQL) would be:
SELECT *
FROM entries
WHERE entry_id >= #last_viewed_entry_id
ORDER BY entry_id
LIMIT 50