For quite a long time I use proxy servlet, and from my experience in order for javascript to properly work, the proxy servlet has to be configured to run in the ROOT context. However, a site http://www.filestube.com/ from what I investigated, its running a site from another domain on a iframe.
I am wondering what kind of approach is this?
From what I can see on the target page it loads javascript from some 'local' domains (*.filestube.com) who then in turn load javascript from another domain (e.G. google or facebook in this case).
Also there is an IFrame on the site, but IFrames may come from everywhere anyway.
So the kind of approach is: Normal, don't think about user privacy and just load everything you think you might need from everywhere.
Related
My GWT app URL when a page is access looks like this:
http://127.0.0.1:8888/index.html?gwt.codesvr=127.0.0.1:9997#ViewPage;hash=6a
or
http://127.0.0.1:8888/index.html#ViewPage;hash=6a
However, this does not look good, is there a way for the GWT client side code to make it look like this, to "mask" it somehow to:
http://127.0.0.1:8888/6a
Where I have a servlet configured to forward this "shortened" URL to the long URL above so its very safe to make the URL "masked"? Without losing state and history.
The shortest possibility I know would be an URL like:
http://127.0.0.1:8888/#6a
Therefore you must configure index.html as default page. (It must be configured as default response).
You also have to rewrite the history-management. You have to remove the Place-Token from the URL.
I don't see any way to do this directly with GWT, since GWT needs access to the code fragment in the URL to manage browsing history and state.
One indirect way to do it would be to embed your GWT module inside an iframe that occupies the whole page area. The drawback is that the user would loose the ability to bookmark pages inside the GWT application.
By the way, I don't share your view that it "does not look good". Many popular Web applications use the URL like this, including Gmail. Most users don't care about what's in the URL.
We have a set of web apps and want to identify if they have a Java client-side dependency i.e. if they invoke the client installed JRE.
Is there an easy way to do this? or do we have to manually scan the code for or anything else that may have a Java client dependency?
Thanks.
No, there is no easy way to do this.
It would be easy if all your web-apps would use a <applet> html tag or a <object> html tag, then you could simply match every html source. This you can do anyway to find some of the web-apps that use java, at least on the start page of the app.
But since it is also possible to load java applets using javascript and an automatism cannot navigate through an app like a user, there is no easy way to do this.
If you have control over the clients (e.g. company internal), you might turn off java on a few clients and let the users do the checking (e.g. they will call if something does not work). Maybe you even have key users for application tests.
I am about to start a totally new web project.
The project need to have different small window, which contain html generated from other web site.
One important requirement is when user submit a form in the window, NO refresh should be invoked on the other window.
My leader say let's look into jsr286 portlet (coz portlet sounds like window?). But after look into some example (pluto portal/jetspeed2), none of them support the requirement, whenever a window is submit, whole page is submitted.
My rough idea is to use iframe in each window, and let the iframe does the rest (like ref to external website, handle form submission).
Personally, I don't think iframe fit quite well into the portlet jsr286. And most of the window has nothing to do with each other, so processEvent is not compulsory.
So my questions is:
for a new project with such requirement (separate form submission), does it worth it to confirm to portlet jsr286?
If it does, how does the iframe works with different portlet modes(VIEW/EDIT/HELP) or window state(MAX/NORMAL/MIN)?
Thank you very much!
there's a good explanation here that you can point your team leader to. it says:
Mashups and portals are both content aggregation technologies. Portals are an older technology designed as an extension to traditional dynamic Web applications, in which the process of converting data content into marked-up Web pages is split into two phases: generation of markup "fragments" and aggregation of the fragments into pages. Each markup fragment is generated by a "portlet", and the portal combines them into a single Web page. Portlets may be hosted locally on the portal server or remotely on a separate server.
and, critically:
Portal technology is about server-side, presentation-tier aggregation.
so aggregation is done on the portal server (even when the portlet servers are separate - this is all driven by the need to make the server side scalable on big sites; it's not about clients combining from multiple sources). and that's why submission refreshes the whole page (because it has to load the new page from the portal).
which should help clear things up, since it sounds like what you are looking for is client-side aggregation (i don't think i'm telling you anything new here, but i'm giving you references in "enterprise speak" that might sound more convincing).
(so, just in case it's not clear, your requirements sound like you need a client-side mashup. portlets won't work because they are assembled server-side. iframes would work, but have some limitations (size, rescale, style / dynamic changes). i was going to suggest combining things on the client using javascript with backbone, but i am worried you'll have issues with pulling data from different sites because of the restrictions on what javascript from within a web page can access. looks like this article would be worth reading...)
I have developed a Java applet which opens a URL connection to some different server. The applet then retrieves contents of the HTML page and do some processing and then shows to user. Can I cross-compile it to JavaScript using GWT?
Cross compile: No.
Port: Probably. Depends on your constraints.
You won't be able to do a straight recompile and have it "just work" (GWT only supports a subset of the JRE and any UI stuff definitely isn't a part of it) but you might be able to port some of your logic over. If you're using XPath to pull content out of the page, that code most likely will need to be redone as well. There's a GWT wrapper for Sarissa that works pretty well.
Also, since the requested page is going to be on a different server, you'll need to set up some method of doing a cross site request. So either browser hacks or a proxy on the hosting server.
I need to screen scrape some data from a website, because it isn't available via their web service. When I've needed to do this previously, I've written the Java code myself using Apache's HTTP client library to make the relevant HTTP calls to download the data. I figured out the relevant calls I needed to make by clicking through the relevant screens in a browser while using the Charles web proxy to log the corresponding HTTP calls.
As you can imagine this is a fairly tedious process, and I'm wodering if there's a tool that can actually generate the Java code that corresponds to a browser session. I expect the generated code wouldn't be as pretty as code written manually, but I could always tidy it up afterwards. Does anyone know if such a tool exists? Selenium is one possibility I'm aware of, though I'm not sure if it supports this exact use case.
Thanks,
Don
I would also add +1 for HtmlUnit since its functionality is very powerful: if you are needing behaviour 'as though a real browser was scraping and using the page' that's definitely the best option available. HtmlUnit executes (if you want it to) the Javascript in the page.
It currently has full featured support for all the main Javascript libraries and will execute JS code using them. Corresponding with that you can get handles to the Javascript objects in page programmatically within your test.
If however the scope of what you are trying to do is less, more along the lines of reading some of the HTML elements and where you dont much care about Javascript, then using NekoHTML should suffice. Its similar to JDom giving programmatic - rather than XPath - access to the tree. You would probably need to use Apache's HttpClient to retrieve pages.
The manageability.org blog has an entry which lists a whole bunch of web page scraping tools for Java. However, I do not seem to be able to reach it right now, but I did find a text only representation in Google's cache here.
You should take a look at HtmlUnit - it was designed for testing websites but works great for screen scraping and navigating through multiple pages. It takes care of cookies and other session-related stuff.
I would say I personally like to use HtmlUnit and Selenium as my 2 favorite tools for Screen Scraping.
A tool called The Grinder allows you to script a session to a site by going through its proxy. The output is Python (runnable in Jython).