Now, for all sorts of reasons, I'm working on a web based shopping platform for a close to home client, my daughter, and so far, (3 months) while we've got a live and working custom built web shop, there's a lot of things I want to do with it, because we need to, but an absence of in depth knowledge of PERL and all related software is proving an obstacle to the planning of the next phase.
The recent learning curve of enough HTML, JAVAscript, PERL and UNIX to survive on a shared web host has been close to trying to climb the North Face of the Eiger, but it's been worth the effort, in that while the shop is VERY rough round the edges at the moment, we do have a working on line shop with payment system that is reasonably fast, easy to use, and has been attractive enough to persuade people to use it and place orders.
Now, I want and need to tidy it up, (hide my debug code among other things) and add in the condiderable number of extra functions that the buying customer won't see as such, but that will make our end of it a lot easier, faster, professional and more economic to do the job, but by doing it in a way that retains the integrity of the ease of operation which we have right now.
To complicate things, the original plan was that I wasn't doing any of the server side work, but a fundamental disagreement about the way it was going to work, combined with a total absence of documentation from the server owner/operator meant that the original plan and server had to be abandoned in mid flight, which meant taking space on a shared server, and getting to grips with server side concepts, as well as enough PERL & UNIX to get it live.
The longer term plan is to move to our own dedicated facility in house, based on DELL servers, but the exact decisions about windows/SQL or UNIX/MySQL are not yet firm, having had to go with UNIX/Apache/PERL so far is making me think that remaining on that side of the fence may well be an attractive option, and at present, we're not using any database as such, so that decision can be deferred for a little while.
That's where the lack of in depth knowledge is a problem right now, in that I need to do some serious system planning without being sure that the underlying system software I am going to be using can easily accomodate the direction I am thinking of taking.
What I am thinking is that there will be a considerable number of things that I want to do that could be triggered as a response to POST information from a web screen, and at the same time, providing there is an easy way to load the POST information as part of a PERL thread, that would make a very powerful and easy way to also be able to do the same thing as a spawned thread from on line processing.
An example might be that I (will) have a script that will take just an order number in, and produce an E-mail transmittable copy of the invoice relating to that order, based on database lookup, which would be very helpful in allowing a customer to ask for and receive a duplicate copy of the paperwork.
At the same time, if I could load the information into a POST record for that script, it could also then effectively be used as the original production script, and by virtue of the POST and script being a self contained unit, or possibly module, once it's working, it can be used wherever it is needed to produce that document.
The same is then true for many other aspects of the system, from a design testing and operational view, and code maintenance becomes much easier, in that modules can be tested in isolation, with known data from test databsse sources, which makes many tasks much easier.
Not a new concept, it worked very well on the mini's that I used to work on, and I used the concept all the time for many file maintenance and print jobs.
It's a development of the subroutine concept, in that the methods are the same, create a subroutine, give it defined input, and let it get on with the job, but as I will want to use the same subroutine from an on line screen, the parameter input I want to use is the POST record, if that makes sense.
So, my question, based on very little real exposure as yet to complicated PERL, which at present I'm running on a shared hosting UNIX based APACHE box, is initially relatively straightforward.
Is there an easy (or relatively easy) way to spawn a CGI script from within a CGI script, using the parameter concept I've outlined above, while allowing the spawning script to continue to run, which will probably result in a number of other spawns happening?
It's possible that I am looking at the wrong language for this, and that I should be looking at something like PHP, or .NET, but right now, having spent the length of time I have getting started with all that I have, I'm reluctant to make the mix even more complicated, and so far, while the syntax and implementation of PERL has been hard to work with with compared to the luxury of precompiled code etc on the mini, at things stand now, I can see no valid and pressing reasons to go in other additional directions.
So, Pointers, ideas, alternative suggestions all appreciated at the moment, in order to avoid making any more mistakes :>), there's been enough of them already.
Sorry the message is a bit long, I couldn't see an easy way to explain where I'm coming from without giving a bit of my background first.
Thanks
Steve
In reply to Very new to PERL, want to see if CGI spawn concept is possible and or feasible without major pain by IrishSteve
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |