Need help separating logic from display

[jeyroz]

Fellow Monks:

I am currently trying to find a more 'complete' method for separating my logic code from my display markup.

In the past I would include all form markup in my perl files and use HTML::FillInForm to populate the form fields. I would then push the form out to a <TMPL_VAR NAME='content'> (using HTML::Template) but this defeats the purpose of using a template.

I recently began using HTML::Template to generate ALL my markup including forms. Unfortunately, I'm have a problem COMPLETELY populating my forms while in a template file. I have used HTML::Template's 'associate => $query' to load the form with the param() info. This method breaks down when trying to populate select menus, radio buttons, and checkboxes. This method also (I believe) prohibits me from prepopulating a form using data from a database query.

I am determined to remove any trace of markup (within reason) from my perl code and would appreciate any 'battle tested' suggestions.

[punkish]

Let me take a stab at assisting you.

I haven't used HTML::FillInForm, but I routinely use H::T, and never have a problem creating forms. Let's take the example of a select widget -- if its <option> values are going to be created programmatically, obviously it you will create an AoH in your code that you will then loop over in your template. You will always have some sort of markup that you might generate programmatically -- for example, I usually generate values for "oddrow" and "evenrow" CSS classes so I can color the rows in my tables with alternating light and dark colors. Or, I might generate values for the "checked" state of radio or checkbox fields so they are correctly checked or unchecked in the displayed form.

Bottomline -- Don't worry about removing all traces of markup from your code. Instead, worry about removing all traces of code from your markup. You don't have to achieve that 100%, but the more you achieve it the closer you are to a perfect state.

[babumovva]

Hi, I have previously developed a system for workflow colloboration for my previous employer, wherein I tried to achieve the same goal of separting the GUI (HTML content) from the business process logic. I did not use any modules like HTML::Template but however I just cached all the html files with place holders (templates) into a hash. The names of the templates and their filenames including path are associated/driven by a parameter file. The names serve as the keys for the hash and the html content as value. The html content is populated with place holders like #customer_name# etc. The only problem is where a table with multiple rows of data to be populated typically with some values coming from a database. In these cases the html code defining the row itself is made a template and the main template file holds a place holder of this template name. While using mod_perl, I have loaded the hash in the startup.pl code so that there exists only one copy of this hash for all instances of webserver processes. To simplify remembering the place holders, you may like to use the same names of the fields/columns in the database table, but however these are validated for spurious code before loading into the hash. This scheme has worked well for me and the response time will be very good as there is no need to read any html files for each query, as all the templates are in memory. Except for the place holder tags the templates are free from any embedded code. The server side logic is clean as it is devoid of any content generating code (html related stuff) and the logic is easy to comprehend. This scheme has worked well for me and you may like to try the same. Hope that helps. Thanks babumovva

[mpeters]

To put it simply, I'd keep doing what you're doing but change the order slightly. Put all of your markup into your templates (it only get's confusing to the person coming behind you if you put some in your templates and other bits in your perl code) and then pass any needed variables into your template but don't worry about passing form input values.

Then process your template, catch the output and then send it through HTML::FillInForm, and then return that output to the browser. This is actually what the CGI::Application::Plugin::ValidateRM does for you when it creates the error output after a form doesn't validate. Your code might look something like this:

  my $tmpl = HTML::Template->new(....);
  $tmpl->param(%non_form_stuff);
  my $output = $tmpl->output();
  my $fif = HTML::FillInForm->new();
  print $fif->fill(
    scalarref  => \$output,
    fobject    => $query,
  );

[AJRod]

In case you haven't, you may want to try Formbuilder. It works well with H::Template, and with this you can prepopulate a form from a database query.

[srdst13]

I would second this vote. FormBuilder does a great deal of the form creation, validation, and parameter handling pretty much automagically and integrates seemlessly with mod_perl and CGI::Application. Params are sticky, but that behavior can be easily modified. As a bonus, it even creates javascript validation code, which you are free to use or not; validation also occurs on the server side. As for templating (View from Controller and model), it can generate HTML on its own or be used with any of the big-three (H::T, TT2, or Template) templating systems.

[tphyahoo]

I had a similar question and wound up putting together a Survey of Surveys on HTML Templating systems to compare and contrast what's out there.