Is it possible with IIS to serve a .php page, but that can also host asp.net control?
Like a two-pass parsing, the first pass parse the php, then the asp.net parser transform the controls.
The variable declared on each layer do not need to be shared.
Is it possible or is it a sin?
Ultra hack and untested... but maybe....
Use output buffering and have a PHP script that generates your control. Then, save the output to a file (with a unique name) and file_get_contents() to evaluate the ASPX file.
Regardless of whether or not ZenGeneral's creative hack works, its a sin and really, just don't go there!
Possible, but not recommended.
Pick one or the other.
In worse case scenario, you could use a php curl to grab the aspx or even (GRASP!) an iframe.
It puts a lot of unnecessary strain on the server, because it has to get the php file, parse it, then get the aspx file, parse it, then send it to php (or php grabs it), then renders the rest of the php file once the request goes through. It also would make the load times slower.
Related
First of all, I know that you can't convert a PHP file to HTML due to PHPs nature. So what I rather want to do is have a script run through and scrape all the pages and save them down correspondingly (eg. /help/how-to-stackoverflow should become /help/how-to-stackoverflow.html).
The site I want to convert doesn't use dynamic server-side logic, meaning that no matter who you are, the same URL always gives you the same result and there's nothing going on behind the scenes. It also doesn't use parameters and such.
If possible, the process should be easy to integrate into automation (aka be a command to run), however, this is not a requirement.
So, what is the best way to do that without going through and exporting every page manually?
I am currently trying to load an HTML page via cURL. I can retrieve the HTML content, but part is loaded later via scripting (AJAX POST). I can not recover the HTML part (this is a table).
Is it possible to load a page entirely?
Thank you for your answers
No, you cannot do this.
CURL does nothing more than download a file from a URL -- it doesn't care whether it's HTML, Javascript, and image, a spreadsheet, or any other arbitrary data; it just downloads. It doesn't run anything or parse anything or display anything, it just downloads.
You are asking for something more than that. You need to download, parse the result as HTML, then run some Javascript that downloads something else, then run more Javascript that parses that result into more HTML and inserts it into the original HTML.
What you're basically looking for is a full-blown web browser, not CURL.
Since your goal involves "running some Javascript code", it should be fairly clear that it is not acheivable without having a Javascript interpreter available. This means that it is obviously not going to work inside of a PHP program (*). You're going to need to move beyond PHP. You're going to need a browser.
The solution I'd suggest is to use a very specialised browser called PhantomJS. This is actually a full Webkit browser, but without a user interface. It's specifically designed for automated testing of websites and other similar tasks. Your requirement fits it pretty well: write a script to get PhantomJS to open your URL, wait for the table to finish rendering, and grab the finished HTML code.
You'll need to install PhantomJS on your server, and then use a library like this one to control it from your PHP code.
I hope that helps.
(*) yes, I'm aware of the PHP extension that provides a JS interpreter inside of PHP, and it would provide a way to solve the problem, but it's experimental, unfinished, would be still difficult to implement as a solution, and I don't think it's a particularly good idea anyway, so let's not consider it for the purposes of this answer.
No, the only way you can do that is if you make a separate curl request to ajax request and put the two results together afterwards.
I'd like to create an RPG in JavaScript. The RPG will have a lot of dialog in it. I have heard XML is the way to go..., but I have no experience using XML, and a good amount of experience with PHP and MySQL.
My questions are:
Would it be better to store dialog in a MySQL database and access it with PHP using IDs? Or should I just keep it all on the front end by accessing XML files with Javascript?
If I use XML, do I need to run the javascript on a webserver (Like WAMP)? Or can I parse it locally with:
function parseXML() {
xmlhttp=new window.XMLHttpRequest();
xmlhttp.open("GET","dialog.xml",false);
xmlhttp.send();
xmlDoc=xmlhttp.responseXML;
}
(Which is currently giving the error XMLHttpRequest cannot load file:///C:/Users... Cross origin requests are only supported for HTTP.
Even after reading up on XML, I'm still not sure how I can integrate it with JavaScript. Can someone help give me an example of how I could take a sample rpg XML dialog and meaningfully parse it in JavaScript?
Thank you
Why don't you use JSON instead? It's much easier to use from JavaScript code. While you're at it, avoid usind XMLHttpRequest by hand and use some library that handles the bad stuff for you (e.g., jQuery).
For the "dialog" part, I'm not sure what you're gonna use MySQL for. Anyway, you can use any form of storage on the server side, provided that your PHP scripts give well-formed replies to the client side code.
Would it be better to store dialog in a MySQL database and access it
with PHP using IDs? Or should I just keep it all on the front end by
accessing XML files with Javascript?
The main advantage of having a database here is that you gain a lot of flexibility. You can create/edit/delete a piece of dialogue and its relations quite easily and without having to maintain/regenerate a huge data file every time (As you would do with a XML or JSON or w/e formalism you choose).
On the other hand, this solution might be overkill if you just have simple dialogues with no relations and limited content.
Since you are about to do a game in Javascript, and if your content is not changing that much, you can consider a JSON encoding for your dialogues. You could parse the data instantly via Javascript and still have the possibility to make all kind of complex relations between dialogues as you would in XML.
If I use XML, do I need to run the javascript on a webserver (Like WAMP)? Or can I parse it locally with: ...
You have this error because you indeed need to run a server here. If you just want to do some tests, no need to use WAMP or whatever big webserver, just run a python server for now and that will do the trick.
cd /yourProject
python -m SimpleHTTPServer
Let the server run and open your browser at:
http://127.0.0.1:8000
Give the input file a base url like http://localhost/rpgame/dialog.xml.
I am relatively new to web-development and am encountering an issue using some inline PHP code.
The page is a JavaServer Page (.jsp) and I am trying to implement a JFormer form.
When I add my JFormer PHP code to my .jsp page, it just displays as plain-text and refuses to cooperate with me (even when using demo code from the site's documentation). Is this because of some sort of incompatibility between using PHP on a .jsp page?
If that is the case, what are some work-around that I could use? Should I use an iframe?
I need to preserve the use of the .jsp page and would prefer very much to use JFormer, but if I have to I can toss it.
Example of something similar to what I am doing can be found at: http://www.jformer.com/documentation/getting-started/installation/
JSP and PHP are both server-side languages. As such, all scripting in a given file must be processed by the required engines on the server to produce the necessary HTML output.
I suppose it is possible to rig multiple engines inline to process first JSP, then PHP, but that seems cumbersome and error prone.
Instead, consider using an iframe (as you suggested) or load the PHP content via an AJAX call.
PHP is executed by a PHP interpreter and output HTML. JSP is compiled and executed by a Java VM, and output HTML. You can't execute PHP inside JSP code (and vice-versa). It's like if you put Chinese words inside an English speech. Nobody can understand.
I think the point of this is that the examples for jFormer use PHP for the server side logic. If you want to integrate jFormer into your JSP project, learn how to code the equivalent PHP functionality in JSP. You may need to create a Servlet for portions of the logic.
It looks like JFormer requires PHP so you can't make this work on a JSP page easily. You can rewrite the JFormer PHP code in Java/JSP but this may be a lot of work.
The container (like Tomcat) you're using may be able to run PHP scripts as CGI scripts. If you do this you can't easily share session information between PHP and Java. Javascript could be used to accomplish this, but beware of security issues. If you still want to use JSP you could make an iframe that points to the PHP page, as you said.
Here's an article on setting that up for Tomcat:
http://wiki.apache.org/tomcat/UsingPhp
Disclaimer: I don't know JFormer.
While cross-site scripting is generally regarded as negative, I've run into several situations where it's necessary.
I was recently working within the confines of a very limiting content management system. I needed to include database code within the page, but the hosting server didn't have anything usable available. I set up a couple bare-bones scripts on my own server, originally thinking that I could use AJAX to import the contents of my scripts directly into the template of the CMS (thus retaining dynamic images, menu items, CSS, etc.). I was wrong.
Due to the limitations of XMLHttpRequest objects, it's not possible to grab content from a different domain. So I thought iFrame - even though I'm not a fan of frames, I thought that I could create a frame that matched the width and height of the content so that it would appear native. Again, I was blocked by cross-site scripting "protections." While I could indeed load a remote file into the iFrame, I couldn't execute JavaScript to modify its size on either the host page or inside the loaded page.
In this particular scenario, I wasn't able to point a subdomain to my server. I also couldn't create a script on the CMS server that could proxy content from my server, so my last thought was to use a remote JavaScript.
A remote JavaScript works. It breaks when the user has JavaScript disabled, which is a downside; but it works. The "problem" I was having with using a remote JavaScript was that I had to use the JS function document.write() to output any content. Any output that isn't JS causes script errors. In addition to using document.write() for every line, you also have to ensure that the content is escaped - or else you end up with more script errors.
My solution was as follows:
My script received a GET parameter ("page") and then looked for the file ({$page}.php), and read the contents into a variable. However, I had to use awkward buffering techniques in order to actually execute the included scripts (for things like database interaction) then strip the final content of all line break characters (\n) followed by escaping all required characters. The end result is that my original script (which outputs JavaScript) accesses seemingly "standard" scripts on my server and converts their standard output to JavaScript for displaying within the CMS template.
While this solution works, it seems like there may be a better way to accomplish the same thing. What is the best way to make cross-site scripting work specifically for the purpose of including content from a completely different domain?
You've got three choices:
Create a server side proxy script.
Create a remote script to read in remote dynamic HTML. Use a library like jQuery to make this easier. You can use the load function to inject HTML where needed. EDIT What I originally meant for example # 2 was utilizing JSONP, which requires the server side script to recognize the "callback=?" param.
Use a client side Flash proxy and setup a crossdomain.xml file on your server's web root.
Personally, I would call to that other domain on the server and get and parse the data there for use in your page. That way you avoid any problems and you get the power of a server-side language/platform for getting and parsing the data.
Not sure if that would work for your specific scenario...hard to know even with your verbose description...
You could try easyXDM, by including very little code, you can pass data or method calls between documents of different domains.
I've come across that YDN server side proxy script before. It says it's built to work with Yahoo's Search APIs.
Will it work with any domain, if you simply trim the Yahoo API code out? Or do you need to replace it with the domain you want it to work with?
iframe remote content can be accessed by local javascript.
The remote server just have to set the document.domain of the page.
Eg:
Site A contain an iframe with src='Site B/home.php'
home.php looks like this :
[php stuff]...[/php]
[script type='text/javascript']document.domain='Site A'[/script]