I have some user tasks on the browser that I want to automate. These tasks involve page load/re-load. I am wondering if it is possible to write a javascript code using browser capabilities (like dev tool / local storage) to perform this.
Is it possible to write an extension to do that ?
My flow is the following :
Be on a page that has multiple listings of my own
Loop through each listing to modify it.
Modifying each listing involves
clicking on a button "Modify", which brings user to https://xxxxxx/ modify.
Then do a bunch of clicks on that page (easy).
Then click on confirm which bring user to another page https://xxxxxx/ modify/confirmation.
Please note I am not looking for solutions that involve automation frameworks like Puppeteer or Selinium. I need to have javascript code or chrome extension.
Looking forward for your help
searched the web for two weeks no solutions
First of all, I have a background in C (++), Java, MATLAB and Python, mainly used for scientific and electronic applications (Math operation on data, reading data from sensors, microcontrollers).
But i'm relatively new to both HTML (CSS) and Javascript.
For both I've read some books. In HTML books, multiple pages are done by links (<a></a>).
In javascript (which feels a lot more natural to me than HTML), I've seen some examples where there is only 1 html page, full of divs, who are shown and hiden each time a certain page needs to be shown.
This is done with the Jquery command $('#div1').hide() and $('#div2').show();
Now my question is, what is the best practice? When is it better to have multiple HTML pages, and when is it better to have just hide/show divs with Javascript?
Thanks
Not Every one Can Use Javascript. Not Every Computer Or Browser Has The Basics Of Java Installed. But Every Computer Can Read HTML every Browswer Can Read HTML.
To identify If a visitor is using java.
How to check whether Java plugins are installed or not in a browser using Code .?
Java is mostly installed now days with the browser some basic functions. But older navigator or IE browsers dont always have it installed by default.
More Info Here also
How can I detect the Java runtime installed on a client from an ASP .NET website?
The easiest is using <ul><li> css navigation themes. Check this site out for more info.
https://medialoot.com/blog/how-to-create-a-responsive-navigation-menu-using-only-css/
When you have multiple html pages and user clicks on links, then on each click a new web page has to be fetched from server and then rendered.
Whereas when you do it in java script the same web page will be altered, so there are no additional requests to the server. And this will be much faster than loading a new web page.
But remember the initial loading time is second approach is longer but its negligible.
Let me point out that there is no "best practice" to the question that you are asking. It is entirely up to the team if they want to push all the content in one page or keep them separately.
If in case you have a content that requires decent amount of images to be loaded, or contents that you are sure will rarely be seen, you might want to keep them in separate pages so as to make the page load faster.
If you have heavy contents which requires a lot of interaction with javascript/jQuery then you certainly might want to keep them in separate pages so that later when you want to debug/add to the code it can be easily done.
The vice versa of the above holds true as well.
If in case you just have small content, or simple text content then you can easily do it in a single page.
Maybe you should use a tab component ? bootstrap wraps one very nicely:
http://getbootstrap.com/javascript/
Maybe thats the best approach, also take a look at angular.js routes in specific, it should do what ever you are looking for.
I want to create an app which is able to inject a javascript script into a web page when the user clicks an item in the share menu (alternative methods of triggering the app to do this may also be ok).
I've found that adding an item into the share menu is pretty easy using the ACTION_SEND intent.
However, I've done a lot of googling and searching SO, but I can't seem to find any examples of people injecting scripts into an Android web browser, which is why I'm starting to doubt if this is possible.
Essentially, I have a bookmarklet which in injects javascript into whatever web page you're looking at. I want to build an app which does exactly the same as the bookmarklet does. Any alternative suggestions for achieving this would also be interesting to hear.
When building a social bookmarking button widget for usage in other websites there are a few challenges. We just recently opensourced the clientside aspects of this. (blog post here: http://www.mellowmorning.com/2010/08/03/creating-your-own-diggfacebook-liketweetmeme-button/)
Basically the goal is to replace the chosen elements
love it
With a button showing how many other people loved it.
There are two approaches to this.
- replace the A with html (script approach)
- replace the A with an iframe (iframe approach)
There are rather complicated differences between these approaches. One particularly annoying is the inability for the script approach to communicate with its popup.
Can anyone suggest a workaround to communicate between the login popup and the button. (IE. when you love something through the popup?, how do you update the count on the button, without being stopped by same origin protection..)
Which approach do you recommend. Iframe or Script and why?
These are the differences I encountered: Iframe vs Script
Iframe:
Popup communication possible
The script approach cannot communicate with popups it creates due to the same origin restrictions. The iframe however can be of the same domain as the popup and freely communicate. This gives a better user experience when for instance logging in.
Easier to develop
The iframe approach is easier to develop and requires less code.
Parallel download in IE
IE doesn’t download the count scripts in parallel, but it does do so for the IFRAMEs. Making this approach somewhat faster.
Independent CSS
External sites don’t interfere with your button’s css if you use an iframe technique. The disadvantage is that it makes things likes hovers impossible to integrate with the other site. (For example Fashiolista’s compact button).
Independent
The iframe approach makes it very hard for other sites to game the users like/love action. With a script approach a foreign site can simply call your javascript to fake someone loving the product. This freedom can be abused but also allows for mashups.
Script:
Slower dom load
Creating iframes takes a lot more time for the browser.
Slower perceived load
The script approach allows you to format the buttons before the data is loaded. Vastly increasing the perceived load speed.
No shared functionality
Buttons can’t share functionality. So when someone logs in for one button its is not possible to update the others.
There is of course a third option too, which is a hybrid between the iframe and the script approach.
You can use script to hook into the pages DOM (gives a loot of freedom with regards to different uses), and to create a hidden iframe pointing to your domain.
The script could communicate both with the current document, and with yours using Cross Domain Messaging and in turn with the popups using the iframe as a proxy.
Of course, the XDM does impose some difficulties, but if you use a proved solution like easyXDM, then it shouldn't be much of a problem.
Here is an example that shows how to interact with a popup.
Basically 2 questions
- Which is the best approach
- Workaround for the popup communication difficulties the script approach faces
Thanks for the popup information!
What is the underlying technology to support these cross domain popups?
If i understand your third option correctly:
- foreign site loading our js
- js replacing dom elements
- js opening hidden iframe to own domain
How do I then open a popup which still allows for communication with our js loaded into the foreign site? For that the popup would need to be instantiated by the iframe right? And we would need a method to communicate with the iframe. I thought im not allowed to do anything with the iframe except setting its window.location.href. Could you explain how that works?
Have you experimented with single page web application, i.e. where the browser only 'GETs' one page form the server, the rest being handled by client side javascript code (one good example of such an 'application page' is Gmail)?
What are some pro's and con's of going with this approach for simpler applications (such as blogs and CMSs)?
How do you go about designing such an application?
Edit: As mentioned in the response a difficuly is to handle the back button, the refresh button, bookmarking/copying url. The latter can be solved using location.hash, any clue about the remaining two issues?
I call these single page apps "long lived" apps.
For "simpler applications" as you put it it's terrible. Things that work OOTB for browsers all of a sudden need special care and attention:
the back button
the refresh button
bookmarking/copying url
Note I'm not saying you can't do these things with single-page apps, I'm saying you need to make the effort to build them into the app code. If you simply had different resources at different urls, these work with no additional developer effort.
Now, for complex apps like gmail, google maps, the benefits there are:
user-perceived responsiveness of the application can increase
the usability of the application may go up (eg scrollbars don't jump to the top on the new page when clicking on what the user thought was a small action)
no white screen flicker during the HTTP request->response
One concern with long-lived apps is memory leaks. Traditional sites that requests a new page for each user action have the added benefit that the browser discards the DOM and any unused objects to the degree that memory can be reclaimed. Newer browsers have different mechanisms for this, but lets take IE as an example. IE will require special care to clean up memory periodically during the lifetime of the long-lived app. This is made somewhat easier by libraries these days, but by no means is a triviality.
As with a lot of things, a hybrid approach is great. It allows you to leverage JavaScript for lazy-loading specific content while separating parts of the app by page/url.
One pro is that you get the full presentation power of JavaScript as opposed to non-JavaScript web sites where the browser may flicker between pages and similar minor nuisances. You may notice lower bandwidth use as well as a result of only handling with the immediately important parts that need to be refreshed instead of getting a full web page back from the server.
The major con behind this is the accessibility concern. Users without JavaScript (or those who choose to disable it) can't use your web site unless you do some serious server-side coding to determine what to respond with depending on whether the request was made using AJAX or not. Depending on what (server-side) web framework you use, this can be either easy or extremely tedious.
It is not considered a good idea in general to have a web site which relies completely on the user having JavaScript.
One major con, and a major complaint of websites that have taken AJAX perhaps a bit too far, is that you lose the ability to bookmark pages that are "deep" into the content of the site. When a user bookmarks the page they will always get the "front" page of the site, regardless of what content they were looking at when they made the bookmark.
Maybe you should check SproutCore (Apple Used it for MobileMe) or Cappuccino, these are Javascript frameworks to make exactly that, designing desktop-like interfaces that only fetch responses from the server via JSON or XML.
Using either for a blog won't be a good idea, but a well designed desktop-like blog admin area may be a joy to use.
The main reason to avoid it is that taken alone it's extremely search-unfriendly. That's fine for webapps like GMail that don't need to be publically searchable, but for your blogs and CMS-driven sites it would be a disaster.
You could of course create the simple HTML version and then progressive-enhance it, but making it work nicely in both versions at once could be a bunch of work.
I was creating exactly these kind of pages as webapps for the iPhone. My method was to really put everything in one huge index.html file and to hide or show certain content. This showing and hiding i.e. the navigation of the page, I control in a special javascript file where the necessary functions for handling the display of the parts in the page are.
Pro: Everything is loaded in the beginning and you don't need to request anything from the server anymore, e.g. "switching" content and performing actions is very fast.
Con: First, everything has to load... that can take its time, if you have a lot of content that has to be shown immediately.
Another issue is that in case when the connection goes down, the user will not really notice until he actually needs the server side. You can notice that in Gmail as well. (It sometimes can be a positive thing though).
Hope it helps! greets
Usually, you will take a framework like GWT, Echo2 or similar.
The advantage of this approach is that the application feels much more like a desktop app. When the server is fast enough, users won't notice the many little data packets that go back and forth. Also, loading a page from scratch is an expensive operation. If you just modify parts of it, the browser can keep a lot of the existing model in memory and just change the parts that changed.
Another advantage of these frameworks is that you can develop your application in pure Java. This means you can debug it in your IDE just like any other Java app, you can write unit tests and run them automatically, etc.
I'll add that on slower machines, a con is that a large amount of JavaScript will bring the browser to a screeching halt. Since all the rendering is done client-side, if the user doesn't have a higher-end computer, it will ruin the experience. My work computer is a P4 3.0GHZ with 2 GB of ram and JavaScript heavy sites cause it to chug along slower than molasses, which really kills the user experience for me.