That's a pretty vague question. Maybe you can give a little more detail on what you're trying to do and what kind of architecture you're working with. It's not even clear that you're really focused on Perl (but for the ".pl" extension.) Without more details, it's very hard to point you in a helpful direction.
For example, why do you need two servers? What is on each one? (e.g. linux/apache/mysql/perl?) Which one is the database on? Do you control both servers or are they run by third-parties? What kind of external access is available on each? Must script.pl be submitted to www.domain1.com or can it be submitted to www.domain2.com?
-xdg
Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.
| [reply] |
Thanks for the response xdg. To answer as briefly as I can: We control all servers. There are two servers because one is a public site (domain2 in my example.) The images need to live there. The other server is an internal development server. The "users" I described are using the development server, no public access. We're building them a web content interface so they'll stop posting crap conversions of Excel spreadsheets and Word docs. They can input text and pictures and our code will spit out preformatted pages with lean and light code.
The environment is all LAMP, and we lean on mysql heavily. I don't understand the last question- script.pl is on one server, and it needs to call itself as it is basically the user's access to the mysql db. But I'd like it to fire off another command, to another server at the same time. I'd like it to pass a script name and a couple of variables to that second server and have it run.
| [reply] |
It sounds like you need script.pl to just hit another script via HTTP. In that case, take a look at LWP::Simple, and WWW::Mechanize.
| [reply] |
So you want your users to call a CGI script on the development server to upload. And you want that script to generate pages and install them on the production server. The images get uploaded to MySQL on the development server and then get migrated to a MySQL database on the production server as well?
You could just use FTP to move the pages and DBI on the development server to move the images from one DB to the other. That keep everything on the development server. Or (as friedo said), use WWW::Mechanize on the development server to drive a CGI script on the production server to drive the upload.
-xdg
Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.
| [reply] |
A quick javascript hack would be to intercept the form submission and submit the form twice, changing the form action so that the same data was sent once to each domain. You would have to set the target of the form to a hidden IFRAME for the submission whose output you didn't want to display. Attach the javascript to the onsubmit event but add a control to stop the form submitting endlessly (since submitting a form from javascript will trigger the onsubmit event).
The problem with the scenario is that you are dealing with the POSTed data (in the form of a picture). If your issue was limited to simple arguments that could be submitted using a GET then you could just redirect the user from one script to another.
| [reply] |
Thanks all, and thanks inman- that is exactly the approach I am taking, and it is nice and clean. Thanks very much.
R
| [reply] |