On Thu, Apr 26, 2012 at 08:32:29AM -0400, Mark Haney wrote: > On 04/26/2012 07:22 AM, Michael Rasmussen wrote: > > > > >Again, you haven't described why Perl can't create the same HTML the PHP > >does. > > > > > > > > Obviously, I didn't explain myself quite well enough. Let me try > again. I've got a web app I'm building for the company I work for. > It was initially started by an intern in pure perl and was more or > less nothing but some CGI to dump data into a DB and pull data out > of that DB. The perl code generated basic HTML tables and output > and nothing else.
Well this confuses me from the start :) The perl scripts collect data from the sewing machines and then use CGI to dump the data in a database? CGI isn't necessary to do that part. DBI interfaces to a database and you are hopefully already using that in the scripts. Step 1: separate the function of collecting the data and storing it from the form generation. Step 2: If you really want to continue to use Perl then write the scripts to read the data from the database and present that. If your data is stored in such a way that you can't do that then you have a db design problem to fix. Step 3: Now you have access to your data you can look at templating systems. There are many perl templating systems. TT is a good one - I use it to breaking point. Here is where you start with TT http://search.cpan.org/~abw/Template-Toolkit-2.24/lib/Template/Toolkit.pod http://search.cpan.org/~abw/Template-Toolkit-2.24/lib/Template/Manual.pod http://search.cpan.org/~abw/Template-Toolkit-2.24/lib/Template/Manual/Intro.pod although you may want to look at some of the pointers to MVC frameworks provided below. > > Keep in mind here that I've used perl quite a bit, but /never/ in > the context of actually building a website. Not from the ground up. > I have built them in C#, ASP, and PHP, so I'm no n00b to web design. > Just when using perl. > Perl documention is available via the command line using perldoc e.g. perldoc CGI perldoc DBI If you do have any experience in web design then you'll be aware of the separation of the different parts of a web page - CSS for styling, HTML for layout ring any bells? This separation of function is not new - it's applied in a lot of places > I found, that with researching how to do things in perl (like > dynamic dropdown boxes) I was having trouble finding resources that > worked for me. At that point, I moved to PHP since I knew how to do > things with it. There are a number of resources available including the documentation on your system, the Modern Perl book http://modernperlbooks.com/books/modern_perl/chapter_00.html http://learn.perl.org, http://cpan.org and http://perlmonks.org - long may they all shine under the sun. > > That brings me to my problem. I have these reports already built in > perl, and all I want is something like this: > > PHP/HTML form -> PERL CGI -> PHP/HTML This is seriously horrible. One problem I have is that you're cobbling things together and cobbling them poorly with a really half-baked idea and all you really presented was a query about how to solve your half-baked idea . Your simplest route is to learn the CGI module in Perl and use it. > > Essentially I want perl to do the grunt work and output it to my PHP > framework. The only option I found that works (mostly) is to output > the report into a file and then include it in the PHP code. The > only issue there is that I can't inject PHP code into the CGI like I > do with straight HTML (like print "<table></table>"). This mad-cap scheme was doomed to failure from the start. Did you check whether you could actually achieve this code injection before you started? > > I thought this would have been a fairly simple question to ask, like > I've overlooked the obvious and needed it pointed out. Ah well. > You presented something no one would probably ever think or want to do for a start. This idea of using PHP then Perl then PHP and then -oh I have to dart back into the perl CGI script and hackitaboutinitusingPHP would probably have me showing you the door if I were your boss. Most of us are not telepathic or instantly know what you mean when you fail to explain your real problem - which is that you would like to conitinue to use Perl - and I would hazard a guess that it is because it grabs the data and stores it so well - but you've introduced PHP into the mix because you can write in that. Well, it's hard to think of a good analogy to this but I guess learning to drive a car is a lot like riding a bike so I'll do the latter instead of the former because it will really prepare me for driving a car. Would you do that, too? You will find people here will get puzzled if you merely present a half-baked solution to your problem as the problem you wish to solve. > At this point, I have no problem at all with ripping out what PHP h> I've done for straight up perl if I can find the resources that can > walk me through the design and framework setup. I noticed replies > about perl templates and I'll look into them now. I believe other posters have mentioned MVC frameworks. A search for MVC frameworks in Perl gives these links. Please do read them. http://www.oreillynet.com/onlamp/blog/2006/05/mvc_frameworks_in_perl.html http://www.bbc.co.uk/blogs/radiolabs/2007/11/perl_on_rails.shtml http://www.catalystframework.org/ http://www.perlmonks.org/?node_id=849800 and particularly http://www.perlmonks.org/?node_id=850342 > > My apologies for sounding like a troll. It was a question I thought > had a quick answer. You live and learn. > On reading your OP - my very first thought was 'do not feed the trolls'. Consider yourself treated to a banquet. Kind Regards L. -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
