in reply to A different approach to CGI

after reading the CGI.pm documentation, my problem is that I think this module was created with the concept in mind that programmers create web pages

No, quite the reverse if anything: CGI.pm is written with the assumption that HTML is so complex, programmers would want to use some other interface to write it. This is such an astonishingly preposterous notion that I don't feel any need to bother explaining why it's wrong. Using CGI::Lite for form input is fine, but in terms of output, it's better by far to write your HTML in an editor that shows you the actual code — preferably one that lets you split the window and see the HTML in one pane and the CSS in another.

have a webdesigner create a web page with a WYSIWYG editor

They can create a concept mock-up that way, but someone who knows HTML will have to rewrite it from scratch. The code that comes out of most WYSIWYG editors is so bad, it's not worth revising for a static page, much less trying to use it as a framework or template for dynamic content. The programmer will want each piece of the generated content to be wellformed, so that the pieces can be combined dynamically without producing a complete mess. Worse, if you take code created in a WYSIWYG editor and do something really radical such as resize the browser window, it's often going to fail rather badly. You don't want this headache.

let's take this pretty web page and insert special tags in it for the dynamic, CGI-generated content

If your generated content is anything more complex than filling in a couple of blanks, this is going to get you a completely unwieldy wreck of a mess that will be nightmarishly difficult to maintain. If you really must go this route, you should probably think in terms of PHP, which is geared more that way, but I don't advise it for anything remotely complex. Get an artist to draw you what the layout will look like, yes. Have them print it out and give it to the web developer on paper, and let the web developer figure out how to make it look that way. This will take a little longer initially, but you'll get a website that's easier to modify later without screwing everything up, and you'll get a website that deals better with changes in the user's setup, such as resolution, default colors, and so on. (One of the many things WYSIWYG editors don't show you is when you commit the cardinal sin of specifying a foreground color without a background color or vice versa. This is generally obvious if you're looking at the code.)

;$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}} split//,".rekcah lreP rehtona tsuJ";$\=$;[-1]->();print

Replies are listed 'Best First'.
Re^2: A different approach to CGI
by jdtoronto (Prior) on Aug 09, 2004 at 20:49 UTC
    Jonadab,

    I think you are being a bit hard, and perhaps a bit opinionated here, but maybe those things are not serious problems.

    CGI.pm actually grew out of the need to handle a whole variety of CGI related tasks, not the least of which originally was from handling. But, like topsy, it grew and now it handles just about any aspect of CGI including generation of HTML, if you want. It is viable to only use parts of it, and many of us do that, or you could, as you suggest, use alternative modules.

    They can create a concept mock-up that way, but someone who knows HTML will have to rewrite it from scratch.
    Really? I use hundreds of forms each month that are done that way. We generally don't do any re-wruiting at all! We can't afford the time or the effort just to satisfy pedants. The HTML is done in Dreamweaver or something similar and when finished it validates with the stabdard w3c.org validator. Why do I need to re-write it?

    But we also use 'form components'. Many of our applications use the same basic form sections over and over again. So why re-write them at all? We have currently about 80 form components on our server which are carefully crafted, have the CSS embedded in them and which are well documented so we can ensure that when they are combined into another page they will work seamlessly - and they do.

    Our general rule is to give the designer a paper and pencil mock up of what we need the forms to look like. The graphic designers use the CSS to create the overall look of the site and when it is all merged it works well. In fact we have one client who just today turned on a complete re-design of their intranet. Over 45,000 lines of Perl code required not a single change, nor did any of the 187 form based pages on the site. The whole thing was done in CSS and the form components are called out by the wrapper templates in the templating engine. Oh, did I mention that not a single HTML or CSS document was touched by hand? The HTML is edited in Dreamweaver and the styles are handled in StyleMaster.

    And why introduce PHP into the mix? We have inherited some sites that use PHP, and we are working as hard as we can to get rid of it! Until recently I did allow one programmer to use PHP for some sites where clients were already using it. But as of a week ago we instituted a no-PHP policy. We get far better operation and much greater uniformity of installations using Perl than we can with PHP. With any PHP stuff we have we usually end up with the sysadmins installing additional libraries or modifying things so it can be made to work. It is far saner for us to have all of our servers basically configured the same way using Perl so we don't have major re-work headaches when we do any upgrading.

    The HTML generated by the WYSIWYG applications may not be ideal, but it is servicable, the same goes for CSS code. So lets admit that these systems are in fact workable and they do work in some pretty big systems.

    jdtoronto

[reply]

In Section Seekers of Perl Wisdom