I was thinking that "maybe" I might start as a side project a module that would parse (at least the majority of..) well formed HTML and output the perl code to replicate the html using CGI.pm's shortcuts.

At the moment though, it outputs literally the shortcuts to generate exactly the same HTML, and doesn't recognize some of the higher-level form elements, like checkbox_group. Instead, you'll get all the individual input element calls. That's worthy of figuring out how to fix.

-- Randal L. Schwartz, Perl hacker

Randal,

Your the man. Seriously, your books, articles and since I've found Perlmonks, your posts, have been a huge help to me over the last couple years.

Update

Works great. I'll try and modify it to collect the options and print the perl for declaring the arrays and label_hashes. I notice it also doesn't like the new XML style CGI.pm output for non container tags. Should be easy to fix.

Thanks Again.

-Lee

"To be civilized is to deny one's nature."

I've got the <Select> and <option> tags fixed as well.

(It's not pretty but it works) It took me awhile to wrap my head around the recursive nature of the code.

Your code works great. I was able to take a 40 parameter form which is subtabled at least three levels and it worked perfectly. Also for kicks I grabbed a few pages off of Perlmonks and the script generated Perl output it back perfectly. It'll save me a lot of time.

I'll probably add the creation of the %option_labels as well. It's a short jump from where it is. Nothing too crazy. (Don't think I'll bother checking for duplicate dissimilar params or anything.) When this is done would you mind if I posted it?

-Lee

"To be civilized is to deny one's nature."

I really think that you should take another look at templating systems. They will make your life much easier.

Take a look at Effective ways to 'write' html. for a a previous discussion on this topic.

"Perl makes the fun jobs fun
and the boring jobs bearable" - me

I use templates for a lot of things but for applications of this nature there's a few downsides.
• I think it's more platform agnostic for one. A lot of our applications get hosted elsewhere and by sticking with CGI.pm (which almost ever host has) it's easy to move around.
• More things to break. By having the presentation seperate from the logic, you have a lot more files to contend with IMHO.
• Less control (IMHO) over the display in the context of the current session. It's harder I think to make a seamless UI. (Let's say your using SOAP or cXML to communicate with a 3rd party service to complete a transaction of a browser and have to dynamically react. We do odd stuff like this a lot.)
• A few of the projects we are working on are in the direction of extending CGI.pm for totally transparent persistance and validation. Many of the elements are intimately tied to generation of the HTML.


-Lee

"To be civilized is to deny one's nature."

Cool idea. However, templating systems are great. By being able to make components that get reused throughout the site you can change the look of the site quickly and consistently if you want to.

Nothing in most template systems requires 1 page -> 1 file. Most of my recent experience is with Mason and I have made pages that generate themselves differently depending on which step in the process this is.

However, I have more recently bought into the component model that Mason allows and have started breaking up pages into multiple smaller re-usable chunks. So I no longer try to condense multiple pages down into 1 file (unless it is a simple submit page that shows the status of the submit on the second viewing) and I have found that this makes things much simpler. It is easier to write and debug since I can usually determine which file the problem is in at a glance, and then each file is smaller and simpler so I can usually see the problem pretty quickly.

-ben

Hi Ben, I've used templates on over 100K pages. Nothing against them :)
Where I find it lacking is when lets say you have an application where you may have 10 functionality areas with a few subfunctions on each page. This starts to get really messy (I think) and hard to maintain. Especially if a functions is carried out over several forms.

We aren't usally just dumping a form into a nice background but actually modifying the forms and tables, etc in response to the actions and state.

Update
Another thing to think about is that if your program is generating your forms etc, using server side persistance, you can know what your expecting to receive on the next transaction as far as incoming parameters, what is and is not a valid state (relative to where they are),etc to stop people from hacking your forms or submitting invalid or irrelavant data (or resubmitting for that matter).

I agree for a lot of things templating fits the bill. Just it falls short for a lot of what I'm doing.

-Lee

"To be civilized is to deny one's nature."