Re^12: RFC: Proofread the POD for my HTML elements module

[Don Coyote]

Possibly not the answer you are looking for, but I hope not. I was thinkng on your code and how to bring the program into the functional by means of introducing some kind of presumptive end_tag method. On reflection I realised that this was already in place in the CGI.pm module. Foiled again!

Now, you mention that you have not fared well with objects so far, and CGI is not an easy beast to tame. At first I also did not comprehend the difference between the functional and the objective approach. Both importing functions and using the object syntax, but I got the script working. With the help of ardous study, and some lenient monks :)

CGI.pm is both though and the difference in use is derived from how you harness the functions in your script. Either by calling them as functions, thus requiring the need to provide an import list, or in the object method calling way which does not need an import list. A trivial understanding of importing helps here. see Exporter.pm documentation.

I also think it important to realise that there are many issues in your script that have already been addressed and refined in CGI.pm, for example security, and differing server architectures (eol phrasing). And by using CGI.pm you can gain knowledge of objects, while being productive with functions.

Here is the example from before, but in CGI functional format. This shows that CGI can be relatively painless. And you can introduce more complex structures as you become familiar with the way of the CGI. In particular the import of a tag preceded by the asterisk chr '*' is probably the key to where i have been attempting to lead you in my previous responses.

#!/usr/bin/perl -T
use strict;
use warnings;# qw(fatalsToBrowser warningsToBrowser); # FATAL => qw( a
+ll );
#use Base::HTML::Element;

#CGI's functional interface, importing a standard set of subroutines
#and the specified qw( *tag ) start_tag end_tag switch/pragma/syntax.
#read the pod for descriptons of these
use CGI qw(:standard *div);

#sends HTML to server for humans to read,
#comment out to collapse whitespace
use CGI::Pretty;

print header; #defaults to xml but can be defined to an HTML namespace

print start_html(
    -title=>'My page title',
    -style=>{'src'=>'css/style.css'},
    -script=>{'type'=>'JAVASCRIPT',
          'src'=>'javascript/script.js'},
);
# end start_html, auto prints body opentag.


print start_div({-class => 'div_class' }); #note start_div - else clos
+es
print h1({-id => 'sample_heading', -style => 'color:#666' },'My sample
+ heading 1');
print p('A sample paragraph so you can see how this works.');
#css styling to do
print ul({-id=>'colors'},
          li({-type=>'disc',-style => 'color:#f00' },'red'),
          li({-type=>'disc',-style => 'color:#0f0' },'green'),
          li({-type=>'disc',-style => 'color:#00f' },'blue'),
        );
print p('Another paragraph for you');

print h2('A second sample heading');
print p('Guacamole or Bust');

print end_div(); # from imported *div flag

print p({ id => 'end_remarks', class => 'remarks' }, 'Some end remarks
+.');

print end_html();

Of course learning coding through constructing your own versions is a great way to learn, I too do this. The really hard thing is trying to find something that has not already been done, or at least something you (or I, tbh) may really have a shot at improving on.

I don't really see CGI going away anytime soon. CGI caters for unknown tags and such. And I'm pretty sure there have been a few changes since last time I viewed it, if only my understanding. But I do start to see possible patch opportunities here and there... well on some modules, mostly doublestuff or refchecking.