Hey Steve -- > There's a new guy in the company that seems to be dead set > against *shudder* > coding html into cgi scripts, creating multiple cgi's when one > CGI-Application module would do, and creating arrays of > tables ( when he > does decide to actually use a template file) by defining a > javascript array > at the top of the page and then using a javascript loop in > the middle of the > page to print the table.
This guy is *against* these things? Or do you mean that these are the things he *wants* to do? I'm going to assume that what you are saying is that he "dead set *on*" doing these things. (Otherwise, I pretty much agree with him! ;-) 1. Regarding HTML in CGI code: Use HTML::Template (or ANY templating system for that matter) instead. HTML-in-Code (or Code-in-HTML, a la Mason, Cold Fusion, ASP, JSP, etc.) is only a good idea if your app is simple and all developers who are managing it are experts in both HTML and the programming language (in this case, Perl). In my experience, it is very rare to find a single individual who is *expert* in both. Putting application code into the same document as your HTML is such an awful idea, I scarcely have words to describe how awful it is. I want to ask your colleague if he also advocates taking a late-evening stroll on a busy interstate highway, dressed in black. Ask him to enumerate the reasons for not doing so, please! ;-) 2. Regarding multiple CGIs verses a single CGI module The trick is really to figure out when a single module will do, and when multiple modules are required. I am of the belief that an "application" is a collection of functions which are affiliated with one another. If a single function (and its resultant pages) would not make sense out of the context of another function, then those two functions (and the pages they create) are part of the same application. >From your description so far, I get the impression your colleague is thinking about rolling his own "server page" system which has one CGI per HTML screen. That's an awful idea. If he's stuck on the idea of (1) embedding HTML and Perl in the same document, and (2) having one "CGI" per "page", *AT LEAST* implore him to use some existing server page system, such as HTML::Mason! Inventing his own system is a total waste of time, especially when perfectly good and FREE systems exist. 3. Regarding pushing data and display functions into Javascript Interesting. Well, for starters, he had better hope the user has Javascript enabled, and their web browser supports whatever JS functions he uses. Second, he has just DOUBLED the number of programming languages which are required for application development. Now, in addition to needing expert Perl programmers, you also need expert Javascript programmers. That makes sense. Not! Finally, how does his scheme work when you have large result sets? If you load 500 to 1000 records into a web browser will this be a performance problem? I imagine so. I suppose that in those cases his "CGI page" would limit the results sent to the web browser. Nice. I guess he would now have database-related code in two places for a single application: In Javascript and in the CGI. That ought to make maintenance loads of fun. Hope this helps! Warmest regards, -Jesse- Jesse Erlbaum, CTO Vanguard Media http://www.vm.com 212.242.5317 x115 [EMAIL PROTECTED] --------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/cgiapp@lists.vm.com/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
